App Store rejection: how to fix it, guideline by guideline (2026)

An App Store rejection is a message from App Review that cites a guideline, says what the reviewer saw and holds the release until you fix it, explain it or appeal. Start by turning that message into an issue you can test. The next step depends on whether the reviewer couldn't use the app, found a policy mismatch or needs more information. As of October 2026, the App Review Guidelines were last updated on October 16, 2026, so check the live numbering before you quote a section.

What does an App Store rejection message actually tell you?

An App Store rejection message names the guideline the reviewer applied, describes the specific behavior they saw and lists next steps. It often includes the device, the iOS version and screenshots.

Save the full message, any screenshots, the build number and the device details. Read the cited section on the live guidelines page. Then write one sentence: "The reviewer could not complete X because Y." If the message asks for missing information rather than reporting a defect, write down exactly what is missing. Apple's standard 2.1 text also tells you how to reproduce the issue: "For new apps, uninstall all previous versions of your app from a device, then install and follow the steps to reproduce the issue."

• Does the message name a crash, an inaccessible screen or an incomplete feature? Reproduce that flow in the submitted release build, on the device type Apple named.
• Does it name screenshots, the description or review notes? Check whether you can fix it in metadata alone.
• Does it name payments, login, privacy or minimum functionality? Compare the product's behavior with the cited guideline.

Which guidelines do App Store rejections cite, and what do they require?

Each guideline sets a concrete requirement, so match the cited number to its wording and test against that wording. The table quotes the current text of the guidelines that rejection messages commonly cite.

The October 16, 2026 update added 2.5.19 for hidden, dormant or undocumented features, which used to be covered under 2.3.1. It also added 2.3.14 on creative assets and folded the Music Streaming Services entitlement into the StoreKit External Purchase Link entitlement under 3.1.1(a). Treat the table as a starting point, not a guaranteed fix. One guideline can cover different problems, and the reviewer's example is the concrete case you have to resolve.

How do you fix a 4.2 minimum functionality rejection?

Fix a 4.2 rejection by adding real app value, not by rewording the description. Guideline 4.2 says: "If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store."

Ask what someone can do in your app that makes it useful as an app. They might complete a workflow, save meaningful state, use device capabilities in a way that fits the app, or get a mobile experience built for the device. No published feature list guarantees approval. If those workflows already exist, list them in review notes with exact steps and screenshots. If the app mostly shows a web page, it needs product work. Adding notifications or an empty settings screen just to look native doesn't replace real value for users.

How do you reply to App Review in App Store Connect?

Reply in App Store Connect: open the submission from the app's unresolved issues link, click Resolve, then click Reply to App Review. Per Apple's help page, this requires the Account Holder, Admin or App Manager role.

1. In Apps, select the app.
2. At the top of the page, click the link that indicates there are unresolved issues.
3. In the In Progress section, click Resolve next to the submission.
4. Click Reply to App Review and enter your text.
5. To include screenshots or documents, click Attach File, then click Reply.

Apple says you can correspond and attach files "until you resubmit to App Review", so send your evidence before you resubmit. Keep the reply short and factual: say what changed, where it is and how to verify it. Don't argue about other apps that seem to do the same thing.

Should you fix metadata, upload a new build or appeal?

Fix metadata and resubmit the same build when only listing information was wrong. Upload a new build when the app's behavior has to change. Appeal only when you believe the app already complies with the guideline.

Apple's appeal guidance asks you to "explain point by point how your app meets" the guideline. It also says not to appeal after you've already fixed the issues and resubmitted. A complete appeal "does not guarantee" that the decision will be overturned. For apps already on the store, the guidelines' Bug Fix Submissions policy says bug fixes won't be delayed over guideline violations "except for those related to legal or safety issues".

How did other developers fix real App Store rejections?

In public forum threads, many 2.1 rejections came from differences between the reviewer's setup and the developer's: a different network, device or permission state. A 4.2 rejection is a product problem, so small tweaks rarely clear it.

Login error under 2.1. A developer on the Apple Developer Forums quoted the message "Specifically, we were not able to log in due to an error", even though the live and TestFlight versions logged in with the same credentials. Other developers in the thread reported different fixes. One fixed it by "changing http to https on web server". Another, after three rejections, added a "Check your connection" state instead of an endless loader. A third removed iPad from the deployment target after five rejections, which works around the problem by dropping iPad support.

Crash on launch. On the Solar2D forum, a developer was told "We were unable to review the app because it crashed on launch" on an iPhone 13 mini running iOS 18.3.2. The attached crash log showed a missing NSUserTrackingUsageDescription key. The developer confirmed: "It passed after adding : NSUserTrackingUsageDescription."

WebView app under 4.2. A developer on the Apple Developer Forums reported a 10th rejection for a WebView-based app. The reviewer had sent a screenshot of the left menu saying it lacked content. The main screens were now native, but two or three still opened a WebView. The reply marked as the answer came from App Review and recommended a one-on-one App Review consultation. The thread doesn't confirm an approval.

The comparison: the 2.1 cases were fixed by reproducing the reviewer's conditions and reading the crash log. The 4.2 case stalled because each resubmission changed only part of an app that was still mostly a website.

How do you stop the same rejection from happening again?

Turn each resolved issue into a release-checklist item and retest it in the release build before every submission. Apple's guidelines warn that review "will take longer" if an app is repeatedly rejected for the same guideline violation.

• Delete the app, then install the release build fresh on a physical iPhone and iPad.
• Log in with the review account on a network with no development servers or HTTP exceptions.
• Open every permission prompt and confirm that each Info.plist usage description exists.
• Make sure every in-app purchase is submitted, visible and explained in review notes.
• Update the review notes whenever a flow changes. Don't paste notes from six releases ago.

For 2.1 issues, follow the release-build test plan for 2.1 rejections and set up a reviewer demo account. Then work through the submission checklist for the next build. If the review message still leaves you stuck, send us the details and we'll help you work out whether the missing piece is access, metadata or code.