Guideline 4.3 Design Spam: Why Apps Get Rejected and the Fix

Guideline 4.3 design spam is the rejection you cannot fix by fixing something. There is no crash to patch, no missing privacy string to add. Apple is telling you that the app, as a product, is not different enough from what is already on the store. That is a harder message than a bug report, and most of the advice founders find online treats it like one.

I have watched founders answer a 4.3 rejection with a new icon and a new name, and get the same rejection two days later. This is what the rule says, which half of it you hit, and what to change before you resubmit. The wait itself is covered in the piece on an app stuck in waiting for review. The broader list of reasons AI-built apps get flagged lives in the vibe-coded app guide.

What Guideline 4.3 Design Spam Actually Says

The rule sits under the Design section of Apple's App Review Guidelines, headed Spam, and it has two parts. Despite the nickname, guideline 4.3 design spam is not about spammy behaviour like fake reviews or keyword stuffing. It is about duplication, of your own apps and of everyone else's.

Part (a) tells you not to create multiple Bundle IDs of the same app. Apple's example is a separate map app for every city instead of one worldwide map. Part (b) tells you not to submit apps that are indistinguishable from what is already widely available. It calls out opportunistic variants of existing categories and popular apps.

Both parts give the same reason: they make the store harder to navigate and lower the quality for users and for other developers. Read that as the reviewer's real question. Not "is this app broken?" but "does the store need this one?"

4.3(a) vs 4.3(b): Which One You Got

Check which letter your guideline 4.3 design spam message cites, because the fixes have nothing in common.

4.3(a) multiple bundle IDs is a structure problem. You published, or tried to publish, several apps that are the same app with different content: one per city, per sports team, per university, per client. Apple's answer is one app, with the variations delivered through in-app purchase. If this is you, the fix is architectural, and it is the cheaper of the two to solve because the product itself is fine.

4.3(b) is a product problem, and it is the one founders hit. The guideline names categories Apple considers well established, such as dating, flashlight, sound effects, wallpaper, simple timers and fortune telling. It says new submissions in those categories will not be accepted unless they offer a meaningfully different or improved experience. It also says low-effort categories add no value and that repeated submissions of this kind may lead to removal from the Apple Developer Program.

That last sentence is the reason not to improvise. If you got an app rejected for spam under 4.3(b), a second weak attempt is riskier than the first.

Why AI-Built Apps Hit Guideline 4.3 Design Spam

In my experience the rejection clusters in crowded categories: AI companions, identifiers, generators, wellness trackers, and anything with a chat box wrapped around a model. Those are the categories where a founder with an AI builder can ship in a weekend, and so can a thousand others.

A reviewer who opens your app sees one core screen, a model behind it, and a paywall. They have opened that exact app before. Nothing in it is wrong. It is just not distinguishable, and the rule is written for exactly that case.

Template tooling makes it worse in a second way. Apple's guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless the provider of the app's content submits them. If your app came out of a builder's template with the content swapped, a template app rejection can arrive under 4.2.6 or 4.3, and the explanation is the same.

What Does Not Fix a 4.3 Rejection

These are the moves I see most often, and none of them changes what the reviewer sees:

• A new icon, name or colour scheme. The guideline is about the experience, not the packaging. Apple's own copycat rule, 4.1(a), explicitly mentions minor changes to a name or UI.
• A longer description. Marketing copy does not change what the binary does.
• Resubmitting the same build with a note saying it is original. You are asking the same person the same question and offering no new evidence.
• A second developer account. Do not do this. Repeated submissions are the exact pattern the guideline warns about, and a new account does not hide a binary that looks the same.

If the reviewer could not tell your app from the category before the change, they will not tell it apart after.

What Actually Makes an App Different Enough

Apple's wording for guideline 4.3 design spam gives you the test: a meaningfully different or improved experience. Meaningful means a user can name the difference in one sentence, without seeing a screenshot.

Things that pass that test in my experience are specific. A capability the category lacks, such as a workflow for a particular profession. Data or content the others do not have, which you can show. A genuinely different interaction, not a reskin of the chat box. Use of the device that the category does not usually bother with.

We shipped a mushroom identifier app and a plant-care app, both in categories that look crowded from the outside. What carried them was never the scanning feature everyone has. It was what happens after the scan, the part that is specific to the person using it. That is the work a reviewer can see in a few minutes.

If you cannot write the one-sentence difference, no review note will write it for you. That is a product question, and it is better answered before a rejection than after.

How to Answer the Reviewer

Reply in the App Store Connect message thread and be specific. Say what the app does that others in the category do not, in two or three sentences, and show where to find it. Give the reviewer a demo account and a short path through the screens that prove the difference.

Do not argue about the category and do not quote the guideline back at them. A reviewer who sees a reasoned explanation and a working path to the feature has something to act on. In my experience a long emotional reply does the opposite.

If the app is a 4.3(a) case, say how you are consolidating: one Bundle ID, the variations moved to in-app purchase. Then do it, rather than describing it.

Resubmit After a 4.3 Rejection: Change the Binary First

The rule for how to resubmit after a 4.3 rejection is simple: the next binary must contain the change. A reply with the same build is a second look at the same evidence.

A sequence I use:

1. Write the one-sentence difference for the product.
2. Find where in the app it is not yet visible, and build or surface it, ideally in the first minute of use.
3. Update screenshots and metadata to match what the app now does, not what it once promised.
4. Add the demo account and the path in the review notes.
5. Submit once.

Step five matters. Each rejection costs you the queue and the time, and a founder who submits three variants in a week has produced the repeated pattern the rule describes. If the next attempt is not clearly stronger, hold it back.

If you are on a fixed launch date, plan for at least one more review cycle, and read the mobile MVP launch checklist to see what else should be settled before a resubmission.

What I Would Do If Your App Got a 4.3 Rejection

I ask three questions before anything else. Which letter, (a) or (b)? Can you say in one sentence what this app does that its category does not? And was it built from a template or an app builder?

If it is (a), we consolidate the Bundle IDs and use in-app purchase, and the product is untouched. If it is (b) and the one-sentence answer exists, we make that difference visible and resubmit once. If it is (b) and the answer does not exist, I tell the founder so, because no resubmission fixes that. The money is better spent on the product than on a third attempt.

The Bottom Line

A 4.3 rejection is a question about your product, not your build. Read which part of guideline 4.3 design spam applies to you, make the difference real before you reply, and resubmit once with a binary that shows it. If you want a second opinion on whether an app is different enough before you submit, see the engagement model on the services page, or tell me about your project.