Why a First App Submission Gets Rejected, on Both Stores

A first app submission usually fails for a reason that has nothing to do with how the app was built. The binary works, the designs are signed off, the team has tested it for weeks, and the rejection arrives anyway because a reviewer could not log in, or the privacy policy existed in only one of the two places it has to exist, or the Google Play account had never run the closed test that now stands between a new developer and production. These are process requirements, they are published, and they are all checkable before you submit.

Apple checks whether the submission is complete before it checks anything else

Section 2.1 of the App Review Guidelines, read on 22 September 2026, is called App Completeness, and it is the first substantive gate. It asks for final versions with all metadata and working URLs, and it is explicit about what gets thrown out: Apple states that "we will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems".

The same section carries the requirement that catches the largest number of first-time teams, and it is a single parenthetical: "Include demo account info (and turn on your back-end service!) if your app includes a login". A reviewer who cannot get past your sign-in screen has seen nothing of the app. Apple also allows for the case where credentials cannot be shared, stating that a built-in demo mode may be used "in lieu of a demo account with prior approval by Apple".

“Placeholder text, empty websites, and other temporary content should be scrubbed before submission.”

Two practical failures hide inside that sentence. The first is the staging URL that is still wired into a Help or Terms link. The second is the back end that is only reachable from the office network, which looks like a working app to your team and like a dead app to a reviewer in another country. Turn the service on, from outside your own network, before you submit.

If the app sells anything, section 2.1(b) adds that in-app purchases must be "complete, up-to-date, visible to the reviewer and functional". A purchase flow that is gated behind a feature flag your reviewer cannot reach is an incomplete submission, not a clever rollout.

The account deletion rule, and why it now applies on both stores

If your app lets a user create an account, both stores require a way to delete it, and the two requirements are not identical. Apple states the rule plainly in section 5.1.1(v): "If your app supports account creation, you must also offer account deletion within the app". One path, inside the app.

Google Play asks for two. Its account deletion policy, read on 22 September 2026, requires developers to "provide users with an in-app path to delete their app accounts and associated data" and, separately, to "provide a web link resource where users can request app account deletion and associated data deletion". The in-app path must be prominent, for example within account settings, and the web page must reference the app or developer name and make the request route easy to find.

Apple is equally specific about where the privacy policy lives. Section 5.1.1(i) requires "a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner". Teams routinely do the first and forget the second, because the store listing is the part that feels like submission paperwork and the in-app link feels like a design decision.

Google Play’s newer blocker: twelve testers for fourteen days

This one surprises teams because it is not a code requirement at all, and it can add a fortnight to a launch plan that nobody budgeted. For new personal developer accounts, Google Play requires, read on 22 September 2026, that the developer "run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days" before applying for production access.

The word doing the damage is "continuously". A tester who opts out and rejoins restarts their own fourteen day clock, so a group assembled loosely from colleagues and friends can quietly fail the count on day thirteen. Recruit more than twelve, tell them explicitly not to leave the test, and check the opt-in count before you start counting days rather than after.

Sequence this early. If the app is due to launch alongside a campaign, the closed test has to begin at least two weeks before the production submission, which in practice means before the app is finished. Plan it as a schedule dependency in the same way you would plan a penetration test or a security review, not as a formality at the end.

A pre-submission checklist you can run in an afternoon

None of the following requires a tool. It requires someone who did not build the app to try to use it the way a reviewer will, on a device that is not a developer machine, on a network that is not your office.

• Log in as the reviewer will. Use the demo credentials you are about to submit, on a clean device, from outside your network, with the back end in the state it will be in on review day.
• Open every link in the app and the listing. Terms, privacy, support, marketing URL. Any staging host or empty page here is a completeness rejection.
• Find account deletion in under thirty seconds. In the app for both stores, and on a public web page for Play. If it takes you longer, it is not prominent.
• Exercise the purchase flow. Visible, reachable and functional for a reviewer who has none of your feature flags.
• Check the Play tester count and the fourteen day clock before you apply for production access, not after.
• Run the app cold on a low-end device. Crashes and obvious technical problems are named in the guidelines as grounds for rejection.

Most of these are cheaper to fix than to appeal. A rejection costs a review cycle, and a resubmission puts you back in the queue behind everyone else, which is why the teams that ship on schedule are usually the ones that treated the store requirements as part of the definition of done rather than as a step after it.

If you are still choosing the stack for the build itself, our notes on React Native with Expo and EAS cover the build and submission pipeline these requirements sit on top of. And if you would rather hand the whole release path to a team that has been through it, talk to us about the build.