App Store Rejection Fix: Common Rejections, What to Change

The App Store rejection fix is usually small once you know which rule you broke. Most rejections come from a short list: the reviewer couldn't sign in, digital content is sold without in-app purchase, there's no in-app account deletion, permission prompts are vague, privacy answers don't match the app, or the app is a website in a wrapper.

TL;DR: Read the cited guideline, fix the cause, and say exactly what changed when you resubmit. Most first-release rejections trace to guidelines 2.1, 3.1.1, 5.1.1, 5.1.2, 4.8, or 4.2. Apple says it typically reviews at least 50% of submissions within 24 hours and 90% within 48 (Apple), so one fast resubmission is usually cheap.

Guideline numbers below come from Apple's App Review Guidelines, checked on 21 October 2026. Apple revises them several times a year, so read the live text before you resubmit. This post covers the store rules; billing design lives in its own post, linked below.

Which App Store rejections are most common, and what fixes each?

Nine causes cover most first releases. The table maps each to the guideline Apple usually cites and the change that clears it. The sections after it explain the ones that need more than a line.

Rejection	Guideline usually cited	The fix
Reviewer couldn't sign in or reach features	2.1 App Completeness	A working demo account, or an approved demo mode, plus notes
Crashes or broken screens during review	2.1	Test the exact build on a clean device with the review account
Digital goods sold outside in-app purchase	3.1.1	In-app purchase for digital content and subscriptions
No way to delete an account	5.1.1(v)	Account deletion inside the app
Permission prompt with a vague reason	5.1.1	A specific purpose string for each permission
Privacy answers don't match behavior	5.1.2 and privacy labels	Update App Privacy answers and SDK privacy manifests
Social login without a private option	4.8 Login Services	An equivalent login that meets Apple's three conditions
App is a repackaged website	4.2 Minimum Functionality	Real app value: native features, offline use, notifications
Screenshots or description mislead	2.3 Accurate Metadata	Show the app in use; drop claims it can't back

Why was my app rejected under guideline 2.1?

Usually because the reviewer couldn't get past the login screen, or got in and found nothing to review. Guideline 2.1 asks for demo account details, with your back end switched on, whenever an app has a login. If legal or security rules stop you providing an account, Apple allows a built-in demo mode, but only with its prior approval.

Fix: in App Store Connect, under App Review Information, give a demo account that works and stays working, seeded with realistic data. If the app depends on a role, give one account per role and label them.

Role-based products are where this goes wrong. GymFast, for example, ships separate staff and member apps, so each submission needs an account for the role that app serves, with data already in it. A member account with no workout plan looks like a broken app to a reviewer who's never seen a gym dashboard.

If sign-in uses a one-time code by SMS or email, give the reviewer a way in that doesn't need your phone. And write the notes for a stranger: what the app does, who it's for, where to tap.

Crashes fall under 2.1 too. Install the exact TestFlight build on a clean device, sign in with the review account, deny every permission, and switch off Wi-Fi halfway through. Most review crashes hide on a path your own devices never take, because they already granted everything.

When must an app use Apple's in-app purchase?

When it opens up features or content inside the app. Guideline 3.1.1 lists subscriptions, in-game currencies, premium content, and full versions as things that must use in-app purchase. Guideline 3.1.3(e) says the opposite for physical goods and services used outside the app: those must use other payment methods.

Fix: sort everything you sell into those two buckets. A gym membership is a service used outside the app. Study material, AI credits, and premium features are digital.

The linking rules now differ by storefront. Apple's current guidelines say apps on the United States storefront can include buttons and links to other purchase methods without the StoreKit external purchase entitlements, while other storefronts limit such links to apps holding the relevant entitlement. Read the current rule for every storefront you sell in rather than copying another app.

NoteTube is one example of selling on both sides: RevenueCat in the apps, Stripe on the web, and a scheduled job that reconciles the two. How that's built is in RevenueCat in the app, Stripe on the web.

What does Apple require for account deletion?

If people can create an account in your app, they must be able to start deleting it in the app, under guideline 5.1.1(v). Apple's account deletion guidance says to offer deletion of the whole account record and its personal data. Offering only to deactivate or disable the account isn't enough (Apple Developer).

Fix: put "Delete account" in account settings, explain what will be removed, confirm once, then do it. If finishing requires your website, link straight to that page. Outside highly regulated industries, Apple says not to require a phone call or an email to support.

Two details catch people:

• Subscriptions. If the user has an auto-renewable subscription, tell them billing continues through Apple and ask them to cancel before deleting.
• Sign in with Apple. Apple says apps that support it should revoke user tokens through the Sign in with Apple REST API when the account is deleted.

On the server, delete or anonymize the user's data, revoke their tokens, and remove them from any third-party tools.

Permission prompts and privacy answers

Specifically. Each iOS permission shows a system prompt with a purpose string you write, and "this app needs camera access" fails. Privacy answers in App Store Connect must cover what your third-party SDKs collect too, not only your own code. Both are about telling the user, and Apple, the truth.

Fix for prompts: name the feature and the reason. "Scan the QR code at the front desk to check in" is a good camera reason. Ask when the feature is used, not on first launch, and keep the app working if the user says no.

Fix for privacy: Apple says you must identify all data you or your third-party partners collect, and that third-party partners include analytics tools, ad networks, and SDKs whose code you've added (Apple App Privacy Details). List every SDK in the app, check what each collects, and update the answers. Keep SDK privacy manifests current when you upgrade them.

The trap here is time, not ignorance. Privacy answers are written once, at launch. Then someone adds an analytics SDK six months later and nobody reopens App Store Connect. Make "check privacy answers" part of the checklist for any release that adds a dependency.

Does Sign in with Apple have to be offered?

Often, but not always. Guideline 4.8 says an app that uses a third-party or social login for the user's primary account must also offer an equivalent login that limits data to name and email, lets users keep their email private, and doesn't collect app interactions for advertising without consent. Sign in with Apple meets all three.

Fix: add Sign in with Apple next to Google or Facebook, or use your own email account system only. Apple lists exceptions, including apps that use only the company's own account system and business apps that need an existing enterprise account. Whatever you choose, make sure an Apple-created account can link to the same person's web account, or support will hear about it.

Why would Apple reject an app as a website?

Because guideline 4.2 expects features, content, and UI that go beyond a repackaged website. Reviewers ask whether the app offers anything a bookmark wouldn't. A web view of a membership page doesn't. A member app with QR check-in, a workout plan, and offline logging clearly does.

Fix: give the app reasons to exist: push notifications, offline use, camera or QR features, faster native navigation for the core tasks. Metadata matters here too. Under guideline 2.3, screenshots and the description must show the app's real core experience, so don't advertise features the build doesn't have.

Responding to a rejection, step by step

Read the cited guideline in full, then decide whether the reviewer misunderstood or was right. Apple's App Review page says you can correspond with App Review in App Store Connect before resubmitting, and appeal to the App Review Board if you think the app was misunderstood (Apple App Review).

1. Read the guideline, not just the reviewer's summary.
2. If the reviewer misread the app, reply with a short explanation and screenshots.
3. If the rejection is fair, fix it and say exactly what changed when you resubmit.
4. If you still disagree, file one appeal per rejected submission, with specific reasons the app complies.

For Expo apps, some fixes are JavaScript-only and could ship over the air. Anything that changes what the reviewer saw should go through review again; our OTA release process covers where that line sits, and the Expo vs React Native CLI page compares the two workflows.

A note on Google Play

Google runs different checks, and two catch first releases. New personal developer accounts must run a closed test with at least 12 testers opted in continuously for 14 days before production access (Play Console Help). And from 31 August 2026, new apps and updates must target Android 16, API level 36 (Android Developers). Put both in the launch plan.

FAQ

What should App Review notes include?

What the app does and who it's for, a working demo account for each role, where to tap to reach the main feature, and anything a stranger couldn't guess, such as hardware the app expects or a feature limited to one country. Short, plain notes save a round of questions and often a rejection.

Who should own the Apple and Google developer accounts?

Your company, from the first submission. Enroll in the Apple Developer Program and Google Play Console yourself and add your developers as team members. Whoever holds the account controls the listing, the reviews, and future releases, and moving an app between accounts later is slower than setting it up right.

Is a rejected build ever approved without code changes?

Yes. If the reviewer misunderstood the app, couldn't reach a feature, or tested with a broken demo account, a clear reply with screenshots or a working account can clear it without a new build. Fix the review notes first, then decide whether code needs to change.

Should we submit to Apple and Google on the same day?

Submit both early and plan the launch date around the slower one. Apple's review is often quick, but Google's closed testing for new personal accounts takes at least 14 days, so the Play listing can be the bottleneck on a first release from a new account.

Stuck in review, or planning a first release? Our App Store submission help covers rejections, review notes, and store setup. Send us the rejection message and we'll tell you what we'd change.