Guideline 4.3 Design Spam: app rejected, what now?
By Mehdi Azizi
Updated , 9 min
Guideline 4.3 Design Spam: what 4.3(a) and 4.3(b) say, why AI-built apps get hit, and how to reply to Apple and avoid it.
Guideline 4.3 Design Spam: the short answer
Guideline 4.3 is the App Store's anti-spam rule. 4.3(a) forbids publishing the same app several times, and in practice it's used against repackaged apps. 4.3(b) rejects apps that can't be told apart from what already exists, especially in saturated categories. The fix is about substance: a core feature nobody else offers.
It's the hardest rejection to fix. It questions the very reason your app exists, and no code fix is enough if the product looks too much like what's already out there.
I publish my own iOS apps: Solys, an alarm clock with mini-games, and TradaZen, a trading practice app, are on the App Store. Nolera and Clic were rejected, then fixed. I've had 2.1, 5.6.3 and 2.3.2 rejections, which I break down in why Apple rejects your app. I've never had a 4.3 rejection, and I'm not going to pretend otherwise. This guide is based on Apple's official text, paraphrased.
What exactly does guideline 4.3 say?
4.3, "Spam", sits in section 4, "Design", of the App Review Guidelines. Its two parts target two different problems.
4.3(a): one app, not one copy per variant
The official text asks you not to create multiple Bundle IDs for the same app. Apple's example: publishing one map app per city in the world, instead of a single world map where people search for their city. If your app has versions by location, sports team or university, Apple advises you to submit a single app and offer the variants through in-app purchases.
In practice, the rejection message goes further than this example. In the 4.3(a) rejections developers have posted on Apple's developer forums, Apple writes that the app shares "a similar binary, metadata, and/or concept" with apps submitted by other developers, with only minor differences. The message calls these similar or repackaged apps spam. Three words matter: the binary (the compiled code), the metadata (name, description, screenshots) and the concept.
Two other rules point the same way. 4.2.6, a sub-rule of guideline 4.2, rejects apps created from a commercial template or an app generation service, unless they're submitted directly by the content provider. Guideline 4.1, "Copycats", forbids copying a popular app by slightly changing its name or interface. It opens with a simple sentence: "Come up with your own ideas."
4.3(b): saturated categories
4.3(b) rejects apps that are indistinguishable from what's already widely available: for Apple, these opportunistic variants hurt discovery on the App Store.
The text names the categories involved. Dating apps, flashlights, sound effects, wallpapers, simple timers and fortune telling are already well established. Apple no longer accepts new submissions in these categories unless they offer "a meaningfully different or improved experience". Apple can even remove the ones that aren't updated or improved, or that attract nobody.
A second list is harsher: drinking games, Kama Sutra, fart and burp apps. Apple considers them low quality or low effort, and repeated submissions of this kind can get you removed from the developer program.
Horoscopes and astrology aren't named as such in the current version of the text. A generic daily horoscope app is still very close to fortune telling, and I'd treat it as a saturated category.
Why 4.3 hits AI-built and template apps more often
Templates share everything by design
An app template sold online gets bought by lots of developers, who change the colors, the icon and the name, then submit. Apple doesn't explain how it spots similarities, but its message talks about the binary, the metadata and the concept: three things a template shares with all its copies. That's exactly the case 4.3(a) and 4.2.6 target.
AI builds the average version of your idea
Ask an AI for "a habit tracking app": it gives you the most likely version of the idea, so the average of what exists, with the same screens and the same onboarding. The code may be original, the concept isn't. And 4.3(b) judges the experience, not how original the code is.
AI is great at coding a differentiated idea, but it won't find the difference for you. I go over what it does well and what it misses in building an iOS app with AI.
How to really differentiate your app
A core feature nobody offers exactly this way
This is the rule I apply to every idea, precisely to avoid 4.3: a core feature nobody else offers exactly this way. Yet another alarm clock would be vulnerable, since simple timers are among the categories Apple names. Solys is an alarm clock that makes you win a mini-game to turn it off. The difference fits in one sentence, and you see it the first time you use it.
The test: finish the sentence "it's the only app that...". If all you can come up with is "but prettier", your difference is too weak.
Content and logic that belong to you
A different skin isn't enough. What sets an app apart is what it produces: content written for it, data it computes, a mechanic you can't find anywhere else. If you start from a template or an open source project, change the logic, not just the colors.
A name, screenshots and a description that prove it
The 4.3(a) message mentions metadata: the reviewer judges your listing too, just like with guideline 2.3.10. A generic name like "Flashlight Pro" signals a copy before the app is even opened. Your name and subtitle should state the unique feature, your first screenshot should show it, and your description should open with it. This work also helps your search ranking: the method is on the App Store ASO page.
One app for all your variants
If your idea comes in versions by city, team or theme, publish a single app with a choice inside it, plus in-app purchases if the variants are paid. That's the literal reading of 4.3(a).
How to reply to a 4.3 rejection in App Store Connect
What used to be called the Resolution Center now lives in the App Review section of App Store Connect. That's where you reply to the App Review message with text and attachments, screenshots or documents, as long as you haven't resubmitted.
- Identify the sub-rule. A 4.3(a) rejection talks about similarity to other apps or multiple variants. A 4.3(b) rejection talks about a saturated category.
- Be honest about the substance. If your app comes from a template or really does look like what exists, don't argue: change the product, not the wording.
- If your difference is real, show it. Keep your reply short, factual, in English, with a video of the core feature attached.
The template I'd use, to adapt:
Hello App Review team,
Thank you for your feedback regarding Guideline 4.3.
[App name] is not a variant of an existing app. Its core feature is:
[one sentence: what the user can do that no other app offers this way].
What makes it different:
- [Unique feature, and where to find it in the app]
- [Original content or logic created for this app]
- [Why it matters to the user]
All code, content and assets were created for this app.
We do not publish any other app based on the same code or concept.
Attached: a short screen recording of the core feature.
If a specific part of the app looks similar to existing apps,
could you tell us which one, so we can address it precisely?
Best regards,
[Your name]
Only write the two sentences about the code and other apps if they're true. A false claim in a reply to Apple will cost you more than a rejection. The full process after any rejection is on the app rejected by Apple page.
When to appeal to the App Review Board
Apple lets you appeal to the App Review Board if you think the reviewer misunderstood your app's concept and how it works, or that you were treated unfairly during review. Apple sets three conditions: give specific reasons why your app complies with the guidelines, file only one appeal per rejected submission, and first answer any request for additional information.
Appeal when your difference is real, visible in the app, and your reply in App Store Connect wasn't enough to get it across. For a template, a clone or a variant with no difference, an appeal won't change the product.
On the same page, Apple also offers 30-minute video appointments with App Review. If your idea comes close to a saturated category, ask before you build.
The anti-4.3 checklist before you submit
- You can finish the sentence "it's the only app that..." without mentioning design
- The core feature is visible on first use, without searching for it
- No screen, text, sound or visual comes as-is from a template, and you've changed its logic
- You don't publish two apps sharing the same code and the same concept
- Your variants (cities, teams, themes) live in a single app
- Your name and subtitle state the unique feature, not the category
- Your first screenshot and your description open with your difference
- If your app touches a category named in 4.3(b), the review notes explain in two sentences what sets it apart and how to test it
You prevent 4.3 when you choose the idea
"Yet another" app in a saturated niche has two problems. Apple may reject it under 4.3(b). And if it gets through, it's up against apps installed for years without giving anyone a reason to pick it.
So differentiation isn't something you bolt on at submission time. It's decided before the first line of code, by narrowing your idea down to one clear core feature for a specific audience. That's the heart of a well-scoped iOS app MVP, and the first step of my idea-to-App Store method.
Choose the right idea before you code
In the iOS Kit, the first step of the path is there for exactly that: choosing the idea, the audience and the price, before writing code.
Already got a 4.3 rejection? The Apple Review Kit helps you find the cited rule, what it asks for, and an example fix and reply. If you want us to look at your case together right now, book an hour with me on video.
Nobody can guarantee Apple's approval, me included. I can help you rule out, right from the start, the ideas that would make one app too many.
Still unsure about your idea? The free diagnostic starts from your project, tells you which step to tackle first and sends you my Apple anti-rejection checklist. The home page then shows how to build a mobile app without starting from scratch by choosing the idea before writing code.
Frequently asked questions
What's the difference between 4.3(a) and 4.3(b)?
4.3(a) targets duplication: several versions of the same app, or an app that shares its code, listing or concept with others give or take a few details. 4.3(b) targets saturation: nothing new in a very crowded category, like flashlights.
Will my AI-built app be rejected under 4.3?
Not because it's built with AI: Apple judges the result, not the tool. The risk comes from a generic idea that AI turns into the average version of what exists. If your core feature is unique and visible, where the code came from isn't a 4.3 problem.
Can you use a template without getting rejected?
A template used as a technical starting point, then deeply transformed, isn't the problem. A template published almost as-is, with a new name and new colors, is exactly what 4.3(a) and 4.2.6 target.
Should I change accounts or Bundle ID after a 4.3 rejection?
No. Changing the identifier or the account doesn't change the app, and 4.3(b) states that repeated submissions of low-value apps can get you removed from the developer program. The only lasting way out is to change the product, then resubmit.
Can a dating or wallpaper app still be accepted?
Yes, if it offers a meaningfully different or improved experience: that's the condition set by Apple's text. That difference has to show in the app, the listing and the review notes.