On this page (11 sections)
4.3(a) and 4.3(b)
- 4.3(a) — Do not create multiple bundle IDs of the same app; apps that differ only by content, brand, language or location should be a single app (using in-app pickers or purchases). This is the white-label / reskin clause.
- 4.3(b) — Do not submit apps that are indistinguishable from what is already widely available. The guideline now names well-established categories — dating, flashlight, sound effects, wallpaper, simple timers and fortune telling — where Apple will not accept new submissions unless they offer a “meaningfully different or improved experience”, and it adds that such apps may be removed later if they are not updated, improved, or do not attract customers. Low-effort categories (drinking games, fart/burp apps and similar) are called out separately, and repeated submissions of that kind can lead to removal from the Developer Program. This is the “too many of these already” clause, and since 2026 it is also a post-approval risk, not only a submission-time check.
The message usually says which sub-clause applies. It changes the remedy: (a) is about your portfolio and duplication; (b) is about the app’s place in the store.
Who gets hit
- White-label apps — one codebase, many client brands, many bundle IDs.
- Agencies publishing similar apps for restaurants, salons, gyms, schools or churches from one account.
- Purchased templates and app-generator output with a new name and colour.
- Similar binaries, metadata or concepts across accounts — Apple compares code signatures, screenshots and descriptions, not just names.
- Saturated categories — simple utilities and games named in the guideline.
Multiple developer accounts do not solve similarity
Publishing the same app from different developer accounts to avoid 4.3(a) is visible to Apple (shared code, assets, backend endpoints, screenshots) and is treated as an attempt to circumvent the guideline. It can affect all the accounts involved. The client-owned-account route is legitimate only when the apps are genuinely different products.
4.3 vs 4.2 vs 4.2.6
| Guideline | Concern | Remedy direction |
|---|---|---|
| 4.3 Spam | Too similar to other apps / too many of the same | Differentiate meaningfully or consolidate |
| 4.2 Minimum Functionality | Too little functionality | Add real functionality |
| 4.2.6 Commercialised template / app generation | App created from a commercialised template or generation service should be submitted by the content provider | Client submits under their own account, or the app is substantially customised |
Cosmetic differentiation is weak
Icon, colours, logo, name and a few strings do not differentiate an app in Apple’s terms. Reviewers look at functionality, content, audience and purpose. If two apps do the same thing for the same kind of user with the same screens, they are the same app.
What meaningful differentiation looks like
- Different core functionality or workflows, not just different data
- Content that is unique and substantial to that app
- A distinct audience with features they specifically need
- Integrations (hardware, services, back-office systems) unique to that client
- Store listing that describes the specific product, not the platform it was built on
Multi-tenant and picker architecture
For genuine white-label businesses the durable answer is often one app: users pick their brand, location or organisation inside the app (a picker, a code, an invite link or an account), and the app loads that tenant’s content and configuration. Apple explicitly points to this model in 4.3(a). It usually means backend work — tenant resolution, configuration delivery, theming, push segmentation — which is engineering we can do.
Build a comparison matrix before you reply
| Dimension | This app | Similar app(s) Apple may be comparing to |
|---|---|---|
| Core functionality | List the specific functions | List theirs |
| Content | What is unique and how much | What overlaps |
| Audience | Who specifically | Who they serve |
| Integrations | Hardware, APIs, services | Theirs |
| Codebase / template | Custom, or template plus what customisation | Template origin |
If the matrix shows real differences, use it in your reply or appeal. If it does not, you have your answer: differentiate or consolidate.
Appeal vs restructuring
- Appeal when the app is genuinely distinct and you can show it with the matrix and screenshots.
- Restructure (single app with a picker, or client-owned submissions of substantially customised apps) when the portfolio really is many copies of one product.
- Do not resubmit with a new icon, a new bundle ID or from another account.
Portfolio audit
If you publish many apps, review the whole portfolio before responding to one rejection. A 4.3 finding on one app is often a signal about the account. Consolidating proactively is far less painful than a wave of rejections or removals.
What we can implement
Portfolio and similarity audits; multi-tenant restructuring (tenant resolution, remote configuration, theming, per-tenant push and analytics); genuine functional differentiation on iOS native, Flutter and React Native; and an evidence-based comparison for a reply or appeal.