Why the App Store and Google Play reject a build: rejections I've dealt with

Whenever I finish a game or an app, one question stays with me: what will the reviewer see when they open it? I've had store rejections on my own products and on clients' projects. Most of the time the cause isn't a big bug; it's that what the reviewer sees differs from what I expected.

The two examples below are from October this year, from an app that creates photos with AI.

Rejection 1: the permission prompt never showed

The app declared in its App Store privacy details that it tracks users for ad measurement. Under Apple's rules, the system tracking permission prompt (ATT) then has to be shown. The build was rejected: the reviewer never saw that prompt.

When I found the cause, it turned out to be a design decision. The prompt appeared only after the user turned on "Ad measurement" in the privacy preferences and saved. That preference was off by default. The reviewer never opened that setting, so the prompt never opened either. On top of that, the review was done on an iPad Air.

The fix: the prompt now shows unconditionally the first time the home screen opens, after the intro screens. The setting in the privacy preferences is filled in from the answer. If permission isn't given, ad measurement never starts.

Review 2: "Information Needed" and two bugs found while recording

On another build, Apple asked for more information: a screen recording showing how the app is used, and a written explanation. While recording, two bugs came up.

• Saving photos didn't work. In the new version of the Expo package in use, the old functions threw an error when called. The app switched to the package's legacy interface, and a message that opens the settings was added for when gallery access is denied.
• Credit packs didn't load. The code looked for the packs under a specific name in the purchase dashboard, while the packs had been added to the default list. The code now looks in both places.

Apple asking for more information meant these two bugs were found before users found them. That's why recording the app before submitting, without waiting for a review to ask, is a good habit.

What I check before submitting

App Store:

• No empty screens. Placeholder screens that say "coming soon" are a reason for rejection. In a social app, that's why we actually built the feed screen that was in scope before release.
• An alternative to third-party login. If the app lets people sign in with a third-party account, it should also offer an alternative sign-in that meets Apple's rules.
• Personal data and AI. If user data goes to a third-party AI service, explicit permission is asked for first.
• Opening it on an iPad. Even if the app is made for phones, the review can happen on an iPad.

Google Play:

• Closed testing. New personal developer accounts need a closed test with at least 12 testers running for 14 days before a production release. That time belongs in the schedule from the start.
• Target API level. Google Play requires apps to target recent Android versions; a new build with an old target can't be uploaded.

Store rules change from time to time, so I check the details against the stores' current documentation every time.

What stayed with me

Most rejections come from the reviewer using the app differently than I do. They may never open the settings, they may use an iPad, they may skip everything on first launch. That's why using the app before submitting as someone who has never seen it helps a lot. A rejection often shows ahead of time a problem a user would also run into.