A launch date slips for a reason nobody planned for surprisingly often: the app is finished, the client has signed off, and the store says no. Review rejections are rarely about bugs. They are about policy, metadata and account details that were nobody's job until the day of submission.
This article lists the rejections we see, the checklist we run before pressing submit, and how we schedule a release so a rejection is a one-day delay instead of a missed date.
Why apps get rejected
Apple publishes its App Review Guidelines and Google its Developer Program Policies, and both are long. In practice a small set of rules accounts for most rejections of business apps.
The reviewer cannot get in. An app with a login and no test account, or a test account that has expired, is rejected the same day. The review notes need working credentials for every role the reviewer might need, and a short explanation of what the app does for whom.
The app does too little. Apple's minimum functionality rule turns away apps that are a website in a frame, or a single form with nothing else. A business app that mostly repeats the web experience needs something that justifies being an app: offline use, notifications, a device feature.
Account creation without account deletion. Apple requires an app that creates accounts to let users delete them from inside the app, and Google has an equivalent requirement plus a web link for deletion. This is the rejection that surprises product owners most, because deletion touches the backend, the data retention policy and the support process, not just a screen.
Third-party sign-in without Sign in with Apple. If the app offers Google or Facebook login, Apple expects Sign in with Apple as an option too, with a few exceptions such as apps that use only a company's own enterprise login.
Permissions without a reason. Every iOS permission prompt needs a purpose string that says what the app will do with the camera, the location or the contacts, in plain words. Android needs a prominent disclosure for sensitive permissions such as background location, and a policy declaration in the console. A generic string, or a permission the app does not visibly use, is a rejection.
Privacy labels and the data safety form that do not match the app. Apple's privacy details and Google's data safety section have to match what the app and its SDKs actually collect. Analytics and crash-reporting SDKs collect more than teams expect. We fill these forms from the SDK list, not from memory.
Payments outside the rules. Digital goods and subscriptions sold inside the app must use the store's billing on both platforms, with narrow exceptions that vary by region and change over time. Physical goods and services delivered outside the app may use your own payment provider. Getting this wrong is a rejection, and getting it wrong at scale can suspend the account.
Placeholder content. Lorem ipsum, "coming soon" screens, empty states with no copy, or a version string that says 0.0.1 all signal an unfinished app.
The checklist we run before submission
The list below is what we go through for every release, not just the first. It takes an hour when the items are already true and a week when they are not, which is why it runs before the build is cut.
- A test account per role, with a note on what the reviewer should try, in the review notes on both stores.
- Account deletion working inside the app and documented in the notes, with the deletion web link on Google Play.
- Every permission prompt with a purpose string a non-technical person understands, and no permission the app does not use.
- Privacy details and the data safety form filled from the current SDK list, and matched against the privacy policy URL.
- Sign in with Apple present wherever a third-party login is.
- Payments routed correctly: store billing for digital goods, your provider for physical goods and services.
- Screenshots from the current build on the required device sizes, with no device frames or claims the app does not make.
- App name, subtitle and description without competitor names, unsupported claims or keywords stuffed into the title.
- Support URL and privacy policy URL that load and are current.
- Crash-free on a fresh install, on a mid-range Android phone and the oldest iOS version the app supports, with the network off and on.
- Version and build numbers incremented, and the release notes written for people rather than for the changelog.
How to schedule a release so a rejection costs a day
Review times are usually under two days on both stores now, but a rejection restarts the clock, and holidays slow it down. The schedule that works:
- Submit to TestFlight and Google's internal testing track first, at least a week before the date. Internal testers find what the reviewer would.
- Submit the release build for review at least three working days before the planned launch, with manual release selected so approval does not mean a surprise launch.
- Use a staged rollout on Google Play, starting at a small percentage, and watch crash rates for a day before going to full.
- Keep the previous build ready to re-release, and know who can approve a hotfix at the weekend.
If the app is rejected, reply in the resolution centre with the specific fix rather than an argument. Most rejections are resolved in one round when the reply is precise.
Who owns the accounts
Publish under your own developer accounts, with your company as the legal entity, from day one. Moving an app between accounts later is possible but slow, and reviews, ratings and subscriptions do not always survive it.
Keep the signing keys and certificates in your own secure store as well. An app whose upload key lives only on a contractor's laptop is an app you cannot ship without them.
What this means for the plan
Store review belongs in the launch stage of the process, with its own checklist and its own dates. When we scope a mobile app, the release plan includes the internal test window, the review buffer and the staged rollout, and the account setup is a discovery task with your name on it. That is how a rejection becomes a day, not a week.
