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.

Surviving App Store review: the 7 rejection causes we keep hitting
KEY TAKEAWAYS
  • Guideline 2.1 (Performance) is the rejection that eats the most time, and it's almost always a crash on a fresh install with no account.
  • Guideline 3.1.1 will get you if you sell digital credits through Stripe or anything that isn't IAP. RevenueCat saves you from yourself here.
  • If your app uses AI image or text generation, expect a 1.2 rejection asking for user-generated content reporting and blocking.
  • Reviewers test on the worst network in the building. If your splash screen sits for 8 seconds, you fail 4.0.
  • Write the review notes like you're talking to a tired QA engineer at 4pm on a Friday. Because you are.

We’ve shipped about 30 iOS builds across Photo AI Studio, Interior AI Designs, and a handful of client apps in the last 18 months. Roughly a third got rejected on first submission. None of those rejections were surprising in hindsight, but every single one cost us 24 to 72 hours of calendar time, which when you’re trying to hit a launch window is genuinely painful.

Here are the seven rejection reasons we keep seeing, in rough order of how often they bite us. None of this is theoretical. Every one of these has a corresponding ticket in our Linear from the last year.

1. Guideline 2.1 - crashes on a clean install

This is the big one. The reviewer downloads your app on what is probably a battered iPad running the latest iOS beta, opens it once, and it crashes or hangs. They don’t try again. You get a screenshot and a generic 2.1 rejection.

The pattern we see: the app works fine for us because we’re signed in, our keychain has tokens, our local DB is populated. On a fresh install with no account, the onboarding flow hits a null somewhere and dies. Or the splash screen waits on a network call that times out instead of failing gracefully.

Fix that helped us: a hard rule that any first-launch screen must render within 2 seconds even if every network call fails. We wrap the bootstrap in a timeout and fall back to a cached or empty state.

const bootstrap = async () => {
  const result = await Promise.race([
    fetchInitialConfig(),
    new Promise((resolve) => setTimeout(() => resolve(null), 2000)),
  ]);
  return result ?? DEFAULT_CONFIG;
};

Also: install the app on a wiped device or a fresh simulator before every submission. Not your daily driver. We have a checklist item for this and we still forget.

2. Guideline 3.1.1 - using anything but IAP for digital goods

If your app sells credits, subscriptions, unlocks, tokens, or any other digital thing that gets consumed inside the app, it has to go through In-App Purchase. Stripe is fine for physical goods or services consumed outside the app. It is not fine for “100 AI generations for $9.99.”

We learned this the expensive way on Photo AI Studio v2. We had Stripe wired up because the web version used it and we wanted parity. Rejected. Spent four days ripping Stripe out of the iOS build and putting RevenueCat in front of StoreKit 2. Honestly, RevenueCat is what we should have started with. It handles the entitlement sync between iOS, Android, and web, which is the part that breaks your brain otherwise.

If you have a web app and an iOS app and you want the same user to keep their credits on both, the architecture you want is: RevenueCat for iOS and Android purchases, Stripe for web purchases, both writing to a single user entitlements table in your backend.

3. Guideline 1.2 - user-generated content with no moderation

This hits every AI app eventually. If users can generate images or text, especially if they can share or save the output, Apple expects you to have:

We got a 1.2 rejection on an app that didn’t even have a social feed. The reviewer’s argument was that since users could generate images from prompts, they could generate something objectionable. We added a Report button on every generated image (it emails our support inbox via Resend), a prompt filter on the backend, and a EULA link in settings. Passed on resubmission.

If you’re building anything with image generation through FAL or Replicate, just put this stuff in from day one. It’s a day of work and it removes an entire category of rejection.

4. Guideline 4.0 - design that looks like a website

WebViews wrapping your marketing site will get rejected. So will React Native apps that look exactly like the web equivalent with no native gestures, no native navigation, and a hamburger menu in the top left.

The specific thing reviewers seem to flag: tap targets that are too small, scroll behavior that doesn’t match iOS, and a back button drawn in the UI when there’s already a system one. We had Interior AI Designs rejected once for having a custom back chevron that, combined with the swipe-from-edge gesture, made navigation feel weird. Removed the custom chevron, used the default nav bar, accepted.

5. Guideline 5.1.1 - asking for permissions you don’t need

If you request photo library access on app launch and the user hasn’t done anything yet, you’ll get flagged. Same for camera, contacts, location. The rule is: ask in context, when the user has tapped the thing that needs the permission, and explain why in the Info.plist string.

Bad: NSPhotoLibraryUsageDescription = "We need access to your photos."

Better: NSPhotoLibraryUsageDescription = "Photo AI Studio uses your photo library to import the image you want to enhance."

The second one tells the reviewer exactly when and why. The first one gets a follow-up question.

6. Guideline 2.3.10 - mentioning other platforms

If your app description or in-app copy mentions Android, the Play Store, or the web version, you can get hit. We had a screenshot that said “Now on iOS” in the corner. Rejected, because that implied it had been somewhere else first and Apple doesn’t love that framing.

The fix is boring: scrub every mention of Android, Google Play, and “also available on” from your screenshots, app description, and in-app onboarding. Keep the cross-platform marketing on your website.

7. Guideline 2.1 again - account deletion

Since June 2022, any app with account creation must offer in-app account deletion. Not “email us to delete your account.” Not a link to a web form. A button inside the app that actually deletes the account.

We still see this miss on client apps we audit. The pattern is usually: there’s a delete button, but it sends an email to support and waits for human action. That’s not compliant. It has to actually delete, or at least queue a hard delete that completes without human intervention.

Our standard implementation: a settings screen with a Delete Account button, a confirmation modal, then a call to a backend endpoint that soft-deletes immediately (hides the data) and queues a hard delete job for 30 days later in case the user changes their mind. Document this in your review notes so the reviewer doesn’t have to guess.

The review notes are not optional

The single highest-leverage thing we do before submission is write good review notes. Test account credentials, a one-line description of what to test, and a list of any non-obvious permission prompts. If your app needs a specific country VPN or a test promo code, put it there in plain English.

Reviewers are processing dozens of apps a day. Make their job easy. We’ve had submissions approved in under 18 hours when the notes were clean. The same app on a quiet notes field can sit in review for four days.

If you want help getting an AI app through review without burning a week on rejections, we do this for a living.

FREQUENTLY ASKED

Common questions

Can I use Stripe in my iOS app for AI credits if I already use it on web?

No. If the credits are consumed inside the iOS app, Apple requires In-App Purchase. You can keep Stripe on web and add RevenueCat in front of StoreKit 2 on iOS. Sync entitlements server-side so a user who buys on web sees credits on iOS and vice versa. The web purchase has to happen in a browser, not in a WebView inside the app, or you'll fail 3.1.3.

How long does App Store review usually take?

In our recent submissions, most decisions come back in 24 to 48 hours. We've seen as fast as 6 hours and as slow as 5 days. Holidays slow things down. First submissions of a new app tend to take longer than updates. Clean review notes and a working test account seem to correlate with faster approvals, though Apple doesn't publish data on this.

What counts as enough content moderation for an AI image app?

At minimum: a server-side prompt filter for the obvious categories (CSAM, explicit violence, hate), a Report button on user-visible generated content, a Block user feature if there's any social element, and a EULA prohibiting objectionable content. We send reports to a support inbox via Resend and review them daily. Apple has rejected apps for not having all four, even when the app has no social features at all.

Do I really need in-app account deletion?

Yes, since June 30, 2022. A button that emails support is not compliant. The deletion must happen without a human in the loop. A reasonable pattern is to soft-delete immediately, hide the user from the app, and queue a hard delete job for 30 days later. Document the flow in your review notes so the reviewer can find the button without hunting.

What's the fastest way to get unblocked after a rejection?

Reply in Resolution Center with specifics: what you changed, where to find it, and a new test account if relevant. Don't argue the guideline unless you genuinely think it's wrong, in which case request a call with the App Review Board. In our experience, fixing and resubmitting is faster than appealing. We've had resubmissions approved in under 12 hours when the fix was obviously addressed.

SOURCES
  1. [1]
    App Store Review Guidelinesdeveloper.apple.com
  2. [2]
  3. [3]
    StoreKit 2 documentationdeveloper.apple.com
  4. [4]

Related posts