Guideline 4.3 spam rejection: which half you got, and how to get approved

Apple's June 8, 2026 update rewrote both halves of 4.3 and added examples, so older blog posts that treat it as one rule are out of date. The two halves protect different things. 4.3(a) stops one developer from filling the store with near-identical Bundle IDs. 4.3(b) stops everyone from adding another undifferentiated app to a category that already has plenty.

Most indie developers who get a 4.3 didn't set out to spam. They shipped something that looks like spam from the reviewer's side of the glass. The common causes we see:

• Template code shipped close to stock. Starter kits and boilerplates are fine as a foundation. A build where the template's screens, assets and copy are still recognisable is what gets matched.
• One codebase, several listings. A "Pro" and a "Lite" app, or a version per language, niche or client. Apple's own guidance is to ship one app and handle variations with in-app purchase or in-app choices.
• Bought or inherited source code. If the same code shipped under an account Apple later terminated, the similarity follows it — that's the "terminated account" variant of the message.
• A thin wrapper in a crowded category. Another habit tracker, timer, wallpaper or AI chat front-end whose first screen could belong to fifty other apps.
• Listings that copy the category leader. Screenshots, subtitle and description written to resemble the top app make the "concept" match stronger, even when the code is yours.

1. 01

   List everything the flagged apps share

   Code, bundle structure, assets, onboarding copy, screenshots, description, even the support URL. If you run several apps, include all of them — the match may be between two of yours.

2. 02

   Consolidate variants into one app

   If the difference between your apps is a city, team, theme or content pack, merge them. Offer the variation as an in-app choice or an in-app purchase, as Apple suggests in 4.3(a).

3. 03

   Make the binary unmistakably yours

   Remove template leftovers — sample screens, placeholder icons, stock onboarding — and rebuild the first-run experience around what your app does. That's the part a reviewer compares.

4. 04

   Rewrite the listing from scratch

   New screenshots that show your own UI and value, a subtitle in your own words, and a description that leads with what's different. Don't reuse the old listing with a few words changed.

5. 05

   Explain provenance if code was bought

   If you acquired the app or its code, say so plainly in your reply: when, from whom, and what you've rebuilt since. Hiding it tends to end in a harder rejection later.

6. 06

   Reply in App Store Connect, then resubmit

   Summarise the changes in specific terms (what was merged, what was rebuilt) rather than asserting the app is original.

4.3(b) isn't asking whether your code is original. It's asking whether a user who already has one of these apps would get something new from yours. Apple's text names the bar directly: a "meaningfully different or improved experience". Your job is to have one, and make it impossible to miss.

1. 01

   Write the one-sentence difference

   Finish this: "Unlike the apps already in this category, ours ___." If the blank is a colour scheme, a lower price or "better design", that's not enough. A different method, audience, data source or workflow is.

2. 02

   Put it on the first screen

   The differentiator should be visible within seconds of launch, not unlocked later. If it needs setup, pre-populate a demo state for the reviewer.

3. 03

   Put it in screenshot one and the subtitle

   The product page is part of the "concept" Apple assesses. A listing that reads like the category leader undermines an app that isn't.

4. 04

   Tell the reviewer where to look

   In review notes, describe the differentiating feature and the exact steps to reach it. A 20-second screen recording link helps.

Reviewers respond to specifics. Adapt this to your case, keep it short, and only claim what's true in the build you're submitting.

Hello App Review team,

Thank you for the feedback on Guideline 4.3([a/b]).

What we changed in build [number]:
- [Merged our three city apps into this single app; cities are now an in-app choice.]
- [Rebuilt onboarding and the home screen; no template screens remain.]
- [New screenshots and description that describe our own features.]

What makes this app different from others in the category:
[One or two sentences: the method, audience or capability no other app offers.]

Where to see it:
1. Launch the app and [step].
2. [Step] — the [feature] appears on this screen.

[If applicable: We acquired this app from [seller] on [date] and have rebuilt [what] since.]

Thank you,
[Name]

Apple offers three routes beyond a normal reply. Choose based on whether the reviewer misread your app or read it correctly.

If the app is genuinely a variant of something you already ship, the fastest path is usually the one Apple suggests in the guideline itself: one app, with the variations inside it.