The most common way a website-to-app project dies is not a technical failure. It is a rejection email from App Review citing Guideline 4.2, Minimum Functionality — usually after the build worked perfectly and the client has already been told a date.
The rule is written down, it is not a reviewer's mood, and it is avoidable. Here is what it says and what actually gets apps through.
What the rule says
Apple's App Review Guidelines, section 4.2, requires that an app provide enough functionality and lasting value to justify its place in the store. The guideline is explicit that an app which is simply a repackaged website does not qualify, and the same section rules out apps that are little more than a marketing brochure or a link to a web page.
The reasoning is commercial rather than technical. Apple does not want a store full of entries that duplicate what Safari already does, because that makes the store worse for everyone browsing it.
What this does not mean
It does not mean WebView apps are banned. Plenty of apps from large companies are mostly web content in a native shell, and they pass review every release. The test is not how the screen is rendered — it is whether the app does something the website alone cannot.
Google Play is more permissive here, but it has its own policy against low-value and duplicate content, so a bare wrapper is a risk on both stores. Play just tends to let it through first and remove it later, which is worse.
What gets an app through
In practice, reviewers are looking for native capability the browser does not provide. The more of these the app genuinely has, the less argument there is:
- Push notifications. The strongest single signal, because it is the clearest thing a website cannot do while closed. Set them up and actually use them — an empty push system that has never sent anything is not persuasive.
- Native navigation. A bottom tab bar, a native top bar, a working back gesture. If the app looks like a browser with the chrome hidden, it reads as a repackaged website because that is what it is.
- Offline behaviour. At minimum, a designed screen when the network drops rather than a blank white page or a browser error.
- Device features. Biometric unlock, camera, photo library, the share sheet, location when it is genuinely used.
- An interface adapted for the app. Hiding the site's own header, footer, cookie banner and newsletter popup matters more than it sounds: those are the elements that make a reviewer see a web page.
What gets apps rejected
- The app is one screen pointing at a URL, with nothing else
- The site's own navigation bar is visible inside the app, duplicating the native one
- A cookie consent banner appears on launch — an instant tell
- Links open Safari instead of staying in the app
- The app is a catalogue or brochure with no interaction
- Login is required before the reviewer can see anything, and no demo account was provided
That last one deserves emphasis. If your app needs an account, give App Review working credentials in the review notes. Rejections for "we could not get past the login screen" are common and entirely self-inflicted.
If you are rejected anyway
A 4.2 rejection is not the end. You can reply in App Store Connect, and a reasoned response works more often than people expect. Explain what the app does that the site does not, point at specific features, and say who uses it and why they need it on a phone.
What does not work: resubmitting the same binary, arguing that other apps do the same thing, or rewriting the store description. Review is about the app.
Add the missing capability, say what you added, and resubmit. Most wrapper apps that pass do so on the second attempt, having added push notifications and native navigation.
Build with this in mind, not after
The practical lesson is to treat the native layer as part of the product rather than packaging. An app that hides the site's own chrome, adds tabs and sends useful notifications is a better product and passes review. An app that is a URL in a box fails on both counts.
For what is actually inside these apps and where the technology runs out, see WebView vs native.