App Store and Play Store submission: avoiding the last-minute rejection

An app store submission checklist is the difference between launching on the date you promised and explaining to your board why the app is stuck in review. Apple and Google reject apps for a short, well-documented list of reasons, and nearly all of them can be prevented weeks before submission if someone owns them. This article sets out the common rejection reasons, what each store expects, how to prepare the review package, and how to schedule submission so that a rejection is an inconvenience rather than a missed launch. It applies whether the app is native or built with React Native.

Why apps get rejected at the last minute

The pattern is always the same: the build is finished on Thursday, submitted on Friday, and rejected the following week for something that has nothing to do with the code. The reviewer could not log in because there was no test account. The app asks for location without saying why. The privacy questionnaire says one thing and the analytics SDK does another. There is no way to delete an account. The screenshots show features that are not in the build. Each of these is a compliance requirement, and compliance is scope: it belongs in the plan alongside features, with an owner and a deadline.

Common rejection reasons and how to prevent them

Privacy labels and the data safety form

Apple's privacy nutrition labels and Google's data safety section require you to declare what data the app collects, whether it is linked to the user, and what it is used for. The forms are simple; the work is knowing the truth. Every SDK in the app (analytics, crash reporting, advertising, push, payments, maps) collects something, and the declaration must cover all of it. We keep an SDK inventory from the first sprint with each SDK's data collection noted from its documentation, and fill the forms from that inventory. A mismatch discovered by a reviewer, or later by a user, is worse than a longer label. Apple's App Review Guidelines and Google's Play policy centre are the primary sources and change several times a year, so someone reads them at kick-off and again before submission.

Permissions: request in context, work when denied

Reviewers test what happens when a permission is refused. If the app blocks or crashes, it is rejected. Each permission needs a purpose string that says what the feature does with it in plain language, requested at the moment the user tries the feature, with a graceful path when it is denied. Location for a delivery app is requested when the user first tracks an order, not at launch. Camera for a document upload is requested when they tap upload. This is also better product design, so it rarely costs anything to do properly.

Payments and the in-app purchase line

Both stores require digital goods and services consumed inside the app (subscriptions to content, premium features, virtual items) to go through their in-app purchase systems, while physical goods, real-world services, and business-to-business transactions can use your own gateway. Apps that sell both must draw the line correctly, and apps in India that add UPI or wallet flows must be clear about what is being purchased. Misclassifying a digital feature as a service is a common and slow rejection. Classify every purchasable item at design time and, if there is any doubt, ask the platform's developer support before building. Our mobile payments guide covers the gateway side.

Test accounts, review notes and demo mode

The single most avoidable rejection is a reviewer who cannot get past login. Provide a demo account with realistic data, a way to bypass OTP for the review phone number, and notes that explain anything unusual: a B2B app that needs an organisation code, a field app that needs a job assigned, a fintech app that needs KYC. If the app depends on hardware or a physical location, record a video walkthrough and link it in the notes. Test the credentials on a clean device the day before submission, because expired demo accounts are a classic.

Schedule submission as a project phase

Review times vary and rejections add days, so the submission plan starts weeks out. A first internal build goes to TestFlight and Play internal testing early, so the store accounts, certificates, signing and metadata pipeline are proven before the real build exists. The release candidate is submitted with margin before the announced launch date, and a manual-release setting so an approved build can be held until the marketing moment. Phased rollout on Google and staged release on Apple limit the blast radius of a bug in the first days. Someone on the team is named as the store owner, with the developer accounts, agreements and tax forms in order, because an expired agreement blocks submission as surely as a bug.

Store account hygiene

• Developer accounts owned by the company, not an individual engineer
• Agreements, banking and tax information accepted and current
• Signing keys and certificates stored in a managed secret store with a rotation plan
• Privacy policy and support URLs live and matching the app's behaviour
• Age rating questionnaire answered from the actual content
• Export compliance and encryption declarations prepared

A worked example

A field-service SaaS company planned a customer launch of its technician app to coincide with a trade event. Two weeks before the date, the first submission was rejected on three grounds: the reviewer could not log in without an organisation code, location was requested at launch with a generic purpose string, and account deletion was absent because accounts were created by administrators. We added review notes with a demo organisation, moved the location request to the first job with a specific rationale, and built an in-app deletion request that triggered backend erasure with administrator notification. The resubmission was approved, but only because the team had left margin. On every project since, those three items have been in the first sprint. The in-app copilot for a B2B SaaS case study is the same company's product; the store work was unglamorous but decided the launch.

Team and timeline

Store compliance is a workstream inside the mobile build rather than a separate team: the product manager owns metadata and policy reading, a mobile engineer owns permissions, deletion and the SDK inventory, the designer produces screenshots from the release build, and QA runs the review-simulation pass on clean devices. It is included in our React Native mobile development service from $17,500 / ₹11.2L, with a fixed UI/UX design engagement from $5,500 / ₹3.6L when store assets and onboarding need dedicated design. Ongoing policy changes and OS upgrades are handled under an Essential Care Plan at $1,000 / ₹68,000 a month. See the pricing page.

Before you start: a checklist

• Read both stores' current guidelines at kick-off and note category-specific policies
• Create the SDK inventory with each SDK's data collection
• Write purpose strings and denied-permission behaviour with each feature
• Build account deletion alongside account creation, including backend erasure
• Classify every purchasable item as digital or physical before building checkout
• Set up demo accounts, OTP bypass and review notes in the first sprint
• Push an early build through TestFlight and Play internal testing to prove the pipeline
• Submit the release candidate with margin and hold release manually

Glossary

• Privacy nutrition label: Apple's declaration of data types an app collects and how they are used
• Data safety section: Google Play's equivalent declaration
• Purpose string: the text shown when an app requests a permission, explaining why
• TestFlight and internal testing: pre-release distribution channels on Apple and Google
• Phased or staged rollout: releasing an update to a percentage of users first
• Manual release: holding an approved build until you choose to publish it

Related reading

Read React Native vs Flutter vs native for the framework decision that precedes any submission, crash-free sessions: the metric that predicts app reviews for the stability target before you submit, and push notifications that users keep on for the notification permission that reviewers also test.

Treat store compliance as scope with an owner from week one, submit with margin, and the rejection email becomes a minor edit rather than a missed launch.