Getting an app approved: the checklist we run before every submission
The rejections we have actually received from Apple and Google, turned into a checklist that runs before any build goes up.
We have shipped seven apps to the App Store and several to Google Play under our own name, plus client apps. Every rejection we ever got is now a line in a script that runs before submission. This is the human version of that script.
Before you build the binary
Most rejections are decided before the reviewer opens the app.
- A demo account with real-looking data in the review notes, for anything behind a login.
- A privacy policy URL that loads, and a delete-account path inside the app.
- Every paywall price traced to a real store product, not a placeholder string in code.
- Subscription terms visible on the paywall: price, period, and how to cancel.
- A link to the terms of use for any app with subscriptions.
Permissions
Every permission needs a plain sentence saying why, shown before the system prompt. Google is strict about location and requires a prominent disclosure screen inside the app, not just the store listing. One of our Android releases was rejected for exactly that and approved the next day once the screen existed.
Every rejection we ever got is now a line in a script that runs before submission.
Screenshots and listing
Screenshots are per device size on Apple, and the store serves the largest size you populated. Populate one size fully rather than several half done. Keep the listing text free of other platforms' names. Do not promise features the build does not have.
Android specifics
Target the API level Google requires this year, use the current billing library, and verify both by inspecting the built artifact, not the config file. Stale test tracks block production updates, so clean them up first.
After approval
Released metadata is locked. Fixing a screenshot means a new build and a new review. Get the listing right before the first approval and you save yourself a week later.
Want this built for your business?
One call. A written scope, fixed price and ship date the next day. A working version in your hands by the end of week one.
Online pickup ordering for a bakery, butcher or candy shop: what you actually need
What online ordering should do for a shop that sells over a counter, what it should not do, and how to tell if your shop is ready for it.
Over-the-air updates: why your app can be fixed today instead of next week
How a fix reaches your customers' phones without waiting for an App Store review, what it can and cannot change, and why it matters when you pick a developer.