A question we hear in early calls: "the website already works on phones, so can we just wrap it in an app and put it on the App Store?" It sounds like the cheap version of an app. Apple has a written answer, and it is one sentence in guideline 4.2: your app should "elevate it beyond a repackaged website."
The rule keeps going. "If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store." Songs and movies go to the iTunes Store, books and game guides go to Apple Books, and everything else has to clear a bar the guideline calls "lasting entertainment value or adequate utility." The section these rules live under says it plainly: these are "minimum standards for approval," not targets.
The rules around 4.2 close the obvious workarounds
Apple did not leave the repackaged-website test alone. Three neighboring rules cover the paths people usually take around it:
- 4.2.2 bans the thin version by name. "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." Web clippings and collections of links are exactly what a wrapped site is made of.
- 4.2.6 covers the app-builder shortcut. Apps made from "a commercialized template or app generation service" are rejected unless the app's content owner submits it directly. The template company cannot submit it for you, and Apple's suggested alternative is a single "picker" app that hosts all client content in one binary. If a vendor is offering to publish your app under their account, this rule is why that is a bad deal.
- 4.2.7(e) bans thin clients. "Thin clients for cloud-based apps are not appropriate for the App Store." That is the sentence for apps that mirror a service running elsewhere.
Then there is 4.3, the spam rule. An app "indistinguishable from what's already widely available" can be rejected outright, and repeat submissions of what Apple calls "mediocre, low-quality, or low-effort" apps "may lead to removal from the Apple Developer Program," not just a rejected build.
Apple's own App Review page states the wrapper case in the plainest terms anywhere in its docs: "Websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app."
Web technology is not the problem
Here is the part that surprises people: Apple does not ban web tech in apps. It bans web content with nothing added.
Guideline 4.7 explicitly allows "HTML5 and JavaScript mini apps and mini games" inside a native host app, and Apple says the App Store has supported mini apps since 2017: "self-contained experiences built with web technologies offered within a native host app," now with a dedicated Mini Apps Partner Program. Plenty of shipped apps render parts of their UI in a web view. Review does not inspect your tech stack; it inspects what your app does.
Apple even ships the honest alternative itself. Safari on iPhone can open any website as a web app: full screen, its own icon on the Home Screen, its own entry in the app switcher, and push notifications since iOS 16.4. If the experience you want is "our site, on the Home Screen, with notifications," you may not need the App Store at all, and Apple's own guide walks users through it in a few taps.
Where the line actually sits
Our position, from shipping and maintaining apps on the store: the question reviewers are answering is not "is there a web view in here" but "does this earn its place next to apps that use the device." An app passes 4.2 when it does something the website on its own cannot:
- Uses the device. Camera, location, bluetooth, biometrics, Sign in with Apple, widgets, share extensions. The App Review page asks apps to "make the most of the features unique to iOS."
- Works offline in a real way. Cached data you can still read and act on, not a blank spinner with a retry button. Guideline 4.2.3 requires the app to work on its own, and to disclose any download it needs on first launch.
- Feels built for the screen. Native navigation, not a desktop layout squeezed into a web view. "Web content that is not formatted for iOS" is cited as a rejection reason verbatim.
- Adds a function. The site reads; the app does. Scanning, tracking, notifying, syncing, calculating. If the entire feature list reads "view our website faster," that is the repackaged-website answer.
One honest caveat: this is a judgment call, not a checkbox. There is no Apple-published percentage for how many rejections cite 4.2, though Apple does say that over 40% of unresolved review issues trace to guideline 2.1, which is about crashes and incomplete builds. The 4.2 rejections we watch happen land on apps that were a site in a shell, and they land at submission, after the build work is done.
The takeaway
Before paying anyone to wrap a website, run this list:
If the app fails the first four lines, the money is better spent making the website a good web app than buying a rejection letter. If it clears them, you have a real app, and the wrapper question never comes up. This is the same call we make on every custom software engagement, and the standard apps like CashTaq ship under. If you want a read on whether your idea clears 4.2 before you build it, send us the site.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
