Surviving App Store review: the 7 rejection causes we keep seeing
Seven rejection patterns we hit shipping iOS apps in 2024, the exact guideline numbers, and what we actually changed to get approved. Including the one that took five resubmits.
- ↳Guideline 5.1.1 (data collection without justification) is the single most common rejection we see, usually triggered by asking for contacts or camera before the user understands why.
- ↳If your app uses third-party login or in-app purchases, expect 3.1.1 and 4.0 issues unless you also offer Sign in with Apple and route digital goods through StoreKit.
- ↳Reviewers test on real devices with bad networks. Empty states, offline behavior, and login demo accounts matter more than your marketing copy.
- ↳Most rejections we get back in under 24 hours now. Plan for two review cycles per launch, not one.
- ↳A clear reply in Resolution Center, with screenshots and timestamps, gets you unblocked faster than a code change half the time.
We’ve put around 20 iOS apps through App Store review over the last two years, between our own products (Photo AI Studio, Interior AI Designs, Zoltan AI) and client work. Some sailed through in four hours. One took five resubmits and a phone call with App Review. The rejections are rarely surprising once you’ve seen them a few times, but they cost real days if you hit them on launch week.
Here are the seven we keep seeing, in rough order of frequency, with what we actually did to fix each one.
1. Guideline 5.1.1, asking for data before earning it
This is the number one rejection we get. You pop the contacts permission, or photo library, or camera, on app open. Reviewer denies it. Now your app is a blank screen and they reject under 5.1.1 (Data Collection and Storage) or 2.1 (App Completeness).
The fix is boring and works every time: gate the permission behind a user action that obviously needs it. Photo AI Studio doesn’t ask for photo library access on launch. It asks when you tap “upload a selfie” on the generation screen. The NSPhotoLibraryUsageDescription string says exactly what we do with the photo and that it gets deleted after processing.
<key>NSPhotoLibraryUsageDescription</key>
<string>We use your selfie to generate AI portraits. Photos are processed on our servers and deleted within 24 hours.</string>Vague strings like “to improve your experience” get rejected. Be specific about what you do with the data.
2. Guideline 3.1.1, selling digital stuff outside StoreKit
If your app unlocks anything digital (credits, subscriptions, AI generations, premium filters), it has to go through in-app purchase. Not Stripe. Not a web checkout you sneakily link to. Not a QR code.
We use RevenueCat on top of StoreKit 2 for every consumer app now. The one time we tried to be clever, routing a “top up credits” flow to a Stripe checkout because StoreKit consumables felt awkward, we got rejected within six hours. The rejection literally quoted our Stripe URL back at us.
There are real exceptions (“reader” apps, physical goods, business services) but if you’re a B2C app selling AI features, you’re not the exception. Just use StoreKit.
3. Guideline 4.8, third-party login without Sign in with Apple
If you offer Google, Facebook, or any other social login, you must also offer Sign in with Apple. This is non-negotiable since 2020 and Apple still catches apps missing it. We caught ourselves missing it on Zoltan AI v1.2 because we’d added Google sign-in mid-development and forgot. Four-hour rejection.
The annoying part: Sign in with Apple has to be visually equivalent. Same prominence, same position in the stack. Hiding it below a fold or making it smaller is a rejection.
4. Guideline 2.1, broken demo account or unclear test instructions
Reviewers need to get past your login screen. If you require an account, you must provide a demo account in App Store Connect under “Sign-in required.” If that account doesn’t work, or expires, or has no data in it, you get rejected for incompleteness.
What works for us:
- A permanent demo account, password documented in a 1Password vault the whole team can read.
- The demo account is seeded with realistic data (3 projects, 10 generations, a sample subscription state).
- Notes field in App Store Connect explains anything non-obvious: “To test the paid flow, the demo account has unlimited credits enabled server-side. Tap Generate on the home screen.”
We’ve had reviewers explicitly thank us in the resolution center for clear notes. It’s the cheapest goodwill you can buy.
5. Guideline 4.3, “spam” / clone rejections for AI apps
This one is newer and brutal. If you publish multiple AI image apps, or your app looks too similar to other AI apps in the store, Apple may reject under 4.3(a) as a spam clone. We hit this with a niche photo app last year that shared a codebase with Photo AI Studio.
What got us through:
- Different bundle ID, obviously, but also genuinely different UI, different copy, different onboarding.
- A clear positioning statement in the app description: who it’s for, what makes it specific.
- Sometimes a phone call. You can request one through Resolution Center. The reviewer who called us was reasonable once we explained the actual product difference.
If you’re shipping six near-identical AI wrappers from the same developer account, Apple will figure it out and you’ll lose the account. Don’t do that.
6. Guideline 5.1.2, privacy policy doesn’t match what the app does
Apple compares your privacy policy URL, your App Store Connect privacy declarations, and your actual SDK usage. If you declare “no data collected” but you’ve got Firebase Analytics and Sentry firing on launch, you’re getting flagged.
We maintain one source of truth: a privacy.json in the app repo that lists every SDK, what it collects, and the legal basis. Privacy policy is generated from it. App Store Connect declarations are filled in from it. It takes 20 minutes per app and prevents one of the dumbest rejection categories.
Firebase, Sentry, RevenueCat, Mixpanel, Adjust, AppsFlyer. All of these collect data. Declare them.
7. Guideline 2.3.10, Android references, beta language, placeholder text
The pettiest rejection and the easiest to fix. Screenshots that mention Google Play. Copy that says “available on Android too.” A settings screen with “beta” in the title. Lorem ipsum on a tutorial page nobody noticed.
We now run a pre-submit checklist that greps the entire codebase and asset folder for: android, google play, beta, lorem, TODO, FIXME, test@test. Catches something embarrassing maybe one time in five.
rg -i "android|google play|lorem|TODO|placeholder" ./ios ./assetsWhat to do when you get rejected anyway
Most rejections we get back in 12 to 24 hours. The reply matters more than people think.
Don’t argue the guideline. Acknowledge what they flagged, explain the fix or the misunderstanding, attach screenshots with timestamps if you’re contesting (e.g. “the permission prompt only appears after tapping Generate, see attached video”). If you genuinely disagree, request a call through Resolution Center. Apple will sometimes reverse a rejection on the call if you have a real case.
Don’t resubmit the same build with a snarky reply. We’ve watched that turn a 24-hour cycle into a five-day one.
If you’re shipping consumer AI apps and want a second pair of eyes on your build before submission, or you’ve been stuck in review for a week and need someone to read the guidelines with you, reach out. We’ve made all of these mistakes already so you don’t have to.
Common questions
▸How long does App Store review actually take in 2024?
For us, most reviews come back in 12 to 24 hours, sometimes under 4. First submissions of a new app skew slightly longer. Holidays and the week before a major iOS release (early September) get slower, often 2 to 3 days. Apple publishes median times around 24 hours and that matches what we see, but plan for two review cycles before launch, not one.
▸Can I use Stripe in my iOS app for any reason?
Yes, for physical goods and services consumed outside the app (food delivery, ride-share, real-world classes, B2B services). No, for digital content used inside the app, which includes AI credits, subscriptions to digital features, filters, and unlocks. The line is whether the thing being purchased is consumed in the app. If unsure, assume StoreKit.
▸Do I really need Sign in with Apple if I only offer email login?
No. Sign in with Apple is only required if you offer a third-party social login (Google, Facebook, Twitter, etc.). Plain email and password is fine on its own. The moment you add Google sign-in to your existing email flow, you must also add Sign in with Apple, with equivalent visual prominence.
▸What's the fastest way to fix a 5.1.1 data collection rejection?
Move the permission prompt to the exact moment the user takes an action that needs that data, and rewrite the usage description string to say specifically what you collect and why. Don't ask on launch. Don't use generic copy. If the reviewer can tap the feature, see the explanation, and understand the trade, you're approved.
▸Should I worry about 4.3 spam rejection if I'm shipping an AI app?
If it's your first or second AI app and the product is genuinely differentiated in concept, UI, and copy, you're fine. If you're publishing multiple near-identical AI wrappers from the same developer account, expect 4.3 and risk losing the account entirely. Apple has gotten aggressive about this since late 2023.
- [1]App Store Review Guidelinesdeveloper.apple.com
- [2]Sign in with Apple requirement (Guideline 4.8)developer.apple.com
- [3]App Store Connect: App privacy detailsdeveloper.apple.com
- [4]App Review processing timesdeveloper.apple.com
Related posts
Surviving App Store review: the 7 rejection causes we keep hitting
Seven specific reasons Apple keeps rejecting our apps, what each rejection actually looks like in Resolution Center, and what we changed in the build to get through.
MVP software development when the prototype already exists: finishing what Cursor started
A field guide for taking a half-built Cursor or v0 prototype across the line. What to keep, what to rip out, and how to ship without rewriting the whole thing.
Why we still pick Flutter + Firebase + AdMob for new mobile apps in 2026
Everyone keeps asking why we haven't moved to React Native or native SwiftUI. Here's the honest stack math after shipping a dozen apps on Flutter, Firebase, and AdMob.