Vibe Coding
Wrapping a web app for iOS: what Apple actually requires beyond the WebView
Capacitor, Cordova, and similar tools can get a React or Next.js app running inside a native iOS shell in an afternoon. Getting that shell approved is a different task — Apple checks for what's outside the WebView, not just what's inside it.
The rule reviewers actually apply
Guideline 4.2 doesn't ban WebView-based apps outright, but it does reject apps that are "not appropriately adapted" for iOS — in practice, a wrapped website with no native functionality, offline behavior, or platform integration reads exactly like a bookmark, not an app.
The test that matters: if the same content works identically in Safari with no meaningful loss of functionality, App Review has no reason to treat the wrapped version as a distinct product.
What separates an approved wrapper from a rejected one
Native push notifications tied to real, user-relevant events — not just a generic "enable notifications" prompt with nothing behind it.
Real offline behavior: cached content or a genuine offline mode, not a blank screen or a loading spinner when the connection drops.
At least one native platform feature that a browser tab can't offer — a home screen widget, Face ID-gated content, share extension, or background sync.
No visible browser chrome: address bars, external-link behavior that pops Safari unexpectedly, or unstyled web scrolling that breaks the native feel.
The parts of App Review that don't care about your architecture
Privacy, account deletion, and permission strings apply the same way to a wrapped app as to a fully native one — the WebView doesn't exempt you from a PrivacyInfo.xcprivacy manifest or an in-app account deletion flow if the app supports account creation.
If the web app calls a backend that collects analytics or personal data, that has to be declared accurately in the App Privacy questionnaire regardless of where the code physically runs.
If you've already been rejected for this
Read the specific wording — a 4.2 rejection citing "minimal functionality" or comparing the app to a website is a strong signal that native additions, not cosmetic changes, are what's needed.
Resubmitting the same wrapper with a new icon or renamed screens without adding real native functionality is very unlikely to pass a second time.
Next step
Find out what your wrapped app is missing before you resubmit
Sign in to AcceptMyApp and run an AI pre-submission check that flags exactly this pattern — thin WebView wrappers with no native functionality added.
Get startedRelated resources
Guideline 4.2
App Store Rejected for Minimum Functionality? Here's Why
A Guideline 4.2 minimum functionality rejection means Apple sees your app as too thin, a repackaged website, or template-generated. Here's what actually clears the bar.
Vibe Coding
Turning a Bolt, Lovable, or v0 Prototype Into an App Store Submission
Bolt, Lovable, and v0 are built for fast web prototypes, not App Store binaries. Here's the real path from an AI app-builder project to a submittable iOS app.
Rejection guide
App Store Rejection: Guideline 4.2 Minimum Functionality
Fix a Guideline 4.2 minimum functionality rejection by showing native value, improving screenshots, and writing stronger review notes.