Why does Apple reject apps? My real rejections and how I fixed them

Apple rejects an app when it doesn’t meet its review guidelines: it crashes or has visible bugs, privacy information is missing, it asks for permissions the reviewer can’t verify, or Apple considers it too similar to another app (guideline 4.3, "spam"). Almost every rejection can be avoided by building the app with those rules in mind from day one.

I’ll walk you through my own cases. Publishing my games on the App Store, I got rejected three times for three different reasons, and I also had an app approved on the first try. Here’s what each rejection said, how I fixed it, and the checklist I’ve used ever since. If you’re after the basic fees and requirements of each store, they’re in what it costs to publish an app on Google Play and the App Store.

What is guideline 4.3, and why does it come up so often?

App Store guideline 4.3 targets "spam": Apple doesn’t want a store full of near-identical apps. The catch is that any developer who reuses code across apps (which is the sensible way to avoid paying for everything twice) runs the risk of a reviewer seeing two similar apps and treating them as copies.

Being different under the hood isn’t enough: the app has to look different and carry no leftovers from the other one. Two of my three rejections came from this rule, for quite different reasons.

Rejection 1: "too similar" (Color Sudoku Play)

Color Sudoku Play is a Sudoku where the numbers 1 to 9 are replaced by 9 colors. To me it was a different product; to Apple, it was too similar to Sudoku Play, my previous app. Swapping numbers for colors wasn’t enough differentiation.

The fix was a full redesign with its own visual system: glassmorphism, with layered gradients, translucent surfaces, blurred floating circles, and a cyan and coral palette that has nothing to do with Sudoku Play. The app was approved, and that redesign became its identity. Today it’s live on both the App Store and Google Play.

Rejection 2: "spam" because of copied IDs (Block Drop Merge)

Block Drop Merge mixes Tetris with 2048 and reuses a lot of code from Block Drop Play. Version 1.0.1 was rejected under 4.3(a), and when I dug in I understood why: the AdMob ad unit IDs were Block Drop Play’s, test ads had been left switched on in production, some storage keys and in-app purchase product codes belonged to another app, and the icon was generic.

I audited the whole codebase for every trace of the other app, fixed all the IDs, redesigned the icon (numbered blocks in an L shape), made new screenshots, and sent Apple a formal reply. Version 1.0.2 went back into review, and that rejection gave me an audit protocol I now run before every derived launch.

Rejection 3: "we can’t find the permission prompt" (Color Match Drop)

For Color Match Drop, Apple couldn’t find the App Tracking Transparency prompt, the one asking whether you allow the app to track you for advertising. The prompt was implemented correctly. The real issue: the reviewer’s iPad had "Allow Apps to Request to Track" turned off system-wide. With that setting off, iOS never shows the prompt, for any app.

I resolved it without changing code or uploading a new build: I replied to Apple explaining the scenario. The lesson is that not every rejection is your fault, and a clear, technical reply is a tool too. I documented the procedure for future apps.

And the one approved on the first try?

Block Puzzle Play was approved by Apple on its first review. It wasn’t luck: I prepared it systematically. I declared every piece of data the app collects, double-checked the bundle IDs, published app-ads.txt for advertising, completed the age rating, and sorted out everything privacy-related: ads, crash reporting, and Google and Apple sign-in. In other apps I also added a privacy policy, terms, and in-app account deletion.

What do I check before submitting an app to Apple?

• Nothing left over from another app: ad unit IDs, purchase product codes, storage keys, names, and icons.
• Test ads switched off in the production build.
• The app looks different from the very first screenshot if it shares a base with another one.
• Complete privacy info: what data is collected and why, an accessible privacy policy, and a way to delete the account.
• Permissions explained: every permission needs a clear reason, and the tracking prompt must appear before showing personalized ads.
• Native plugins declared: in Sudoku Play, the purchases library was missing from the config and the iPhone build shipped without the subscriptions entitlement.
• A complete listing: an original icon, current screenshots, a description that matches what the app does, and an age rating.

What did I learn from Google Play?

On Android, my headaches were technical. On Samsung phones, the background sync task crashed the app before it even started, so I switched to syncing when the user reopens the app. On Huawei devices and emulators without Google services, the app crashed: I added a check for those services before using them. And on Samsung, the Sudoku notes grid rendered wrong because the system laid out elements differently; I replaced it with a fixed 3×3 structure.

The lesson: test on real phones from several brands before publishing. The emulator won’t show you what your users will run into.

Does every fix need to go through review?

No. With Expo, fixes to the JavaScript code can be pushed straight to users as over-the-air (OTA) updates, bypassing the store. One catch: on Block Drop Merge I sent updates to a testing channel and they never reached users, because production builds listen to the production channel. Once aligned, urgent fixes go out in minutes. Anything that changes the native layer, like adding a permission or a library, still needs a new build and another review.

The full story of how I published my first apps is in how I published 6 apps as a solo developer, and why reusing code forces you to watch these details is in how to reuse code across apps.

Frequently asked questions