Most brands that want an app already have the hardest part built: a website that works well on a phone. Turning it into an app is the fastest way into the App Store, and Apple approves apps built this way all the time.
But Apple also turns away apps that are just a website in a frame. Its Guideline 4.2 says an app has to be more than “a repackaged website,” and it’s the rule that trips up most webview apps.
At MobiLoud, we’ve worked on over 2,000 app launches, so what the App Store will approve or reject is second nature to us by now.
This guide explains what Apple’s App Store Review Guidelines say about webview and wrapper apps, why reviewers reject them and what an app built from your website needs to pass App Store review in 2026.
Does Apple Allow Webview Apps?
Apple allows webview apps on the App Store. Its guidelines don’t ban apps built with web content, only apps that give people nothing more than the website already does.
A webview is a browser engine running inside an app, showing web pages without the browser’s address bar and buttons. Apps use them all the time, for things like checkouts, help pages and account screens.
When most of an app’s screens come from a website, people call it a webview app, a web-based app or a wrapper.
Apple’s guidelines even say which engine to use. Guideline 2.5.6 requires apps that browse the web to use Apple’s WebKit framework, the engine behind Safari, unless the app has an entitlement to use another engine in the EU or Japan.
So App Review doesn’t ask how your app is built. It asks whether the app gives people something they couldn’t get by opening your website in Safari.
What Does App Store Guideline 4.2 Say?
Guideline 4.2, Minimum Functionality, is the part of Apple’s guidelines that speaks directly to apps built from websites. It opens like this:
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store.
Apple’s advice to developers is even more direct. Its App Review page says “websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app.”
Apps that fall short get a rejection citing “Guideline 4.2 - Design - Minimum Functionality,” which usually says the app isn’t sufficiently different from browsing the web on a phone.
Two parts of Guideline 4.2 matter most for webview apps. Guideline 4.2.2 says that, “other than catalogs, apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.”
The exception for catalogs is what’s most important for retailers. An app built around your products is fine, while an app that’s little more than a saved web page, a list of links or an advert for your website isn’t.
Guideline 4.2.6 covers apps made with templates or app generation services. Apple rejects them “unless they are submitted directly by the provider of the app’s content.”
For a brand, that means the app has to be published in your own Apple Developer account, not the account of the agency, builder or service that made it. That also keeps the app and its App Store listing yours.
Which Other App Store Guidelines Apply to Webview Apps?
Guideline 4.2 isn’t the only rule that catches apps built from websites. These apply on top of the requirements every app has to meet, like developer accounts, privacy details and build tools.
| Guideline | What it asks of a webview app |
|---|---|
| 2.1 App Completeness | A finished app, with every link working, no placeholder content and a demo account for anything behind a login |
| 2.3.3 Screenshots | Screenshots of the app in use, not of your website or a splash screen |
| 2.5.6 WebKit | Web content shown with Apple's WebKit framework, the engine Safari uses |
| 3.1.3(e) Physical goods | Your store's own checkout for physical products, not In-App Purchase |
| 4.3 Spam | One app covering every market, rather than near-identical apps for each location |
| 4.5.4 Push notifications | An app that works without push, plus opt-in and opt-out for marketing messages |
| 4.8 Login services | An option like Sign in with Apple alongside any social login, such as Google or Facebook |
| 5.1.1(v) Account deletion | A way to delete an account from inside the app, if people can create one |
Guideline 2.1 is the most common sticking point of all. Apple says that, on average, over 40% of unresolved review issues relate to App Completeness.
For a webview app, that can be as simple as a broken link, an unfinished page or a login the reviewer can’t get past.
What Does a Webview App Need to Pass App Store Review?
A webview app passes App Store review when it feels like an app from the first tap, not like your website in a frame. In our experience, that comes down to six things.
Native Navigation
Native navigation is the first thing a reviewer notices, and the clearest sign that an app is more than a website.
Most shopping apps use a tab bar along the bottom of the screen for their main sections, such as Home, Search, Saved, Bag and Account. Above the content, a native header shows where you are and takes you back with a tap or a swipe.
Your website’s own header, hamburger menu and footer don’t belong in the app. Two sets of navigation on one screen is a giveaway that the app is a website in a frame.
Screens Designed for the Phone
Apple’s warning about “web content that is not formatted for iOS” is about more than a responsive layout. A screen in an app should look like it was designed for an app.
Start by taking out what only makes sense in a browser:
- Banners and pop-ups asking people to download the app they’re already using
- Links to your desktop site, or to pages that aren’t built for small screens
- Headers, footers and sidebars that repeat the app’s own navigation
Then go further where it counts. Onboarding screens, an account area designed for the app and app-only pages make the app feel like a product of its own, not a copy of your site.
Features a Website Can’t Offer
Features that use the phone itself are the strongest proof that an app does more than a website. Push notifications are the most common, because they reach customers on their lock screen without an email or a text.
Others include Face ID sign-in, barcode scanning, location-based features and the native share sheet. Each one shows a reviewer that the app is built for the device, not just the browser.
Apple doesn’t require any particular feature, and push notifications alone won’t carry an app that otherwise looks like a website. What App Review wants to see is an app that, taken as a whole, is more useful than your site in Safari.
No Dead Ends
An app should never leave people on a browser error page or a blank white screen. Those are the moments when a reviewer is most likely to see the website underneath.
Check that your app has:
- A native screen for when there’s no connection, with a way to try again
- Loading states that look like part of the app, not a browser’s progress bar
- Links to other websites that open in an in-app browser, so people can find their way back
- A way back from every page, with nothing that traps people outside the app’s navigation
Everything the Reviewer Needs
Reviewers can only approve the parts of your app they can reach. Give them a working demo account if your store has logins, and keep your site running normally while the app is in review.
Use the Notes for Review in App Store Connect to explain anything that isn’t obvious, such as features that only appear for signed-in customers or in certain countries. Every app also needs working links to customer support and your privacy policy.
Your Own Developer Account and an Accurate Listing
Publish the app in your own Apple Developer account, as Guideline 4.2.6 requires for apps made by a service. It’s the account Apple holds responsible for the app, so it should belong to your business.
Then make sure the App Store listing matches the app. That means screenshots of the app in use, an accurate description and App Privacy details that cover everything your site and its tools collect.
How Does Google Play Compare?
Google Play is more relaxed than Apple about apps built from websites, but it has rules of its own.
Its Webviews and Affiliate Spam policy bans apps whose main purpose is to “provide a webview of a website without permission from the website owner or administrator.” That’s aimed at apps that wrap someone else’s site, so it isn’t a problem when the website is yours.
Google’s functionality policy is closer to Apple’s Guideline 4.2. It doesn’t allow apps that “only have limited functionality and content,” or apps that crash, freeze or don’t work properly.
Compared with Apple’s review, Google’s leaves more room for a simple app. But an app built to pass Apple’s review will generally pass Google’s too, so it makes sense to design for Apple’s bar from the start.
What Happens If Apple Rejects Your App?
A rejection from App Review isn’t final. Apple tells you which guideline the app didn’t meet, and you can reply, fix the problem and resubmit.
For a Guideline 4.2 rejection, the fix is usually to add what the reviewer felt was missing: native navigation, app-specific screens or features that use the device. When you resubmit, use the Notes for Review to point out what’s changed.
If you think the reviewer misunderstood your app, you can appeal to the App Review Board, with one appeal per rejected submission.
Apple also offers 30-minute Meet with App Review video appointments. They’re ideal for asking how your app lines up with the guidelines before you submit it.
MobiLoud & The App Store Review Process
MobiLoud transforms your website into a custom native app, powered by the same code as your site. We work with mid-market and enterprise online brands, and every app we build is designed to meet everything App Review asks for.
We build the app from your existing site, building a custom native experience around it for the phone. That means native navigation, screens redesigned for the app, push notifications, app-only pages and native features where you need them.
Your app launches with everything you’ve already built, then goes where your website can’t. That’s exactly what Guideline 4.2 is looking for, built into the app from the start rather than added to get past review.
Our team also handles the parts of review that trip brands up:
- Building with the tools Apple requires, and keeping the app’s privacy manifest up to date
- Your App Privacy answers, screenshots and App Store listing
- Submission from your own developer account, and any questions from reviewers
- Updates as iOS and Apple’s guidelines change
With over 2,000 app launches behind us, we know what reviewers look for. We’ve helped brands like John Varvatos, Jack & Jones and Tadashi Shoji launch their apps this way, and typically in around 2-4 weeks we can get your brand live and published in the app stores, without any worries or roadblocks to contend with.
Final Thoughts
Guideline 4.2 isn’t a barrier for apps built from websites. It’s Apple’s way of making sure every app on the App Store earns its place on someone’s home screen.
An app that’s just your website in a frame won’t pass, and it wouldn’t give your customers much reason to keep it either. Design it as an app, with native navigation, screens built for the phone and features that use the device, and you’ve met the bar Guideline 4.2 sets.
Apple revises its guidelines regularly, so check the current version before every submission. Get the basics right too, from a working demo login to in-app account deletion, and your app is ready for review.
