What App Store rejections actually teach you about scope

Between Let’s Barter, High, Sovchi and MyDigitalBill I have submitted to the App Store and Google Play more times than I would like to count. Some of those submissions came back rejected. The useful part was not the fix — the fixes were usually small. The useful part was noticing that the same few things caused nearly all of them, and that none of them were really engineering problems.

A rejection is a scoping failure that waited until the worst possible moment to introduce itself.

Why apps actually get rejected

When a build comes back, the instinct is to treat it as a bug. Something is broken, patch it, resubmit. That framing is comfortable and almost always wrong. Go back through the rejections and you find the same shape every time: a requirement that existed on day one, that nobody wrote into the scope.

Nobody decided not to build account deletion. It simply never appeared on a list, so it never got estimated, so it never got built, so the reviewer found it missing. The code took an afternoon. The delay cost a week.

The reviewer is not finding bugs in your app. They are finding gaps in your plan.

Once you see it that way, the fix moves upstream. You stop trying to write more careful code and start writing a more honest scope.

The four repeat offenders

These four catch more first-time apps than everything else combined.

Google Play has its own version of the same trap. The Data safety form must match what your app genuinely does, the target API level requirement rises every year, and permission-heavy features like full photo library access or background location now require a written declaration explaining why you need them. None of that is hard. All of it takes time you did not schedule.

Guideline 4.2 deserves special attention

If your client’s brief is “make our website into an app”, you have a 4.2 problem before you open your editor. The honest conversation happens in week one, not in review. Ask what the app does that a mobile browser cannot: push notifications, offline access, camera, Bluetooth, biometric login, background sync. If the answer is nothing, you are building a wrapper and it will be rejected.

With MyDigitalBill the answer was obvious — a browser cannot talk to a Bluetooth thermal printer sitting on a shop counter. With Let’s Barter it was push notifications and real-time chat. Have that answer written down before you quote.

Account deletion is a feature, not a setting

This is the one I want to flag hardest, because it is the one that looks smallest and is not.

“Add a delete account button” sounds like an afternoon. Then you start asking the questions that button implies:

• What happens to content the user already posted? On a marketplace, do their live listings vanish mid-trade?
• What happens to conversations? Chat has two participants and only one of them is leaving.
• What must you legally retain — invoices, transaction records — and how do you keep those while deleting the person?
• Is deletion immediate or is there a grace period? Who processes the queue?
• Does it cascade through Firebase Auth, Firestore, Storage and any push tokens?

That is a product decision, a data model decision and a legal decision wearing a button. Apple requires the deletion to be initiated from inside the app; Google additionally wants a web-accessible route so people can delete without reinstalling. Put it in the scope document in week one and it costs a day. Discover it during review and it costs a week plus an awkward client call.

Privacy labels punish vague scope

Apple’s privacy nutrition labels and Google’s Data safety form both ask the same underlying question: what exactly does your app collect, and why? If you cannot answer precisely, you will either over-declare, which scares users off the listing, or under-declare, which is a policy violation.

The reason this is hard is that most of the collection is not yours. It is your SDKs. Analytics, crash reporting, ads, push, a maps widget, a payment provider — each one has its own data behaviour, and on iOS many third-party SDKs now ship a privacy manifest you are expected to account for.

So keep an inventory. A plain table in the project README, updated whenever a dependency is added:

| SDK                  | Collects            | Linked to user | Why                |
|----------------------|---------------------|----------------|--------------------|
| firebase_auth        | Email, user ID      | Yes            | Account            |
| firebase_messaging   | Device token        | Yes            | Push notifications |
| cloud_firestore      | User content        | Yes            | Core functionality |
| firebase_crashlytics | Crash logs, device  | No             | Diagnostics        |

Filling the forms then takes twenty minutes instead of an afternoon of archaeology, and the answers are defensible.

The pre-build checklist

This is what I now run before writing a line of code on any app that will reach a store. It is deliberately boring.

1. Can users create an account? Then account deletion is in scope, in the estimate, on both platforms, plus a web route.
2. Are we using a third-party login? Then an equivalent privacy-focused option is in scope too.
3. What does this do that a browser cannot? Write the sentence down. If you cannot, reopen the conversation.
4. Which permissions do we request? Each one needs a plain-English usage string that a stranger would accept, and a feature that visibly needs it.
5. What does the reviewer need to see everything? A demo account that does not expire, seeded with real-looking data, plus notes for anything non-obvious.
6. Which SDKs collect data? Start the inventory table now, not at submission.
7. Are there paid tiers? Digital goods go through in-app purchase. Physical goods do not. Getting this wrong is expensive.
8. Support URL, privacy policy URL, marketing URL. All live, all reachable, before you submit.

Eight questions. Twenty minutes. They have saved me more time than any refactor I have ever done.

Budget time for review, not just build

The last lesson is about promises. Review is typically quick — often within a day — but a rejection is not a single event. It is a decision, a fix, a version bump, a rebuild, an upload, a wait. Two to four days, comfortably.

So I no longer tell a client “it will be live Friday” when I submit on Wednesday. I tell them the submission date and the expected window, and I explain that a rejection is normal rather than a catastrophe. That reframing matters: the first time a client hears the word rejected, it sounds like failure. If you have already told them it happens to almost every app, it sounds like process.

Which is really the whole point. Scope honestly, communicate clearly, and keep going when the reviewer says rejected. The guidelines are not the enemy. They are a specification that was always there — you just have to read it before you build, instead of after.