Web wrappers: when a WebView app is not enough
The technology is not the problem. Duplicating a browser is.
Guideline 4.2 is about what the app provides, and an app that loads your existing mobile site in a container provides navigation the browser already had. That is the clearest case the guideline addresses.
A hybrid app is a different thing. Plenty of successful apps render substantial parts of their interface with web technology and still integrate with the device, work offline, handle notifications and behave natively. React Native is not a wrapper at all — it renders native components — although an app built in React Native that only loads a remote site in a WebView is one.
Five things move a wrapper toward an app, and you generally need more than one:
Offline. Something useful without a connection.
Device capabilities, meaningfully used. Camera, location, biometrics, files, where they change what the app can do rather than being decorative.
System integration. Push notifications, share sheets, widgets, shortcuts, background refresh.
Native navigation and interaction. Real transitions, gestures, state that survives backgrounding. Not a page with a back button.
Something the website does not do at all.
And if the app is an internal company tool, the answer is usually a different distribution route rather than a redesign. Guideline 4.2, minimum functionality.
The question a reviewer is answering
Not "is this a WebView." "Why would someone install this rather than bookmark the site?"
If you cannot answer that in one sentence, the rejection is predictable, and it is worth noticing that the same sentence is what your App Store description needs anyway. An app with no answer is also an app with nothing to say about itself, which is a marketing problem long before it is a review problem. Guideline 4.3, spam.
What tends to work
Offline first. Content cached, actions queued, sync on reconnect. The single most convincing addition, because it is the thing a browser tab plainly cannot do.
Notifications that matter. Not marketing pushes. State changes the user actually wants to know about.
A capture flow. Camera, scanning, photo attachment, anything using the device rather than describing it.
Widgets, shortcuts, share extensions. Small, cheap, and they demonstrate the app is part of the system.
Native shell, web content. Native navigation, native chrome, and web rendering for the parts that genuinely benefit. This is what most successful hybrid apps actually are.
What does not work
A splash screen and a WebView.
"Push notifications" as the only addition, when the site could send web pushes.
A pull-to-refresh gesture.
Hiding the URL bar.
Reskinning the same site for several brands, which pulls in 4.3 as well and is the version most likely to end in an account-level conversation rather than a rejection. Guideline 4.1, copycats.
The internal-tool case
A company's internal web tool submitted to the public App Store is a common version of this, and it is a distribution problem rather than a product one.
Apple provides routes for enterprise and custom distribution. Choosing the right one resolves the review question entirely, and it usually also resolves the awkwardness of having a login wall as your first screen, which is its own 2.1 risk when a reviewer has no credentials. When a reviewer cannot test your app.
The self-check
# how much of the app is a remote page
grep -rniE 'WebView|react-native-webview|SFSafariViewController|uri:\s*["\x27]https?://' \
src app --include=*.tsx --include=*.ts | head -20
# what native capability is actually used
npx expo config --type public 2>/dev/null | grep -E 'UsageDescription|plugins'
grep -rniE 'notifications|camera|location|share|widget|background' package.json | headIf the first command returns your whole app and the second returns nothing, you have your answer before Apple gives it to you.
Then write the sentence: why install this rather than bookmark the site. If it is honest and specific, put it in the review notes and in the description. If it is not, the work is in the app rather than in the submission. Review notes that work. · After a rejection.
shipcheck reports how much of your UI is remote web content and which native capabilities the project actually declares and uses, so the question is answered from the code rather than from intent. What it checks.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
Can you submit a WebView app to the App Store?
Using web technology is not itself a problem, and an app that offers nothing beyond what a browser already provides is what Guideline 4.2 addresses. The distinction is whether the app does something a website cannot, not which technology rendered the screen.
Why do web wrapper apps get rejected?
Because the app duplicates the mobile website with no added value. Apple's minimum functionality requirement is about what the app provides, and a container around an existing site provides navigation the browser already had.
Is a hybrid app the same thing?
No. Plenty of successful apps render substantial parts of their interface with web technology and still integrate with the device, work offline, handle notifications and behave natively. That is a hybrid app, and it is not what this guideline targets.
What makes a WebView app acceptable?
Doing things a browser cannot: working offline, using device capabilities meaningfully, integrating with system features like notifications, share sheets and widgets, and providing a native navigation experience rather than a rendered page with a back button.
Does React Native count as a web wrapper?
No. React Native renders native components rather than a web page, and the guideline is about apps whose content is a website loaded in a container. An app can be built in React Native and still be a wrapper if all it does is load a remote site in a WebView.
What about apps for internal company use?
Distribution channels exist for enterprise and internal use, and submitting a company's internal web tool to the public App Store is the version that gets rejected. Choosing the right distribution route resolves most of these cases.
shipcheck. “Web wrappers: when a WebView app is not enough.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/rejections/web-wrappers-and-webview-apps/