Quick answer
App Store rejections happen when App Review finds a build or its listing breaking an App Review Guideline. Apple says over 40% of unresolved issues fall under guideline 2.1 App Completeness: crashes, placeholder content, broken links and demo accounts that fail. Fix the cause the reviewer reported, decide whether it needs a new build or only new metadata, test through the reviewer's access path, then resubmit with a clear note.
What are the most common App Store rejection reasons?
Friday, 4:40 p.m. App Store Connect emails you: the submission has unresolved issues under guideline 2.1. The reviewer signed in with your demo account and saw an empty dashboard with no way forward. Your own account has eight months of test data, so you have never seen that screen.
Guideline 2.1 is the one to check first. Apple's App Review page says that on average over 40% of unresolved issues relate to 2.1 App Completeness, which covers crashes, placeholder content and incomplete information. The rest spread across a handful of guidelines in the App Review Guidelines:
| Guideline | What gets flagged | What usually fixes it |
|---|---|---|
| 2.1 App Completeness | Crashes, placeholder text, broken URLs, a demo account that does not work, a backend that is down during review, in-app purchases the reviewer cannot find | A release build tested from a clean install with the exact review account |
| 2.3 Accurate Metadata | A description, screenshots or privacy information that do not match the app; 2.3.3 asks for screenshots of the app in use, not only a splash or login screen | A listing rewritten from the build you are submitting |
| 3.1.1 In-App Purchase | Features or content unlocked with license keys, QR codes or another mechanism of your own | In-app purchase where the rule applies, after reading the current exceptions for your storefront |
| 4.2 Minimum Functionality | An app that is mostly a repackaged website or offers too little lasting value | Product work on the core feature, not extra screens |
| 4.3 Spam | Several bundle IDs for the same app, or an app indistinguishable from many already available | One app with the variations built in |
| 4.8 Login Services | A third-party login such as Google Sign-In or Facebook Login as the main account option with no equivalent alternative | A second login option that limits data to name and email, lets users hide their email, and does not track for ads without consent |
| 5.1.1 Data Collection and Storage | No privacy policy link in App Store Connect and in the app (5.1.1(i)), or account creation without in-app account deletion (5.1.1(v)) | A reachable privacy policy and a deletion flow that works on the server |
| 5.1.2 Data Use and Sharing | Personal data shared with third parties without clear disclosure and explicit permission | A consent step and privacy details that match what the app sends |
Apple's own list of common issues on the same page adds a few that are easy to miss: unclear data access requests, substandard user interface, copycat apps and apps submitted by the wrong entity. Under guideline 5.1.1(ix), apps in regulated fields such as banking, healthcare, gambling or air travel should come from the legal entity that provides the service, not an individual developer.
How do you read an App Store rejection message?
Read the reviewer's message for what they did and what they saw, then reproduce exactly that. Write down the build number, the guideline cited, the account they used, the path they took and any device or iOS version mentioned. "Apple problem" is not a diagnosis; "the review account lands on an empty dashboard with no Create button" is.
Use your own review information the way the reviewer did. Apple asks for demo account details and special instructions in the App Review Information section of App Store Connect, and the reviewer has nothing else to go on. Sign in on a clean device with those credentials and follow those notes word for word, forgetting everything your team knows.
If you cannot reproduce the problem, reply in App Store Connect and ask for the detail you need. Say what you tested and what you saw. A reply of "works for us" gives the reviewer nothing to act on.
Freeze the conditions while you investigate. Keep the submitted build, its source commit and the relevant server logs. Changing the backend three times in an afternoon can erase the state that caused the failure.
Does the fix need a new build or only new metadata?
A code problem and a listing problem take different routes back to review, and fixing the wrong one wastes a round trip. Use the reported issue to pick the layer first:
| Reported issue | First check | Likely work |
|---|---|---|
| App crashes or stops at launch | Install the reviewed build in a clean state | Fix and retest the binary or required service |
| Reviewer cannot sign in | Try the supplied account outside the developer's environment | Repair credentials, access instructions, or authentication behavior |
| Listing describes unavailable behavior | Compare the listing with the submitted version | Correct metadata or implement the promised feature |
| Purchase cannot be completed | Exercise the configured product in Apple's sandbox environment | Correct purchase setup or the app's transaction handling |
| Data disclosure does not match behavior | Inspect the included SDKs and network behavior | Reconcile implementation and disclosures |
| Reviewer questions the app's utility | Walk through the complete user task | Improve the product rather than rewording the listing |
For an empty screen, tell an empty state apart from a failing server. If the API correctly returns an empty list, the app needs a useful empty state with a next action. If the API returns a 401, new placeholder text will not fix the access problem.
For a crash, read the crash log against the symbols for the exact build Apple reviewed. A stack trace from a debug build may point somewhere else entirely. Keep the commit you built the submission from.
For a metadata problem, edit the listing in App Store Connect for the right app version and every localization the issue affects. A corrected sentence in your marketing doc does not change the store record.
How do you avoid demo account and empty-screen rejections?
Your team knows where every feature lives. The reviewer only knows what the app and your review notes show them.
Create a dedicated review account with realistic data and the entitlements needed to reach every feature under review. Guideline 2.1 asks for an active demo account or a fully featured demo mode, and for backend services that are live during review. Avoid sign-in that depends on your company VPN or on a teammate reading out a one-time code.
Then rehearse. Give a colleague who did not build the feature the build and the review notes, nothing more, and watch where they stall. Each stall is a fix for the product or the notes.
Test sign-in edge cases on the release build: sign out and back in, reopen after the session expires, and make sure a restored screen recovers when the stored token is no longer valid. Remove anything that only works on a developer machine, such as a hard-coded sample response or an API endpoint on your internal network.
Describe dependencies the reviewer cannot guess. If a feature only appears after the user creates a record, say so in the notes. If the app needs a physical accessory, follow Apple's instructions for making it reviewable rather than shipping a separate demo app.
Review notes should lead the reviewer to the app your users will get. Guideline 2.3.1 bans hidden or undocumented features, so a review-only mode that hides real behavior creates a second problem.
What else should you check before resubmitting?
Read the full text of each guideline your app touches, not the headline in a checklist. Payments and third-party login carry conditions and exceptions that a one-line summary leaves out.
Test account deletion end to end. Apple's account deletion guidance says apps that support account creation must let users start deletion inside the app, and disabling the account is not enough. Confirm the server result and any retention or billing message you show.
Reconcile privacy answers with the dependencies as well as your own code. Apple's app privacy details page explains how to report data collected by your app and by third-party partners such as analytics and crash-reporting SDKs.
For purchases, test what happens after the purchase sheet closes. Check that cancellation removes access and that restore brings it back, using Apple's in-app purchase testing resources to choose the right environment.
Do not bolt native features onto a thin app to make it look more app-like. A camera button nobody needs does not answer a 4.2 rejection; a stronger core feature does.
How do you resubmit after an App Store rejection?
Fix the cause, then test the state that exposed it. For the empty-dashboard example, write a test that signs in as a user with no records, expects the empty state, and creates a first record. Add a second test where the API fails, so an outage never looks like "no data."
Keep review credentials in your secret store, never in the test file or a public screen recording. Then write a short record of the fix:
The record gives your reply to App Review a factual basis and gives the next release a check to run. Test the nearby paths too: a change to login recovery needs an existing account as well as a new one. Keep the change scoped to the defect, because an unrelated redesign gives the reviewer more to assess.
Reply in App Store Connect with what failed, what changed and the shortest path to see the fix, and name the new build if there is one. Apple's unresolved issues guide explains which items to fix and resubmit; not every issue means replacing every item in the submission.
Expect a slower review if you resubmit the same problem. The guidelines' After You Submit section says apps repeatedly rejected for the same guideline violation take longer to review.
If your app is already live and the rejection blocks a bug fix, check whether it qualifies as a Bug Fix Submission. For apps already on the App Store, Apple does not hold back bug fixes over guideline violations unless the violation is a legal or safety issue. To use this route, tell App Review in App Store Connect and commit to addressing the issue in your next submission.
Can you appeal an App Store rejection?
Yes. If you believe the reviewer misunderstood your app's concept or functionality, you can submit an appeal to the App Review Board. Apple asks you to give specific reasons why the app complies, file one appeal per rejected submission, and answer any open requests for information before appealing.
Appeal a misreading, not a rule you dislike. If the rule itself seems wrong for your case, Apple's guidelines page also has a form to suggest changes to the guidelines.
Do not hide a feature during review and switch it on afterward. Under guideline 2.3.1, egregious or repeated hidden features are grounds for removal from the Apple Developer Program.
Stop the same rejection from coming back
Give each recurring check to the person who owns the behavior. A rejected login flow should change your authentication tests and release rehearsal; an inaccurate listing should change how you review metadata. Store the reported issue next to the corrected build so the next release owner can see what failed and how you check for it now, without reading the whole App Review thread.
Where Expo fits
EAS Submit uploads builds to App Store Connect. It saves you the repeated upload work, and it has no say in whether an app meets Apple's review criteria.
For a fix in native code or the binary, create a new build with EAS Build, test it, and select that build when you submit. The iOS submission guide covers the upload path.
EAS Update ships compatible JavaScript and asset changes to builds that are already installed, within App Store Review Guideline 2.5.2. EAS Update cannot replace a native binary, cannot change the build App Review is looking at, and cannot make a policy problem acceptable. A rejected binary goes back through App Review.
Limitations
No checklist guarantees approval. The reviewer's message and the current guidelines decide the work for each submission, and review time is outside the control of any build or upload service.
Next step
Open Apple's App Review preparation resources and rehearse your app's main journey with a clean review account before you upload another build.
Verified on 12 September 2026.