Getting an app approved has a reputation for being arbitrary and painful. It's mostly neither, once you know what they're checking.
Rejection is common on a first submission and it's rarely fatal. Most rejections are about wording, a missing page, or a box you filled in wrong, and the fix takes an afternoon.
The upfront costs
Apple charges $99 a year to keep an app listed. Google charges $25 once.
Apple review usually takes a day or two now, sometimes longer around holidays. Google is often faster but has become stricter, and new developer accounts sometimes face extra checks that add weeks.
Neither is instant, which matters if you've told anyone a launch date.
What they actually check
Less about code quality than people assume. Reviewers are looking at a handful of things.
Does it work? A crash on launch, an obviously broken feature, or a login they can't get past is the fastest rejection there is.
Is it substantial? Something that's essentially a website in a wrapper, or too thin to justify existing as an app, gets turned down. This catches a lot of first attempts.
Does the payment work the way they require? If you're selling anything the user consumes in the app, it goes through their payment system, and going around it is taken seriously.
Does the privacy declaration match reality? You fill in a form about what data you collect, and it needs to be true, including data collected by libraries you added without thinking about it.
Is there a way to delete an account? If people can sign up in the app, they have to be able to delete from inside the app too.
Does the description match the app? Claims in your listing that the app doesn't deliver are a rejection.
Rejection is usually about words
The most common rejections aren't technical.
Your description promises something the reviewer can't find. Your screenshots show a version that doesn't exist. Your app claims to diagnose, treat, or cure something, which puts you in medical territory with a much higher bar. You mention another platform by name in a way they dislike.
Which means reading your own listing as a suspicious stranger catches most problems. Every claim should be visible in the app within a minute of opening it.
If they do reject you, they say why, and you can reply. A polite message explaining where the feature actually is resolves a surprising number of them without changing any code.
Give the reviewer a way in
If your app needs an account, provide test credentials in the review notes. A reviewer who can't get past your login screen will reject you for being broken, and they won't sign up.
If a feature is buried, say where it is. The notes field is free and reviewers read it. Treating it as a note to a colleague who has two minutes works well.
What you need ready
Gathering these before you start saves a lot of stopping and restarting.
Icons at the required sizes. Screenshots for several device sizes, which is more tedious than difficult. A description, a subtitle, and keywords. A privacy policy URL that's live. A support URL that's live. The privacy declaration answers. And your test account.
Ship a beta first
Both stores let you distribute to a limited group before going public, TestFlight on iOS and internal testing on Android.
Worth doing even with five people. It's the same build process and the same upload, so you find the packaging problems early, and you get a handful of people using the real thing on real devices before strangers do.
It also splits a scary moment into two smaller ones, which is easier than doing it all in one day.
A quick story. My app's privacy declaration started out honest and became wrong without anybody touching it.
The first version stored nothing, so I declared it collected no data, which was true. Then I added accounts and syncing, which meant email addresses, progress data, and eventually a device token. The declaration didn't automatically follow.
Separately, a login library I added turned out to bundle a tracking SDK by default. Just by being in the project it would have changed what the app collected, and therefore what I was legally declaring, without a single line of my own code asking for it.
Both are the same lesson. The privacy answers aren't a form you complete once at submission. They're a description of what your app currently does, and they go stale every time you add a feature or a library.
If you want help preparing
Point two is worth doing before you submit rather than after. A reviewer's eye on your own copy catches things you've become blind to.
Next: Launch day →
Go deeper: Chapter 36, App Store Preparation and Chapter 37, Google Play Preparation