Guideline 4.3(a) – Design – Spam: why App Review thinks your app is a template, and how to answer

“Guideline 4.3(a) – Design – Spam. We noticed your app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences.” If you got this sentence, the frustrating part is that it is not about a bug. Nothing is broken. A reviewer looked at your app for a few minutes and decided it is one of many near-identical apps. This article is about what they are actually comparing, why honest apps get caught, and the two things you can do: change the signals, and write the reply that works.

What 4.3(a) says, and what it means in practice

The guideline text is short: don't create multiple bundle IDs of the same app, don't submit apps that are simply a re-skin of a template or app-generation service, and if you have several apps for different locations or teams, consider a single app with a picker. Since 2025 Apple split the reasons into (a) “similar binary, metadata and/or concept” and (b) the app-generation-service case. In practice 4.3(a) is triggered by three comparisons, in this order:

• Binary similarity. App Review has tooling that fingerprints builds. Two apps shipped from the same starter kit with the same bundle layout, the same frameworks, the same asset catalog and only a different accent color look identical to it — regardless of how different the backend is.
• Metadata similarity. Same screenshot layout, same description skeleton, same keyword field, same support URL pattern across several apps or several developer accounts.
• Concept saturation. Categories with hundreds of functionally identical apps: flashlight, QR scanner, wallpaper packs, calculator, “AI chat” wrappers, horoscope, white noise. Here the bar for “what is different about yours?” is much higher.

Why honest apps get flagged

Most 4.3(a) rejections we see from solo developers are not spam at all. They come from a build that still carries the fingerprint of the template it was started from. The reviewer never reads your code; they see the outside of the binary, and the outside says “starter kit”. The usual signals:

• A placeholder-style bundle identifier: com.example.*, com.yourcompany.*, org.reactjs.native.example.*, com.anonymous.* (the Expo default when no owner is set), host.exp.*.
• The project name still in the bundle: CFBundleName or the executable is TemplateApp, MyApp, expo-template-blank, or the boilerplate's name.
• Template markers left in the JS bundle or resources — starter-kit component names, demo screens that are still reachable, sample images from the kit.
• A first screen that is generic: a stock onboarding carousel with three slides of lorem-ipsum-grade copy, then a paywall. Reviewers see hundreds of these a week.
• Store listing built from the same skeleton as other apps: identical screenshot frames, the same three-bullet description, a support page that is a Notion doc.
• Several apps on the same account (or the same DUNS) that differ only in name and color. This is the case Apple actually means, and the only fix is to merge them.

Step 1: remove the signals before you resubmit

Do this even if you are convinced the app is original — every signal you remove is one less thing the next reviewer can point at. A resubmission with the same binary and a strongly worded note almost always comes back with the same rejection.

1. Bundle identifier. Use your own reverse-DNS id: com.yourbrand.appname. In Expo that is ios.bundleIdentifier in app.json; in Xcode it is the target's *Bundle Identifier*. Changing it before the first release is free; after release it is a new app, so decide now.
2. Names. Set CFBundleDisplayName, CFBundleName and the target name to the real product name. Rename the Xcode project if it is still the template's name.
3. Dead template screens. Delete the demo screens, sample data, and starter components you are not using. If a reviewer can tap into a “Welcome to your new app” screen, you are done.
4. First-run experience. The first screen must show what the app *does*, with your own content, not a generic carousel. If you need onboarding, keep it to one screen and make it specific.
5. Listing. Write the description around the one thing your app does that the category does not. Screenshots with real content, not the same three device frames every template ships with.
6. Multiple apps. If you have several near-identical apps, 4.3(a) is telling you to make it one app with a selector. There is no wording that gets around this one.

Step 2: the reply that works

Reply in App Store Connect (the Resolution Center thread), not with a new binary alone. Reviewers can approve on the strength of a reply when the app is genuinely distinct. Keep it short and concrete; “my app is unique” is what every spam submitter also writes. A structure that gets responses:

Thank you for the review. This app is not a re-skin of a template or another app.

What is unique: <the one feature or dataset no other app in this category has — one sentence, verifiable in the app>.
Where to find it: <screen name / tap path>.
Ownership: the app is developed and published only by <your name / company>; we have no other apps with this concept.
Changes in this build: bundle identifier and app name are now our own, template demo screens were removed, the first screen shows <real content>.

Please let us know if any specific part of the app appears similar to another app so we can address it directly.

Two things to avoid in the reply: arguing that the guideline should not apply to you, and pasting a long feature list. One verifiable, specific difference beats twelve generic ones. If the second review still comes back as 4.3(a), file an appeal with the App Review Board with the same specifics — appeals on 4.3(a) do succeed when the app is original, but they take one to two weeks.

Check the binary before you upload

The bundle identifier, the bundle name and the starter-kit markers are all sitting in the .ipa you are about to upload. RejectProof reads the build in your browser and lists the 4.3 signals it finds — placeholder bundle id prefixes, template markers, generic names — alongside the other 40-plus checks (privacy manifest, purpose strings, sign-in rules, dead links). The free check shows every finding; the full report is what to change for each. You can also run it from the terminal: npx rejectproof MyApp.ipa.

4.3(a) is a judgment call, so no scanner can promise a pass. What it can do is make sure the reviewer's first impression of your binary is “this is someone's own app”, which is most of the battle.