App Store Rejection Reasons: 12 Common Rejections and Fixes
Most App Store rejections cite guidelines 2.1, 4.3 or 5.1.1. Here are 12 common rejection reasons, fixes, how to reply to review and how to appeal.
After an App Store rejection, open App Review in App Store Connect, find the guideline number at the start of each reason and decide whether the problem is in the build or the metadata. Metadata fixes can go back with the same build. Code fixes need a higher build number and a new upload, plus a reply that lists what you changed. Most rejections cite 2.1 App Completeness, 2.3 Accurate Metadata, 3.1.1 In-App Purchase, 4.3 Spam or the 5.1.1 privacy rules.
Below are the 12 most common rejection reasons by guideline number. For each one you get the usual wording in the rejection message, the cause, the fix and what to say in your reply, followed by a summary table and the appeal process. The App Store Review Guidelines are the authority. As of October 2026 they were last updated on October 16, 2026.
What should you read first in a rejection message?
After a rejection, the app’s page in App Store Connect shows a notice about unresolved issues at the top. Open App Review to see each rejection reason. Every reason starts with a guideline number, such as “Guideline 2.1 - Performance - App Completeness”, followed by the reviewer’s description, sometimes with screenshots, a screen recording or crash logs.
Do three things first.
- Find the guideline number and read that guideline in the App Store Review Guidelines.
- Work out whether the problem is in the build (code, bundle contents) or the metadata (screenshots, description, privacy information, review notes).
- If you only change metadata, you can resubmit the same build. If you change code, increase the build number, build again and upload.
What are the 12 most common App Store rejection reasons?
1. 2.1 App Completeness, crashes and obvious bugs
Typical wording. The app crashed on launch or during use on a specific device and iOS version, or a button did nothing or a page was blank. The message usually includes crash logs.
Cause. Guideline 2.1(a) requires the submission to be final, with placeholder text, empty web pages and temporary content removed, and tested for stability on a device. Reviewers test on the latest iOS, so problems you never saw on older versions show up here. A backend that’s offline or an API pointing at a test environment also falls under this guideline.
Fix. Use the attached crash log to find the failing function. Run through the main flows with a Release build on a device running the latest iOS. TestFlight is built for exactly this. See TestFlight beta testing: upload a build and add internal and external testers.
In your reply. Explain the cause of the crash and the fix, give the new build number, and say which iOS version and device model you retested on.
2. 2.1 Information Needed, the demo account doesn’t work
Typical wording. The reviewer couldn’t sign in with the demo account you provided, or needs more information to continue the review (Information Needed).
Cause. Guideline 2.1(a) requires apps with sign-in to provide a demo account and keep backend services available. A mistyped password, an expired account, sign-in that requires an SMS code sent to a local phone number, or features that only appear with specific hardware or in specific regions all stop the review here.
Fix. Enter a long-lived demo account with preloaded data under App Review Information. If sign-in relies on an SMS code, give this account a fixed code and explain it in the notes. If you can’t provide an account for legal or security reasons, the guidelines allow a built-in demo mode with Apple’s prior approval. The demo mode must show the app’s full functionality.
In your reply. This usually only involves metadata. Give the account, password and steps in your reply, then resubmit without uploading a new build.
3. 2.3 Accurate Metadata
Typical wording. The screenshots don’t show the app in use. The description mentions features that aren’t in the app. The name or keywords contain irrelevant terms or other platforms’ names.
Cause. Guideline 2.3 requires metadata, including privacy information, the description, screenshots and previews, to accurately reflect the app’s core experience. Guideline 2.3.3 requires screenshots to show the app in use, not just title art, a login page or a splash screen. Guideline 2.3.7 prohibits packing names and keywords with trademarked terms, popular app names or pricing, and limits app names to 30 characters. Guideline 2.3.10 prohibits names, icons and imagery of other mobile platforms in the app or its metadata.
Fix. Replace screenshots with real screens, remove features you described but didn’t build, drop competitor names from keywords, and search the app and screenshots for words like “Android”. If you have in-app purchases, make clear in the description and screenshots which content costs extra, as guideline 2.3.2 requires. For how to prepare screenshots, see Publish to the App Store on Windows, from .ipa upload to review.
In your reply. List the metadata you changed, then resubmit with the same build.
4. 2.5.1 Non-public APIs or frameworks used for the wrong purpose
Typical wording. The app uses non-public APIs. Or the app includes a framework such as HealthKit or HomeKit, but the reviewer couldn’t find the matching feature.
Cause. Guideline 2.5.1 allows only public APIs and requires the app to run on the currently shipping OS. Frameworks must be used for their intended purpose and described in the app’s description. HealthKit, for example, should be used for health and fitness and integrate with the Health app. Non-public APIs usually come from a third-party SDK or static library.
Fix. Search your own code and dependencies for the symbol names listed in the message, and update or remove the SDK that makes the private calls. Remove frameworks and permissions you don’t use. For the ones you do use, explain in the description and review notes which screen uses them and for what.
In your reply. Say which SDK or call you removed, or point to the feature and the steps to reach it, with a screen recording if needed.
5. 3.1.1 In-App Purchase, digital content sold outside it
Typical wording. The app unlocks features or content by means other than in-app purchase. Or the in-app purchases you configured can’t be found in the app.
Cause. Guideline 3.1.1 requires in-app purchase to unlock features or functionality in the app, such as subscriptions, in-game currency, levels, premium content or a full version. You can’t use your own unlock mechanisms such as unlock codes or QR codes. Guideline 2.1(b) requires in-app purchases to be complete, visible and functional, and if one can’t be found, the review notes must explain why.
Fix. Switch memberships, virtual currency and paid content to in-app purchase, and submit the in-app purchase items for review along with this version. Physical goods and services used outside the app fall under 3.1.3(e) and must use a payment method other than in-app purchase, such as Apple Pay or a card. Real-time one-to-one services between people, such as tutoring or medical consultations, may use other payment methods under 3.1.3(d).
In your reply. State which category each paid item belongs to and cite the guideline number. If the reviewer couldn’t find an in-app purchase, describe how to reach it.
6. 4.2 Minimum Functionality, a website in a wrapper
Typical wording. The app’s features and content are limited, and the experience is about the same as the website. It isn’t “app-like” enough.
Cause. Guideline 4.2 requires an app to offer features, content and UI beyond a repackaged website. Guideline 4.2.2 says that apart from catalogs, apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators or collections of links.
Fix. Add native capabilities a website can’t offer, such as offline use, push notifications, the system share sheet, widgets or camera scanning, or rebuild the core flows as native screens. For WebView projects like uni-app or Cordova, give at least the home screen and the main flow app-specific interactions.
In your reply. List what the app offers beyond the website, with screenshots or a screen recording, and explain the value to users.
7. 4.3 Spam, duplicate apps
Typical wording. The app duplicates another app you submitted, or doesn’t differ from the many similar apps already on the store.
Cause. Guideline 4.3(a) prohibits creating multiple Bundle IDs for the same app, for example one map app per city. Guideline 4.3(b) prohibits submissions that don’t differ from existing apps and names categories such as flashlights, wallpapers, simple timers and fortune telling, unless the experience is clearly different or better. Shipping the same codebase reskinned for several clients is often rejected under this guideline too.
Fix. Merge multiple versions into one app and offer the regional or client differences through in-app settings or in-app purchase. If you really are building a similar app, make the distinctive features substantial. For custom apps built for different clients, have each client submit with their own developer account.
In your reply. Explain how this app differs from the others in your account, who it’s for and what only it does. Don’t resubmit with only a new icon and name.
8. 4.8 Login Services, third-party sign-in only
Typical wording. The app uses a third-party login service as the primary way to sign in, but doesn’t offer an equivalent login option that meets the requirements.
Cause. Guideline 4.8 says apps that use a third-party or social login service to set up or authenticate the primary account must also offer another login service. The guidelines give Facebook Login, Google Sign-In, Sign in with X, Sign In with LinkedIn, Login with Amazon and WeChat Login as examples. The other service must limit data collection to name and email, let users keep their email private, and not collect interactions for advertising without consent.
Fix. Add Sign in with Apple, or another login option that meets these three points, at the same level as the third-party buttons. Apps that only use their own account and password system aren’t affected.
In your reply. Say which login option you added and where it is on the sign-in screen.
9. 5.1.1(i) Missing or broken privacy policy
Typical wording. The privacy policy link doesn’t work, or the policy doesn’t clearly state what data is collected, how it’s used and how it can be deleted.
Cause. Guideline 5.1.1(i) requires a privacy policy link both in the App Store Connect metadata and in the app. The policy must state what data the app collects, how and for what purpose, confirm that third parties provide equal protection, explain data retention and deletion, and say how users can revoke consent and request deletion.
Fix. Host the privacy policy on a publicly reachable web page and link it from the app’s settings or about screen. Fill in each point above, including data collected by third-party SDKs.
In your reply. Give the new link and where it appears in the app. This usually only involves metadata.
10. 5.1.1 Permission requests and data minimization
Typical wording. A permission’s purpose string is unclear. The app requires users to grant access before they can continue. The app requests data unrelated to its core function.
Cause. Guideline 5.1.1(ii) requires consent before collecting data, prohibits making paid features depend on granting access, and requires a way to withdraw consent. Guideline 5.1.1(iii) says to request only the data the core function needs and to use system pickers, such as the photo picker, instead of asking for full access where possible. Guideline 5.1.1(iv) prohibits manipulating, tricking or forcing users into consent. Purpose strings for the camera, photos, location and so on live in Info.plist NS…UsageDescription keys, and vague ones get rejected too.
Fix. Describe the specific use in each purpose string, for example “Used to scan package tracking numbers.” Let the app keep working with other features after a user declines. Don’t put a “you must allow this” screen in front of the system permission alert. For how to write each key, see Info.plist usage descriptions.
In your reply. List where each permission is used and what the app does if the user declines. If you changed Info.plist, build again and upload.
11. 5.1.1(v) Forced sign-up and account deletion
Typical wording. The app requires registration for features that don’t depend on an account. The app lets users create an account but offers no way to delete it in the app.
Cause. Guideline 5.1.1(v) says apps without significant account-based features must let people use them without signing in, and apps that support account creation must let users delete their account in the app. Apple’s account deletion guidance adds that the option must be easy to find, usually in account settings, and must delete the whole account and its personal data. Offering only to disable or suspend the account isn’t enough.
Fix. Let guests use browsing features. Add Delete Account to the settings screen and delete the account and its data after confirmation. If deletion has to finish on a website, link directly to the deletion page. Unless your app is in a highly regulated industry, don’t make users call, email or contact support to delete their account. If you use Sign in with Apple, revoke tokens with the REST API as the guidance describes.
In your reply. Give the full path to account deletion, such as “Profile > Settings > Account > Delete Account”, with a screen recording.
12. 5.1.2 Data use and sharing, tracking permission
Typical wording. The app uses collected data for tracking without requesting permission through App Tracking Transparency. Or the app’s privacy information doesn’t match what the app actually does.
Cause. Guideline 5.1.2(i) says you can’t use, transmit or share personal data without permission, sharing with third parties (including third-party AI) requires clear disclosure and explicit permission, and tracking user activity requires permission through App Tracking Transparency. Guideline 5.1.2(ii) says data collected for one purpose can’t be repurposed without consent.
Fix. If you use advertising or attribution SDKs, show the ATT prompt before requesting the advertising identifier and add NSUserTrackingUsageDescription to Info.plist. If you send data to a third-party AI service, disclose it and get consent first. Review the App Privacy questionnaire in App Store Connect so it matches what the app and its SDKs actually do.
In your reply. Explain when and where the ATT prompt appears, or state that the app doesn’t track users and that the privacy information has been updated.
Why do privacy emails arrive before review even starts?
Two kinds of privacy problems usually arrive by email when you upload a build, before any human review.
- A missing purpose string in Info.plist for a permission. See ITMS-90683 in App Store upload ITMS errors.
- Code or a third-party SDK that uses a required reason API without declaring it in
PrivacyInfo.xcprivacy, which triggers ITMS-91053. As of October 2026, Apple’s documentation states that since May 1, 2024, App Store Connect doesn’t accept apps that don’t declare them.
For how to write a privacy manifest, see Write an iOS privacy manifest (PrivacyInfo.xcprivacy) and declare required reason APIs. When you use KXBuild on Windows or Linux, double-click Info.plist or the .xcprivacy file to edit it in the Property List Editor.
Rejection reasons and fixes at a glance
| Guideline | Common rejection reason | Main fix | New build needed |
|---|---|---|---|
| 2.1 | Crashes, blank pages, placeholder content, backend offline | Fix and retest on a device running the latest iOS | Yes |
| 2.1 | Demo account doesn’t work, missing test instructions | Provide a long-lived account and steps | Usually not |
| 2.3 | Screenshots aren’t real screens, overstated description, other platform names | Update screenshots, description and keywords | Usually not |
| 2.5.1 | Non-public APIs, frameworks used for the wrong purpose | Update or remove the SDK, remove unused frameworks | Yes |
| 3.1.1 | Digital content sold through external payment, in-app purchase not found | Switch to in-app purchase and submit it with the version | Usually |
| 4.2 | Website in a wrapper, too few features | Add native capabilities and native screens | Yes |
| 4.3 | Duplicate apps under several Bundle IDs, look-alike apps | Merge apps, make them distinct | It depends |
| 4.8 | Third-party sign-in only | Add Sign in with Apple or an equivalent option | Yes |
| 5.1.1(i) | Missing or incomplete privacy policy | Complete the policy and link it in the app | Usually not |
| 5.1.1(ii)–(iv) | Vague purpose strings, forced permission | Describe the use, keep the app usable after declining | Yes |
| 5.1.1(v) | Forced sign-up, no account deletion | Allow guest use, add in-app account deletion | Yes |
| 5.1.2 | Tracking without ATT permission, privacy information doesn’t match | Add the ATT prompt, update the App Privacy questionnaire | It depends |
How do you reply to App Review and appeal a rejection?
Reply to App Review
After a rejection, reply in App Store Connect first. It’s the main channel for talking to the review team. Follow Apple’s help article.
- In Apps, select the app and click the link in the notice about unresolved issues at the top of the page.
- In the In Progress section, click Resolve next to the submission.
- Click Reply to App Review, write your reply, click Attach File to add screenshots or documents if needed, then click Reply.
Only the Account Holder, Admin and App Manager roles can reply. Replies are limited to 4,000 characters, and you can keep exchanging messages until you resubmit. If the rejection was about metadata, you can resubmit the same build after fixing it.
When you write the reply, do three things.
- Address each rejection reason in turn, saying what you changed and where to see it.
- If the reviewer misunderstood a feature, explain how it’s meant to work with steps and a screen recording.
- Stay factual. Don’t argue that other tools or apps do the same thing.
Appeal to the App Review Board
If you still disagree after replying, you can appeal to the App Review Board. See Apple’s appeal instructions. Apple asks you to reply to the review message first and appeal only if that doesn’t resolve it. Submit one appeal per rejected submission, explain why the app complies with the guidelines, and answer any information the review team asked for first. The result arrives as a message in App Store Connect.
The appeal form isn’t for chasing or speeding up a review. If you’re short on time, use Apple’s expedited review request, and only when it’s really needed. To find out ahead of time whether a feature complies with the guidelines, book an online meeting with the review team on the App Review page.
If your app is already on the App Store and you’re submitting a bug fix, the guidelines say the fix won’t be delayed over other guideline issues, except for legal or safety concerns. You can tell the review team in App Store Connect that you’d like to ship the bug fix now and address the issues they raised in your next submission, so one App Store rejection doesn’t hold up a live fix.
FAQ
How soon can I resubmit after an App Store rejection?
You can resubmit as soon as you’ve made the fix. There’s no waiting period. Resubmit the same build if you only changed metadata, or upload a new build with a higher build number if you changed code. According to Apple, the review team typically reviews at least 50% of submissions within 24 hours and 90% within 48 hours.
Do I need to upload a new .ipa if the rejection was about metadata?
No. For screenshots, the description, keywords, the privacy policy link or the demo account, make the change, reply on the App Review page and resubmit the same build.
What should I do after a Guideline 4.3 Spam rejection?
First check whether your account has other apps with the same features, and merge them into one if so. Then build features that clearly set the app apart from similar ones and explain each difference in your reply. Resubmitting with only a new icon and name usually gets rejected under the same guideline again.
Is App Review stricter for apps built on Windows?
No. App Review follows the guidelines and looks at the app’s features, stability, privacy handling and store listing. The computer you built on doesn’t matter. Apple makes the final decision according to the guidelines.
Will appealing to the App Review Board get my app approved?
Not necessarily. An appeal asks the board to evaluate the app again, and Apple makes the decision. Explain the feature clearly in your reply before appealing, because many misunderstandings are resolved at that stage.