Your app is finished, the launch date is announced and the marketing team is ready. Then a rejection email arrives from Apple, citing a guideline number you have never heard of. Store review is one of the few parts of launching an app that you don’t fully control, but most rejections are predictable. With a little preparation, first-time approval is the normal outcome.
How review actually works
Apple reviews every iOS build with a mix of automated checks and a human reviewer who installs the app and tries it. Most submissions are reviewed within a day or two. Google Play leans more on automated checks, with human review for some apps; first submissions and policy-sensitive categories can take several days, while updates are often faster.
Google adds one step that catches many teams out. New personal developer accounts must run a closed test with at least twelve testers for fourteen days before they can publish to production. Organisation accounts avoid this, but need a D-U-N-S number and verified company details, which can take a week or more to arrange. Start that paperwork early.
Apple also asks organisations to enrol with a D-U-N-S number, and apps that handle money, health or other regulated services generally need to be published by the company providing that service, not an agency’s account. Publish from your own developer accounts from the start; moving an app between accounts later is possible but adds delay and paperwork.
The rejections we see most often
- No working demo account — if your app needs a login, give reviewers credentials and any OTP workaround, or they cannot test it.
- Crashes and placeholder content — an unfinished screen or a broken link is enough for a rejection under Apple’s completeness rules.
- Thin web wrappers — apps that simply load a website are often rejected for minimum functionality.
- Digital purchases outside in-app purchase — subscriptions and digital content generally have to use Apple and Google billing.
- No account deletion — if users can create an account in the app, they must be able to delete it from the app too.
- Privacy mismatches — your privacy labels and Data safety form must match what the app and its SDKs really collect.
Payments confuse many founders. Physical goods and real-world services, such as groceries, deliveries, rides or salon bookings, can use regular gateways like Telr, Checkout.com or a Tabby integration. Digital goods consumed inside the app, such as premium features, courses or coins, usually must go through in-app purchase, with Apple and Google taking a commission.
A checklist before you press submit
We run the same checks before every store submission. They take an afternoon, and they have saved our clients many lost days. Test on real devices running the oldest operating system version you support, on mobile data as well as Wi-Fi, and with the device language set to Arabic if you offer it, to catch layout and right-to-left problems.
Write clear review notes explaining anything unusual: location-based features that only work in the UAE, hardware the app connects to, or why you request camera or location permissions. Permission prompts need honest purpose strings that tell users exactly why access is needed. A vague message such as “We need your location” invites questions from reviewers.
Check the technical basics as well. Target the API level Google currently requires, build with a recent version of Xcode, remove debug menus and test endpoints, and point the app at production servers. Make sure push notifications, deep links and payment flows work in the release build, not only in debug, because the release build is what reviewers install.
Check your store listing too. Screenshots must show the real app, not mock-ups of features that don’t exist yet. Avoid mentioning other platforms in your iOS listing, keep keywords relevant, and make sure the support and privacy policy links work. Regulated categories, including finance, health and gambling-adjacent apps, may also need licences or extra documentation.
Reviewers aren’t trying to stop your launch. They just need to see an app that works, and is honest about what it does.
What to do if you are rejected
Read the message carefully, fix exactly what was cited and reply in the Resolution Center or Play Console with a short, polite explanation. If you believe the reviewer misunderstood, explain with screenshots or a short screen recording. Apple also offers a formal appeal. Arguing rarely helps; clarity almost always does. Plan a few spare days before any public launch date.
For urgent fixes after launch, Apple lets you request an expedited review, which is often granted for critical bugs, and Google Play supports staged rollouts so a problem reaches only a small share of users first. Neither replaces good preparation, but both are useful safety nets to know about before you need them.
The bottom line
App store review is predictable once you know the patterns. Set up your developer accounts early, give reviewers a working login, finish every screen, use the right billing for digital goods, support account deletion and keep your privacy declarations honest. Build a buffer of a few days into your launch plan, and review becomes a routine step rather than a crisis.
