Guideline 4.3: Design — Spam
4.3 is the rejection that indie developers find hardest to answer, because unlike 2.1 or 5.1.1, nothing is mechanically wrong with your build. The message reads:
Guideline 4.3(a) - Design - Spam
We noticed your app provides the same feature set as other apps submitted
to the App Store by you or another developer. Submitting similar or
repackaged apps can dilute the App Store and hinder discovery.Be honest about which 4.3 you got
There are two, and they need different responses.
4.3(a) — duplicates and repackaging. You, or a developer whose code you share, shipped something Apple considers the same app. This fires on:
- Multiple bundle IDs of one app — a per-city, per-team, per-client, or per-school variant of the same binary.
- Template or app-generator output. If you built the app from a commercial template, dozens of other submissions share its structure, and Apple fingerprints that.
- A "lite" version that isn't meaningfully different from the paid one.
- Code you reused across your own catalogue closely enough that the review system matches it.
4.3(b) — saturated categories. The guideline names them outright: flashlight, fortune-telling, drinking-game, soundboard, basic-utility apps. Apple's position is that the category is full and your entry has to justify its existence. A generic todo list, QR scanner, or unit converter with no distinguishing idea gets caught here.
Apple's own remedy for 4.3(a) is in the guideline text: ship one app and use in-app purchase or configuration to cover the variants, instead of one binary per variant.
Why it hits legitimate apps
Two structural reasons, both worth understanding before you write your appeal.
The first pass is automated and similarity-based. It compares binary structure, asset hashes, metadata, and screenshots against the store. A developer with several apps that share a design system and a networking layer looks, to that system, like a repackager.
The second is that 4.3 is applied at the account level. It can surface on an update to an app that shipped fine for years, if something else in your account or a template you used got flagged in the meantime.
Responding to it
4.3 is one of the few rejections where replying is usually more productive than resubmitting.
- Reply in Resolution Center first, before changing anything. Ask which apps yours was matched against. They don't always say, but the answer reshapes your response entirely.
- State the difference in user terms, not technical ones. "Different target audience", "different data set", "solves a different job" — reviewers respond to product distinctions, not to "we rewrote the view layer."
- If you do have near-duplicates in your account, consolidate. Merge the variants into one app with in-app selection. This is the outcome Apple wants, and it usually ends the thread.
- If the app is genuinely distinct, appeal. The App Review Board handles 4.3 appeals and a well-argued one is often granted. Attach screenshots that show what makes the app different.
- Distinguish the metadata too. Screenshots and description that look like every other app in the category feed the similarity match. Distinct visual identity is a real defence.
What no tool can do for you
Nothing scans your project and tells you whether Apple will consider your app a duplicate. That judgment happens against Apple's index of every app on the store — data you don't have. Any tool claiming to predict 4.3 is guessing, and AuditStore doesn't try.
What it can do is make sure a 4.3 dispute isn't compounded by a second, purely mechanical rejection while you're arguing. A resubmission that comes back again — this time for a missing purpose string or an empty screenshot set — costs you another full review cycle at the worst possible moment. AuditStore audits the Xcode project, metadata and review information so the rest of the submission is clean while you handle the part that needs a human.
One thing that is mechanical and does relate to 4.3(a): if you're shipping per-client or per-region variants, the bundle-match cross-check confirms each build attaches to the app record you intended — a mismatched bundle ID in a multi-variant setup is its own separate mess.
Related
- Guideline 2.3: Accurate Metadata — screenshots and description, which feed the similarity match
- Guideline 2.1: App Completeness
- Xcode Project checks