# Wrapping a web app for iOS: what Apple actually requires beyond the WebView

Canonical page: https://acceptmy.app/guides/web-app-to-ios-app-store-requirements

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.

## Apple guideline references

Guideline 4.2


## Related pages
- ["Minimum functionality" rejection: what Apple is really telling you](https://acceptmy.app/guides/app-store-rejected-minimum-functionality.md)
- [From Bolt, Lovable, or v0 to a real App Store submission](https://acceptmy.app/guides/ai-app-builder-to-app-store.md)
- [Minimum functionality rejection: prove the app has enough value](https://acceptmy.app/rejections/guideline-4-2-minimum-functionality.md)

Last updated: 2026-09-09