WebView Apps: Will Apple and Google Reject a Repackaged Website?
Updated October 2026 by the Cliffex team.
You can wrap your website in a WebView and submit it to the app stores, but a plain wrapper is likely to be rejected by Apple under App Store Review Guideline 4.2 (Minimum Functionality) and can fall foul of Google Play’s functionality and spam policies. To pass review, the app has to do something useful that your mobile website does not, such as push notifications, offline access or device features. If you only want your site on a home screen, a progressive web app (PWA) is often the cheaper and safer route.
This guide quotes what the current Apple and Google rules say, explains what reviewers reject, lists what to add if you still want a WebView-based app, and compares the alternatives.
What Apple’s guideline 4.2 says about repackaged websites
Section 4.2 of the App Store Review Guidelines (last updated June 8, 2026, when we checked) opens with: “Your app should include features, content, and UI that elevate it beyond a repackaged website.” It goes on to say that an app that is not particularly useful, unique or “app-like” does not belong on the App Store, and that an app without lasting entertainment value or adequate utility may not be accepted.
Two related rules matter for website wrappers:
- 4.2.2: other than catalogs, apps should not be primarily marketing materials, advertisements, web clippings, content aggregators or a collection of links.
- 4.2.6: apps created from a commercial template or app generation service will be rejected unless the provider of the app’s content submits them. This catches many “turn your website into an app” builder services.
Apple does not ban WebViews as a technology. Plenty of approved apps render some screens in a WebView. The problem is an app whose whole experience is the same website a user could open in Safari.
What Google Play’s policies say about WebView apps
Google’s rules are worded differently. Its Spam policy has a “Webviews and Affiliate Spam” section that says Google does not allow apps “whose primary purpose is to drive affiliate traffic to a website or provide a webview of a website without permission from the website owner or administrator.” If you own the website, that clause is less of a risk.
The bigger hurdle is Google’s Functionality, Content, and User Experience policy. It says apps that “do not have the basic degree of adequate utility as mobile apps” or lack engaging content are not allowed, and it lists static apps without app-specific functionality as a common violation. A thin wrapper around a brochure site fits that description.
Apps in the Designed for Families program face an extra line in the Families policy: an app “must not merely provide a webview of a website or have a primary purpose of driving affiliate traffic to a website without permission from the website owner or administrator.”
What reviewers typically reject
From the wording of both stores’ rules, these are the patterns most likely to trigger a minimum functionality rejection:
- The app loads your homepage and nothing else. Every tap opens another web page.
- Browser-style navigation: website menus, cookie banners and “download our app” prompts inside the app itself.
- No offline behavior. With the network off, the user sees a blank screen or a browser error.
- Content that is mainly marketing, links or articles with no interaction.
- An app produced by a generic website-to-app converter and submitted under the converter’s account.
- Broken flows inside the WebView, such as login pages that open in an external browser or payment pages that fail.
What to add so a WebView-based app can pass review
Neither store publishes a checklist for passing 4.2. In practice, the test is whether the app gives users a reason to install it. Features that usually make that case:
- Push notifications for things users care about: order updates, booking reminders, new messages.
- Offline support: cached content, saved items or a usable offline screen, with data syncing when the connection returns.
- Native navigation: a native tab bar or menu, with web content limited to individual screens.
- Device features: camera and document upload, barcode scanning, location, biometric login with Face ID or fingerprint, contacts or calendar integration.
- Account features: sign in with Apple or Google, saved preferences, a personal dashboard.
- Native screens for the most-used tasks, such as search, cart or checkout, so the app feels fast where it matters.
Frameworks such as Capacitor let a web app call native APIs for push, camera and storage, which is a common middle path. When you submit, use the App Review notes to explain which features are app-only, and give reviewers a demo account so they can reach them.
Your alternatives: PWA, cross-platform and native
Progressive web app (PWA)
A PWA is a website that can be installed on a device, work offline and integrate with the device, as MDN describes it. Users install it from your website, so there is no app review. On iPhone and iPad, web apps added to the Home Screen gained web push notifications in iOS and iPadOS 16.4, according to the WebKit team. On Android, you can also list a PWA in Google Play using a Trusted Web Activity, where Chrome renders your site full screen and the app and website are verified as coming from the same developer. A PWA cannot be published to the App Store as it is; wrapping it for iOS brings you back to guideline 4.2. Read more in our guide to progressive web app development.
Cross-platform apps
Flutter and React Native let one team build iOS and Android apps from a shared codebase, with native UI and full access to device features. They are distributed through the app stores and reviewed like any app, but they are built as apps from the start, so minimum functionality is rarely the issue. Xamarin, mentioned in older guides, is no longer an option: Microsoft ended Xamarin support on May 1, 2024 and points developers to .NET MAUI.
Native apps
Native apps are built separately in Swift for iOS and Kotlin for Android. They give the most direct access to new platform features and the finest control over performance, at the cost of two codebases. Our native vs hybrid comparison covers the trade-offs in detail.
| Option | App Store (iOS) | Google Play | Review risk | Best for |
|---|---|---|---|---|
| Plain WebView wrapper | Yes, subject to review | Yes, subject to review | High (Apple 4.2, Play functionality policy) | Rarely the right choice |
| WebView app with native features | Yes | Yes | Medium, depends on the features added | Content-heavy sites that need push, offline or device features |
| PWA | No (installed from Safari) | Yes, via Trusted Web Activity | None on the web; normal review on Play | Testing demand, content and commerce sites |
| Cross-platform (Flutter, React Native) | Yes | Yes | Low for minimum functionality | Most business apps on both platforms |
| Native (Swift, Kotlin) | Yes | Yes | Low for minimum functionality | Performance-heavy apps or deep platform features |
How to decide
- You mainly want an icon on the home screen and better mobile performance: build a PWA first.
- You need store presence and your site already does most of the work: a WebView app is possible if you add push, offline and device features and budget for one or two review rounds.
- Users will open the app weekly or daily for a core task: build a cross-platform app with native screens for that task.
- The app depends on heavy graphics, Bluetooth devices, background processing or the newest OS features: consider native.
Cost and timeline
Turning an existing site into a PWA is scoped case by case, depending on how much offline and push functionality you need; for reference, our website projects range from $1,400 to $4,500+. A store app with genuine native features usually falls into our Starter/MVP tier ($4,000–$10,000, 4–6 weeks) when it reuses an existing backend, or the Business app tier ($10,000–$20,000, 6–12 weeks) when it adds new features, payments or integrations. Every project includes 30 days of post-launch support, then hourly maintenance at $25–$49/hr on an estimate you approve first. Source code and IP ownership transfer to you. See our pricing and the app cost guide.
How Cliffex can help
We help businesses with an existing website decide between a PWA, a cross-platform app in Flutter or React Native, and native Swift and Kotlin apps, then build and submit the app. If a store app is the right answer, we plan the app-only features up front so review is not a gamble. Learn more about our mobile app development services or tell us about your project.
Frequently asked questions
Does Apple reject all WebView apps?
No. Guideline 4.2 targets apps that are no more than a repackaged website. Apps that use WebViews for some screens but offer app-specific features, such as push notifications, offline use or device integration, are approved regularly.
What is App Store guideline 4.2 minimum functionality?
It is the App Store rule requiring apps to include features, content and UI that “elevate it beyond a repackaged website”. Apps that are not useful, unique or app-like, or that are mainly marketing, web clippings or link collections, may be rejected.
Does Google Play allow WebView apps?
Yes, if you own or have permission for the website and the app provides real utility. Google’s spam policy bans WebView apps of sites used without the owner’s permission, and its functionality policy bans apps with limited functionality, so a bare wrapper is still at risk.
Can I put a PWA on the App Store?
Not directly. iPhone users install PWAs from Safari by adding them to the Home Screen. To be listed on the App Store, a PWA has to be wrapped as an app, and it then faces the same 4.2 review. On Android, a PWA can be listed in Google Play through a Trusted Web Activity.
What features help a website-based app get approved?
Push notifications, offline access, native navigation, device features such as camera, scanning, location or biometric login, and native screens for the main tasks. Explain these in your review notes and provide a demo account.