Six App Store rejections and what actually fixed them
Across a few apps I have collected six rejections. Every one was avoidable, and in four cases the rejection notice named a guideline whose actual meaning was not obvious from reading it.
2.1 — “we need a demo account”
What they said: App Completeness. The reviewer could not get past the login screen.
What fixed it: A permanent demo account in App Store Connect under App Review Information, with credentials that never expire and an account containing realistic data.
An empty demo account is nearly as bad as none — the reviewer sees an empty state and cannot evaluate the app. Mine now has a populated account that a scheduled job resets weekly.
If the app needs a phone number or a code to sign in, put the workaround in the review notes. “Use OTP 000000 for the demo number” is a sentence that has saved me two rejections.
4.2 — “minimum functionality”
What they said: the app was too simple to be an app.
What it meant: it was a wrapper around a website with little native behaviour.
What fixed it: genuine platform features — offline support, share sheet integration, a widget, and notifications that meant something. Not more screens; more reasons to be an app.
This is the hardest rejection to argue with, because “minimum functionality” is a judgement. Arguing did not work. Adding three features that only make sense on a phone did.
5.1.1 — “purpose string is not specific”
What they said: Data Collection and Storage.
What it meant: the permission prompt did not say what the data would be used for.
❌ NSCameraUsageDescription = "We need camera access"
✅ NSCameraUsageDescription = "Take a photo of a receipt to attach it to an expense"The rule: say what the user gets, not what the app wants. This is a five-minute fix and it is the most common rejection I see other people get.
Warning
A permission you request but never use is also a rejection. Removing a library that requested
location, without removing the Info.plist key, is enough — the reviewer sees a declared
permission with no corresponding feature and rejects for exactly that.
3.1.1 — “in-app purchase required”
What they said: the app linked to an external payment page for a digital subscription.
What it meant: digital goods consumed in the app must use in-app purchase. There is no negotiating this one.
What fixed it: implementing StoreKit properly, with restore purchases, and removing the external link entirely. Note that “removing the link” means from everywhere, including a help page three screens deep — the reviewer found mine.
5.1.1(v) — “account deletion”
What they said: an app that lets users create an account must let them delete it from inside the app.
What it meant: a support email address is not sufficient. It must be an in-app flow.
What fixed it: a Delete Account item in settings, a confirmation, and an API call that actually deletes the data. Fifteen minutes of work, and it is now a hard requirement for every app with sign-up.
2.3.3 — “screenshots do not show the app”
What they said: Accurate Metadata.
What it meant: my screenshots were marketing images with text over a device frame, and the reviewer could not match them to the actual UI.
What fixed it: real screenshots of the real app. A caption above the device is fine; the screen inside must be what the app looks like.
What I do before submitting now
A checklist, and it has held for two years:
- Demo account in review notes, populated with data, credentials that do not expire
- Every purpose string names the user-facing benefit
- No unused permissions in
Info.plist - Account deletion in-app if there is sign-up
- Restore purchases if there is IAP
- Screenshots are of the actual app
- Every link works, including the support and privacy URLs
- It runs on the oldest supported OS, not just the newest
On replying
Twice I have replied rather than resubmitted, and both times it worked.
The Resolution Center is a conversation with a person. A polite, specific message — “this feature is gated behind X, here is how to reach it” — has resolved two of my rejections without a new build. A reviewer who could not find a feature is not the same as a reviewer who found a problem, and it is worth checking which one you have before changing the app.
The other thing worth saying: rejections are routine. Six across several apps and several years is normal, and none of them took more than a day. The cost is the review turnaround, which is the argument for the checklist rather than for treating each one as a crisis.