The 12 Most Common App Store Rejection Reasons in 2026 (and How to Fix Them)

Roughly a third of first-time iOS app submissions get rejected. That number has been remarkably stable for a decade. The reasons cluster into a smaller set than you would think; almost all of them are variations on twelve recurring patterns.

This guide lists each one with the guideline section, the typical reviewer wording, and the smallest change that usually gets the app through on resubmission. The canonical reference is Apple's own App Store Review Guidelines, which is worth bookmarking. The list below is what we have actually seen rejected in 2025 to 2026.

1. Web wrapper detection (Guideline 4.2)

Typical wording: "Your app does not include enough native functionality, features, or content to be appropriate for the App Store."

Apple has been increasingly aggressive about rejecting apps that are essentially a WKWebView pointed at a website. The 2024 to 2026 era of this enforcement reads as a step-change: if your app's main functionality is loading a remote URL and rendering it as HTML, you will almost certainly be rejected.

The fix: Add real native functionality that the website cannot do. Push notifications, offline mode (the app works without an internet connection for cached content), device-feature integration (camera scanning, GPS-aware features, contacts), and a meaningfully native user experience are the four that reliably pass review. One of these is sometimes enough. Two is safer. Apple's developer news on minimum-functionality enforcement is the canonical guidance.

2. Missing or inadequate privacy policy (Guideline 5.1.1)

Typical wording: "We were unable to access your app's privacy policy."

Every iOS app needs a privacy policy URL in App Store Connect. The URL has to be live at submission time, owned by you (no Google Doc / Notion shared link), and accurate to what your app actually collects.

The fix: Host a real privacy policy at a stable URL on your own domain. Free generators like TermsFeed's privacy policy generator or Iubenda produce reviewer-acceptable text in a few minutes. Update the policy whenever your data collection changes.

3. Broken or unhelpful sign-in (Guideline 4.8 and 5.1.1)

Typical wording: "We were unable to log in to your app with the demo account provided" or "Your sign-in implementation does not meet the requirements of Guideline 4.8."

Two sub-reasons get bundled here. First, you provided demo credentials in App Store Connect that do not work. Apple's reviewers will literally try them, and if they fail, you are rejected. Second, you offer a third-party login (Google, Facebook) but do not offer Sign in with Apple as an alternative.

The fix: Test the demo credentials yourself the day before submission. If you offer Google or Facebook login, add Sign in with Apple as an equivalent option. Guideline 4.8 was loosened in 2022 so that you do not strictly need Sign in with Apple, but you do need to offer comparable email-based or anonymous-account options.

4. Paid features without In-App Purchase (Guideline 3.1.1)

Typical wording: "Your app uses a payment mechanism other than in-app purchase to purchase content, features, or services consumed in the app."

If your app sells digital content (subscriptions, virtual currency, premium features), Apple requires you use In-App Purchase. You can not link out to a Stripe checkout for those. The big exceptions are physical goods, services consumed outside the app (Uber rides, restaurant delivery), and "reader" apps (Netflix, Spotify, Kindle) that meet specific criteria.

The fix: If you sell digital content, implement IAP. There is no clean workaround. If you sell physical goods or external services, make sure the reviewer can see that clearly (mention it in the review notes, screenshot the physical-goods flow).

5. Incomplete or misleading metadata (Guideline 2.3.0)

Typical wording: "Your app's metadata mentions or references the names of other third-party platforms" or "The screenshots provided are not representative of the app's functionality."

The two big sub-rejections here are: mentioning competing platforms in your description (do not name "Android" in an iOS app description if you can avoid it), and using mocked-up screenshots that show features the app does not have.

The fix: Write a clean description that describes what your app does without referencing other platforms by name. Take real screenshots from the actual app. Apple does not care if the screenshots are styled, but they must show real screens.

6. Crashes during review (Guideline 2.1.0)

Typical wording: "Your app crashed on launch" or "Your app exhibited bugs during review."

Apple's reviewers run your app on physical devices. If it crashes during launch or in a basic flow, you are immediately rejected. The most common cause in 2026 is the reviewer testing on an older device (the iPhone SE 3 is still in the test fleet) when the developer only tested on the latest hardware.

The fix: Test on at least one older supported device. Many no-code platforms now let you specify the minimum iOS version; in 2026 the common floor is iOS 16. Set it deliberately, do not let it default.

7. Inadequate or misleading app purpose (Guideline 4.3 and 4.0)

Typical wording: "Your app duplicates the content and functionality of other apps already on the App Store."

Apple introduced "app spam" enforcement in 2017 and tightened it through 2024 to 2026. If your app is one of fifty near-identical templates submitted by a single developer (or a co-marketing chain), it gets rejected.

The fix: If you are a freelancer or agency submitting white-labelled apps for clients, submit each one under the client's own Apple Developer Program account, not yours. Apple's clarification on app spam is the canonical guidance.

8. Missing localisation (Guideline 2.3.0 and 5.1.1)

Typical wording: "Your app contains content in a language other than the languages you have indicated support for."

If your app's metadata claims English support but the app interface is in Spanish, you are rejected. The reverse also applies.

The fix: Make the supported-languages list in App Store Connect match what the app actually supports. If you only ship English, do not check Spanish.

9. Permissions requested without clear justification (Guideline 5.1.1)

Typical wording: "Your app requests permission to access [Contacts/Photos/Microphone/Location] but does not explain why."

Every permission prompt your app shows must have a clear, specific NSUsageDescription string explaining why the permission is needed. Generic "We use your camera to take photos" wording often gets flagged.

The fix: Write specific NSUsageDescription strings: "We use your camera to scan QR codes for table reservations" is better than "We use your camera". Apple's own protected resources documentation covers each permission's expected wording.

10. Test account access is missing for accounts-required apps (Guideline 2.1)

Typical wording: "Your app requires an account to use but we were unable to create one or access content without one."

If your app requires sign-up before any meaningful functionality, you must provide reviewers with a demo account in App Store Connect.

The fix: Either provide a working demo account in the review notes, or make some of the app usable without sign-in. The second option is also better product design.

11. Subscription disclosure issues (Guideline 3.1.2)

Typical wording: "Your app does not include a complete description of the subscription terms before the user can purchase."

Subscriptions have specific disclosure requirements: the price, the renewal period, the trial terms (if any), the cancellation flow, and a link to your terms and privacy policy must all be visible on the subscription purchase screen. Apple has been increasingly strict about this since 2024.

The fix: Add the four required elements explicitly to your subscription paywall screen. Use Apple's recommended wording: "Subscription auto-renews. Cancel anytime in Settings."

12. App icon or launch screen issues (Guideline 4.0)

Typical wording: "Your app's icon or launch screen is inconsistent with the rest of the app's design."

This one is fuzzy but real. Apple rejects apps with low-resolution icons, icons that do not match the app's branding, or launch screens that show advertising-like content.

The fix: Use a 1024x1024 PNG icon. Make sure the launch screen is a simple version of your app's first content screen (Apple's Human Interface Guidelines on launch screens are clear: it should look like a snapshot of your first screen with placeholders).

What to do when you get rejected

Three things, in order:

1. Read the rejection notice carefully. Apple usually cites a specific guideline section. The guideline is your roadmap to the fix.
2. If the rejection is unclear, reply in Resolution Center. Resolution Center is the in-Connect messaging system where you can ask for clarification. Replies usually come within 24 hours and are often much more specific than the initial rejection.
3. If you disagree with the rejection, file an appeal via the App Review Board. Roughly 20 percent of appeals succeed, but even unsuccessful ones produce useful clarification.

The single most important thing is to address the rejection on its own terms. Do not resubmit with unrelated changes and a "we fixed it" note. Reviewers see the same app again and re-reject it.

How to keep first-submission success high

The two things that correlate most strongly with first-submission success in 2026:

• Native functionality that is obviously not just a web wrapper. Push notifications, offline mode, and camera integration are the three most reliable signals to the reviewer that your app is "real".
• Complete metadata. Privacy policy URL, demo credentials, accurate language list, real screenshots, specific permission justifications. Each one of these is a quick fix; missing any one of them can stall you for a week.

Apple's review queue has gotten faster in 2026 (median first-submission turnaround is around 3 days), but the rejection rate has not budged. The way to ship fast is to not get rejected.

Bottom line

Most rejections are not surprises. They are the same dozen issues repeated across thousands of apps each month. Read the guidelines once, build to them, and check your submission against this list before hitting submit. The cost of an extra hour of preparation is much less than the cost of a week of waiting for a re-review.