How to Pass App Store Review in 2026 (and Avoid Rejection)

If you want to know how to pass App Store review in 2026, start with how the situation has changed. AI coding tools made it possible to build and submit an app in an afternoon, and a lot of people did. Developers have been reporting App Store review taking too long, and reviewers now see many near-identical, low-effort, vibe-coded apps. Apple disputes that review times are getting longer. Either way, the pile of submissions your app competes with for a reviewer’s attention has changed.

That changes how you should prepare. A reviewer who has just looked at ten wrapped websites and five cloned habit trackers isn’t going to dig for what makes your app good. You have to make it obvious.

This guide comes down to one idea: reduce the scope of what Apple has to audit. Ship fewer native features, make each one solid, and make your app’s edge impossible to miss. That approach covers the two rejections that hit new apps hardest in 2026: guideline 4.2 (Minimum Functionality) and guideline 4.3 (Spam).

Why App Store review is taking so long in 2026

There is no official public number for current wait times, so be careful with any specific figure you read. Here’s what we can say:

• Developers, including established teams, have reported submissions sitting in “Waiting for Review” for longer than they used to (9to5Mac, Business Insider).
• Apple’s position, as reported by 9to5Mac, is that review times are not getting longer, and that it processes 90% of submissions within 48 hours.
• Apple’s own App Review guidelines say that complex apps may need “greater scrutiny,” and that apps “repeatedly rejected for the same guideline violation” take longer to review.

That last point is the one you control. The slowest path through App Store review is getting rejected and resubmitted. Every rejection sends you back into the queue. So the goal is to pass the first time.

The most common App Store rejection reasons

Apple publishes the numbers. In its 2025 App Store Transparency Report, Apple reports 2,093,244 rejected submissions. By guideline section, Performance (1,354,418) is far ahead of Legal (495,673), Design (415,532), Business (283,820), and Safety (151,159). One submission can be rejected under more than one section.

Apple’s App Review page also says that on average, over 40% of unresolved issues relate to guideline 2.1: App Completeness, which covers crashes, placeholder content, and incomplete information.

In practice, the App Store rejection reasons developers run into most are:

1. 2.1 App Completeness: crashes, broken demo accounts, dead backends, placeholder content.
2. 5.1.1 Data Collection and Storage: missing privacy policy, vague permission strings, missing account deletion.
3. 2.3 Accurate Metadata: screenshots or descriptions that don’t match the app.
4. 4.2 Minimum Functionality: “this is just a website.”
5. 4.3 Spam: “this is like apps that already exist.”

The checklist below handles items 1 to 3. Items 4 and 5 are where scope and differentiation come in, and they’re the focus of this guide.

Why scope is the real problem

Each feature you submit is something a reviewer can open, test, and reject. Each permission prompt, login provider, in-app purchase, and SDK pulls in more guidelines:

• Add a social login and guideline 4.8 applies, so you may need an equivalent privacy-friendly login option.
• Add account creation and 5.1.1(v) means you must also offer in-app account deletion.
• Add location and you need a purpose string that justifies it, plus a fallback for users who decline.
• Add a subscription and you’re subject to all of 3.1.2, plus the IAP checks in 2.1(b).
• Send user data to a third-party AI service and 5.1.2(i) requires you to disclose it and get explicit permission.

None of these rules is unreasonable. But together they add up: with more surface, the odds go up that one item fails, and one failed item rejects the whole build.

So the strategy for a first submission is to launch with the smallest version of your app that is clearly useful, clearly native, and clearly yours. You can grow it after approval.

How to avoid a guideline 4.2 Minimum Functionality rejection

Guideline 4.2 is the rule that hits web-based apps and web wrappers hardest:

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store.

4.2.2 adds that apps shouldn’t primarily be “marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” And 4.2.6 rejects apps “created from a commercialized template or app generation service” unless the provider of the app’s content submits them directly.

The usual mistake is to answer 4.2 by adding every plugin available: camera, contacts, geolocation, haptics, share sheet, biometrics, all at once. That doesn’t make an app feel native. It makes it feel unfocused, and each plugin brings its own permission prompt and privacy disclosure.

What you want is one or two native features that the core use case actually needs, where a reviewer can see right away why a website couldn’t do the same job.

Good native features to pick

How to choose your one or two features

Ask three questions about each candidate:

1. Would my core user notice if it were missing? If not, cut it from v1.
2. Can a reviewer see it working in under a minute, using the demo account? If it only shows up after three days of use, it won’t help you in review.
3. Does it pull in a sensitive guideline area (health, kids, payments, location tracking, user-generated content)? If so, add it only when it is the core of the app.

A few examples:

• A field inspection tool: camera capture plus offline sync. Skip contacts, skip social login.
• A medication reminder: local notifications plus a widget showing the next dose. Skip HealthKit until you need it, because it brings strict health-data rules.
• A team status dashboard: push notifications for incidents plus Face ID unlock. That’s enough.

Two well-built native features that are central to the app are a stronger answer to 4.2 than eight half-integrated ones.

How to pass guideline 4.3 Spam: be clearly different, and say so at the top

The second rule that catches AI-assisted apps is 4.3 (Spam), along with 4.1 (Copycats). 4.3(b) is blunt:

Don’t submit apps that are indistinguishable from what’s already widely available.

It names categories Apple considers saturated: dating, flashlight, sound effects, wallpaper, simple timers, fortune telling. In those categories Apple says it won’t accept new submissions “unless they offer a meaningfully different or improved experience.”

Developers also report “Guideline 4.3(a) - Design - Spam” rejections saying the app shares a similar binary, metadata, or concept with apps from other developers. If your app was generated from a common prompt or starter template, assume a reviewer has already seen something close to it.

What happened to us with 4.3 Spam

We hit this rule ourselves at Capgo. We built several apps on top of the same app shell, with the same structure, the same screens, and only the content changing between them. Then we pushed them all to review at the same time.

From Apple’s side, that looks exactly like a spam farm: one developer account sending a batch of near-identical binaries into the queue at once. The apps were flagged under 4.3 Spam, and it took a lot more work to get out of that situation than it would have taken to avoid it.

What we do now, and what we recommend:

• No shared app shell across apps. If two apps have the same layout, navigation, and screens with different content, Apple sees one app submitted twice. Each app needs its own structure, its own UX, and its own reason to exist. If the content is the only difference, ship one app with that content inside it.
• No batch submissions. Don’t push several apps to review at the same time, especially new ones from the same account. Submit one, get it approved, then space out the next ones.
• No near-duplicate metadata. Different apps need different names, descriptions, screenshots, and keywords, not one template with words swapped.
• One app per real product. Variants for different cities, clients, or niches belong in one app with a selector, unless each one is truly a different product.

The 4.3(a) wording is direct about this: “Don’t create multiple Bundle IDs of the same app,” and if you have several versions of an app for specific locations, sports teams, universities, or similar, “consider submitting a single app and provide the variations using in-app purchase.” Repeated spam can also put the whole developer account at risk, not just one app.

Find your real edge

An edge is something concrete a user gets from your app that they won’t get from the top five results for your main keyword. For example:

• A specific audience the generic apps ignore (e.g. shift workers, not “everyone”)
• A workflow the others don’t support (e.g. works with your existing hardware or data source)
• A constraint you handle that others don’t (offline-first, privacy-first, no account required)
• Domain knowledge built into the product (rules, templates, or data from a real profession)

“Clean design” and “AI-powered” aren’t edges in 2026. Every clone claims both.

Put the edge in the first lines of your App Store description

Reviewers and users both read the top of your App Store description first. Use it to answer one question: why does this app exist when the others already do?

Weak opening:

Introducing FocusFlow, the ultimate productivity app! Stay focused, build better habits, and achieve your goals with our beautiful, easy-to-use timer. Powered by AI.

This could describe dozens of apps already on the store. It’s a “simple timer,” which 4.3(b) names directly.

Strong opening:

FocusFlow is a focus timer for night-shift nurses. It schedules breaks around 12-hour shifts, works fully offline in hospital dead zones, and shows your next break on a lock screen widget, so you never need to unlock your phone on the floor.

In two sentences a reviewer learns the audience, the problem, and the native features (offline, widget). It reads like a product, not a clone.

Then back it up in the App Review notes. Write two or three sentences saying who the app is for, what makes it different, and exactly where to find the native features. 2.3.1(a) says new features “must be described with specificity in the Notes for Review section” and that “generic descriptions will be rejected.” Treat the notes as a short guided tour.

App Store review checklist for 2026

Most of this comes straight from Apple’s “Before You Submit” section and guideline 2. Go through it before every submission:

• Demo account works and has every feature unlocked, including paid ones (2.1(a)). Test it yourself from a fresh install the day you submit.
• Backend is live and reachable from outside your network during review.
• Review notes explain the edge, list the native features, and say where to find them. Explain any non-obvious flows and every IAP.
• No placeholder content: no lorem ipsum, “coming soon” screens, empty tabs, or broken links (2.1(a)).
• Screenshots show the app in use and match the submitted build. No splash screens or login-only shots (2.3.3).
• Metadata is accurate: name, subtitle, and description only promise what the build does (2.3). No competitor names or keyword stuffing (2.3.7).
• Privacy policy is linked in App Store Connect and inside the app (5.1.1(i)).
• Privacy details in App Store Connect match reality, including what third-party SDKs and analytics collect.
• Every permission has a specific purpose string and a fallback if the user says no (5.1.1(ii), (iv)).
• Account deletion is available in the app if you allow account creation (5.1.1(v)).
• No login wall if the app doesn’t need accounts (5.1.1(v)).
• IAPs are configured, visible, and working in sandbox (2.1(b)). See how to pass App Store review with in-app purchases for the IAP-specific checks.
• Tested on a real device, including airplane mode and denied permissions. Crashes are rejected under 2.1(a).
• Support URL and contact info are real and reachable (1.5).
• Nothing hidden: no dormant features or remote flags that unlock functionality the reviewer can’t see (2.3.1(a)).

Every unchecked item is a likely rejection, and every rejection means another wait in the queue.

App Store rejected? How to reply or appeal

If you’re rejected anyway, Apple’s guidelines describe two options:

1. Reply in App Store Connect. Answer the exact guideline cited, not the general tone of the message. For 4.2 or 4.3, be specific: who the app is for, which native features it has, where to find them, and how it differs from the apps a reviewer might compare it to. A short screen recording of the app helps.
2. Submit an appeal to the App Review Board if you believe the reviewer got it wrong.

For a step-by-step process, see our guide on how to respond to an App Store rejection.

Before you do either, fix the cause if there’s a real one. If you’re cited under 4.3, changing only the screenshots usually won’t help. Narrowing the audience and making the edge visible in the app and the description will.

For apps that are already live, Apple also says bug fix submissions won’t be delayed over guideline violations, except for legal or safety issues. Ask for this in App Store Connect and commit to addressing the issue in your next submission.

Why Capacitor, React Native and Cordova apps often have an easier time

This part is my own experience, not a statistic. Working with many teams that ship Capacitor apps through Capgo, plus React Native and older Cordova projects, I’ve seen cross-platform apps tend to get through App Store review with less friction than people expect. My explanation:

• The native layer is thin and standard. These apps use well-known, widely used plugins for camera, push, storage, and biometrics. Reviewers see these integrations all the time, and they behave predictably.
• The native scope is naturally small. You add plugins on purpose, one at a time, which matches the “one or two real native features” approach above.
• The app is a real product, not a URL in a frame. A Capacitor app ships its HTML, CSS and JavaScript inside the binary and loads them locally, with native plugins on top. That’s different from a web wrapper pointing at your website, which is exactly what 4.2 targets.

Cross-platform isn’t a shortcut, though. A Capacitor app that’s just your marketing site will be rejected like any other web wrapper. The framework only helps when you follow the scope rules.

The first review is the hardest. Updates are still painful

Your first approval is the biggest hurdle, because Apple is judging the whole concept. But updates go through the same queue. A typo fix, a broken button, or a copy change can still sit waiting, and any update can be rejected for something unrelated that a reviewer notices this time.

That’s why many teams separate native releases from web-layer releases.

Live updates, within Apple’s rules

Apple’s rule here is in the Apple Developer Program License Agreement, section 3.3.1(B) “Executable Code”. The current text reads:

Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application (b) does not bypass signing, sandbox, or other security features of the OS; and (c) for Applications distributed on the App Store, does not create a store or storefront for other Applications.

App Review Guideline 2.5.2 is the review-side rule: apps may not “download, install, or execute code which introduces or changes features or functionality of the app.” Read the two together and the line is clear. JavaScript, HTML and CSS are interpreted code. Updating them is allowed as long as the app stays the app Apple reviewed.

In practice, live updates are appropriate when you:

• Fix bugs in your JavaScript, HTML or CSS
• Adjust UI, copy, layout, or content
• Improve existing, reviewed features without changing what they do

New features, or changes to how an existing feature works, should ship in a reviewed binary.

And they’re not appropriate when you:

• Change the app’s purpose. The note-taking app doesn’t become a casino.
• Change pricing, offers, or how purchases work. Business model changes go through review (see 3.1 and 2.3).
• Do anything deceptive after the user downloads: hidden features, bait-and-switch behavior, or content the reviewer never saw (2.3.1(a), 5.6).
• Change native code, add plugins, or request new permissions. Those need a new binary.

Inside those limits, a live update tool lets you ship the small changes without waiting on review for each one. That’s what Capgo does for Capacitor apps: you upload a new web bundle from your CI, devices download it in the background, and if something breaks you can make the previous bundle active on the channel immediately. Devices pick up the rollback the next time they check for an update. For more on the policy side, see Does Apple allow live updates?.

FAQ

How long does App Store review take in 2026?

Apple says it processes 90% of submissions within 48 hours (as reported by 9to5Mac). Some developers report much longer waits in 2026. There’s no reliable public tracker, so plan for some variance and avoid rejections, which add a full extra wait each time.

Why is my App Store review taking so long?

A higher volume of submissions, a complex or sensitive app (health, finance, kids, payments), or a history of repeat rejections can all slow review. Apple’s guidelines say complex apps may need greater scrutiny and repeat violations take longer. If you have a critical deadline, you can request an expedited review, but Apple asks you to use it only when you really need it.

What is the most common reason for App Store rejection?

Guideline 2.1, App Completeness. Apple says over 40% of unresolved issues relate to it on average: crashes, placeholder content, incomplete information, and broken demo accounts.

How do I fix a guideline 4.2 Minimum Functionality rejection?

Give the app one or two native features its core use case needs (push notifications, camera, offline mode, widgets, HealthKit, biometrics), make sure a reviewer can see them quickly with the demo account, and explain where to find them in the review notes. Don’t submit a website in a frame.

How do I pass guideline 4.3 Spam (or 4.3(a) Design - Spam)?

Show a concrete, verifiable difference from apps already on the store: a specific audience, workflow, or constraint. Put it in the first two lines of your App Store description and in the review notes, and remove leftover template or boilerplate screens. Don’t reuse the same app shell across several apps, and don’t submit several similar apps to review at the same time. Then reply to App Review with specifics.

Can I appeal an App Store rejection?

Yes. You can reply to App Review in App Store Connect or submit an appeal to the App Review Board. Answer the exact guideline cited with facts, not adjectives.

Can a web wrapper app get on the App Store?

A plain wrapper around your website usually gets rejected under 4.2. An app built with Capacitor that bundles its web code locally and uses real native features is a different thing, and it can pass when it is useful and clearly distinct.

Are live updates allowed by Apple?

Yes, within limits. DPLA 3.3.1(B) allows downloaded interpreted code (JS, HTML, CSS) as long as it doesn’t change the app’s primary purpose, bypass OS security, or create a storefront for other apps. Don’t use live updates to change pricing or offers, to add native code, or to do anything deceptive.

Summary

• Shrink the audit surface. Launch with the smallest app that is clearly useful.
• Pick one or two native features that the core use case needs and a reviewer can see in a minute.
• Show your edge in the first two lines of the App Store description and in the review notes.
• Never ship several apps from one shell, or submit them in a batch. That is the fastest way to a 4.3 Spam flag.
• Run the checklist before every submission. Each skipped item can cost you another full wait.
• After approval, keep native releases rare and deliberate, and ship web-layer fixes through compliant live updates.

If you’re building with Capacitor and want to stop waiting on review for every small fix, try Capgo. Set up live updates once, and keep your App Store submissions for real native changes.