"Repackaged website" is what most builders assume killed their submission. Usually it isn't. Apple's Resolution Center message names a specific guideline number, and in the large majority of WebView rejections that number points to a missing offline state, an incomplete review package, a payment flow, or a privacy answer — not the WebView itself. Match your rejection to the right guideline below before you change anything.
Six guidelines that actually reject a WebView app.
Each of these shows up repeatedly in public rejection reports for wrapped web apps. Find the guideline number printed in your Resolution Center message, then fix that specific thing instead of rebuilding the whole app.
Guideline 4.2 / 4.2.2 — Minimum Functionality
What triggers it: The app is a single full-screen WebView with no native navigation, no offline handling, and nothing a browser tab doesn't already do. Reviewers commonly test in airplane mode; a blank white screen is the clearest signal of a thin wrapper.
The fix: Add a native offline state, native tab bar or navigation around the WebView content, and at least one OS-level integration — push notifications, biometric unlock, or a share sheet. See PWA to App Store for the full breakdown of what separates an approved wrapper from a rejected one.
Guideline 2.1 — App Completeness
What triggers it: Broken links, placeholder text, crashes, or a reviewer who could not get past login. This is also the guideline cited when the reviewer simply couldn't test the app at all.
The fix: Remove unfinished screens and debug content, fix the exact flow the reviewer describes, and supply working demo credentials or an approved demo mode in your review notes.
Guideline 5.1.1 — Data Collection and Storage
What triggers it: A missing or non-functional privacy policy link, or App Privacy answers in App Store Connect that don't match what the website and its third-party SDKs actually collect.
The fix: Publish a privacy policy URL that works without login, and audit App Privacy answers against the live website, analytics, and payment providers — not just the native shell code.
Guideline 5.1.1(v) — Account Deletion
What triggers it: The app lets a user create an account but offers no way to delete it from inside the app, or only offers deactivation.
The fix: Add an in-app path to account and data deletion. If deletion completes on the web, link directly to that page rather than a generic homepage.
Guideline 3.1.1 — In-App Purchase
What triggers it: Digital content, subscriptions, or app functionality sold through a web checkout instead of Apple's in-app purchase system. This is a common one for web apps that sell subscriptions on the website and simply load the same checkout inside the WebView.
The fix: Route digital goods and subscriptions through Apple's in-app purchase APIs unless a specific exception or storefront entitlement applies. Physical goods and real-world services consumed outside the app usually keep their existing checkout.
Guideline 2.3 — Accurate Metadata
What triggers it: Screenshots, description, or age rating that don't match the build the reviewer is actually testing.
The fix: Recapture screenshots from the exact build under review, and keep the description limited to what that build does today.
Read the rejection message before you guess.
Every rejection in App Store Connect's Resolution Center opens with a guideline number and a short explanation, sometimes with the exact screen or step the reviewer hit. Resubmitting a guessed fix without reading that message is the single most common way to burn a second review cycle on the wrong problem.
- Open the exact guideline cited, not the nearest one you remember from a forum thread.
- Reproduce the reviewer's scenario: same build, same device class, same network state if airplane mode is mentioned.
- Fix the root cause, not just the symptom the reviewer happened to see first.
- Add a review note explaining what changed and why, so the next reviewer doesn't have to rediscover it.
- Resubmit the same version unless the fix requires a new build number.
Most WebView rejections aren't about the WebView. WebNativeApp reviewed its last 50 App Store submissions over 12 months: 85% passed on the first try, and among the rest, incomplete metadata was a more common cause than wrapper detection under Guideline 4.2. Full data in PWA to App Store.
A wrapper built to pass review the first time.
WebNativeApp packages your production URL with the native offline state, navigation, and push notifications that Guideline 4.2 checks for already wired in, so a rejection is more likely to be a metadata fix than a rebuild.
- Paste your production URL: The same live app your reviewer will see.
- Get a submission-ready shell: Native navigation, offline handling, and store-required behavior included by default.
- Fix what's actually flagged: If App Review still returns a note, it points at something specific to resolve — not a wrapper problem to solve from scratch.
WebView app rejection, answered
Does Apple reject every WebView app?
No. Apple reviews the finished experience, not the implementation technique. A WebView-based app with native navigation, an offline state, and real utility can pass review; a bare URL in a full-screen WebView is what actually gets flagged.
What does Guideline 4.2.2 mean in a rejection?
It means the reviewer judged the app too thin: little more than a website with no native functionality layered on top. The fix is adding native navigation, offline handling, and an OS-level integration — not switching away from a WebView entirely.
How do I know which guideline caused my rejection?
Open the message in App Store Connect's Resolution Center. It names a specific guideline number and usually the exact screen or condition that triggered it. Fix that named issue before changing anything else.
Can I appeal an App Store rejection?
Yes. If you believe the guideline was misapplied, App Store Connect includes a way to request a call or submit clarification through the Resolution Center, separate from simply resubmitting a new build.
Do native features guarantee approval?
No. Push notifications, biometric unlock, or a share sheet make Guideline 4.2 easier to clear, but they don't override an incomplete review package, a missing privacy policy, or a payment flow that bypasses in-app purchase.
How long does resubmission review take?
Apple reports that most submissions are reviewed in under 24 hours as of 2026. A resubmission after rejection generally goes through the same review queue, not an expedited one, unless you request an expedited review separately.