Guideline 4.2: Why Apple Rejects Web Wrappers, and How to Pass
The rejection that catches almost every AI-built app. What Apple means by minimum functionality, what a reviewer looks for, and the native behaviour that turns a wrapper into an app.
August 6, 2026 · 7 min read · By Wanilla Team
Quick answer
Guideline 4.2 rejects apps that are little more than a website in a shell. To pass, the app needs native capability a browser cannot provide — push notifications, biometric sign-in, offline behaviour, native in-app purchases or device hardware — plus a native feel in navigation and layout. Reviewers judge the experience, not the underlying technology, so Capacitor or WebView apps can pass when the native layer is real.
If you package a web app for the App Store without thinking about it, this is the rejection you get:
Guideline 4.2 - Design - Minimum Functionality. We found that the usefulness of your app is limited by the minimal amount of content or features it includes.
What Apple is actually objecting to
Apple does not ban web content — a large share of the App Store renders web views. What it rejects is an app that offers nothing a Safari tab would not. In practice, a reviewer is asking three questions:
- Does this app use the device — notifications, camera, biometrics, offline state, haptics, share sheet?
- Does it feel like an app — native navigation, no browser chrome, no visible page reloads, respectable behaviour on launch and resume?
- Would a user reasonably keep it on their home screen rather than bookmarking the site?
Fail all three and it is a wrapper. Pass them and the fact that your UI is rendered from web technology is irrelevant.
The signals that get a wrapper spotted immediately
- A visible address bar, browser back button, or "Open in Safari" affordance.
- A blank white screen with a spinner on cold launch.
- Links that break out into Safari mid-flow — especially checkout.
- A payment page that is a browser Stripe form. This also breaks guideline 3.1.1.
- No permissions requested at all, ever.
- Desktop layout, hover states, or text that requires pinch-zoom.
What passing looks like
- Real push. APNs registration and a genuine reason to send. This is the single strongest signal of native intent.
- Native purchase. StoreKit 2 with Apple''s purchase sheet, restore purchases and trial handling.
- A native shell. Splash screen, no browser chrome, proper safe-area handling, pull-to-refresh only where you want it, swipe-back that works.
- Offline behaviour. An honest offline state rather than a browser error page.
- At least one device capability your product genuinely uses — Face ID, camera, photo library, haptics, share sheet.
- Enough product. A single-screen app with one form is thin regardless of how it is built.
If you have already been rejected
Do not argue in Resolution Center first. Add the native behaviour, then reply with a short, specific note: what you added, where to find it, and a demo account that works. Reviewers respond well to a concrete diff and badly to a defence of the status quo.
How Wanilla handles it
Every app we launch ships with APNs push, StoreKit 2 purchasing, biometric support and a native shell from day one, so guideline 4.2 is answered by the build rather than by an appeal. That is the main reason a Lovable, Base44 or Replit app gets through review at all.
Related reading: the most common App Store rejection reasons, Capacitor vs React Native and how to fix web-wrapper limitations.
Where to go next
Ready to ship to the App Store?
Book a free Launch Review and we'll map a 24-hour path from your AI build to a live iOS app.
More in Apple Policy
Base44 App Rejected by Apple? How to Fix It and Resubmit
The four rejections that catch almost every Base44 app, what Apple's message actually means, and how to fix each one before resubmitting.
The 10 Reasons Apple Rejects First Submissions
The rejections we see most often on first launches, the guideline behind each one, and the specific fix that clears it.
Apple's 15% Rate: What the Small Business Program Is Actually Worth
The arithmetic on a real subscription price, the timing trap that costs founders money, and how it changes the web-versus-app pricing decision.
