Skip to content
Sebastian Weidlich

← All notes

App Store rejection under Guideline 4.3: what's behind it and what helps

· 2 min read

A rejection under Guideline 4.3 is one of the most frustrating messages App Review can send: the app works, it doesn’t crash, and it’s still rejected because Apple classifies it as “spam”. The causes can usually be narrowed down clearly.

What Guideline 4.3 covers

The App Review Guidelines group two cases under 4.3 (“Spam”):

  • 4.3(a): multiple bundle IDs for the same app. Variants, for example for individual locations, clubs or clients, should be bundled into one app.
  • 4.3(b): apps in categories that are already saturated, without a distinct, high-quality benefit of their own.

In practice, 4.3(a) is the common one. The reason given is then, in essence, that the app shares its binary, metadata or concept with apps from other developers and differs only slightly.

Typical causes

  • Code from templates and app builders. Apps built from the same template are very similar at the binary level. This stands out even more when sample texts, unused screens or stock assets are left in.
  • White-label apps. The same app is submitted for several clients under several bundle IDs, often from an agency’s developer account.
  • Submitted from the wrong account. Under Guideline 4.2.6, apps created from commercial templates or app generation services must be submitted by the provider of the app’s content itself, that is, from the client’s developer account, not the agency’s.
  • Interchangeable metadata. Generic descriptions and screenshots that could fit many apps reinforce the impression.

Related, but to be treated separately, is Guideline 4.2 (“Minimum Functionality”): it applies to apps that are little more than an embedded website.

What helps

  1. Read the rejection carefully. Is it 4.3(a), 4.3(b), or actually 4.2? That determines what has to change.
  2. Make the app distinguishable. Remove what’s left of the template, delete unused code and sample content, and put the app’s own features front and centre.
  3. Merge variants. Instead of many near-identical apps, one app in which users choose their location or organisation.
  4. Submit from the right account. A client’s app belongs in the client’s Apple Developer account.
  5. Rework the metadata. Description and screenshots show what exactly this app does.
  6. Reply in App Store Connect. Explain factually what the app does on its own and what has changed since the last submission. If you believe the decision is wrong, you can appeal to the App Review Board.

What rarely helps: resubmitting the same version unchanged.

If your app is stuck

I take over existing Flutter codebases and resolve App Store and Google Play rejections. For a first assessment, I look at the rejection, the codebase and the store accounts. Get in touch.