Some do, and for predictable reasons. Google Play doesn’t ban WebView. It rejects apps that are only a copy of a website, apps that wrap a site without the owner’s permission, apps that exist to push traffic somewhere, and apps that don’t work when a reviewer opens them. A WebView app that does a real job on the phone can pass.
What Google actually says about WebView apps
In an October 2020 post on common policy violations, it wrote that it sees “a large volume of app submissions that are just webviews of existing websites.” Most of those, it said, are submitted “with a primary purpose of driving traffic rather than providing engaging app experiences to Android users.” Its verdict: “Such apps are considered webview spam, and are removed from Play.”
Its fix: work out what users can do, or do better, in the app than on the web, and build that.
The four ways a WebView app gets rejected
1. It wraps a site you don’t own
The spam policy has a section called Webviews and Affiliate Spam. It bans apps whose primary purpose is to “provide a webview of a website without permission from the website owner or administrator.” Wrap a news site, a store or a government portal you don’t run and you will be rejected.
2. It mostly drives traffic
The same section bans apps whose main purpose is to drive affiliate or referral traffic to a website. A shell around a coupon page, a deals blog or a link list is exactly this.
3. It doesn’t do enough
This is the one most honest site owners hit. The functionality policy says: “We do not allow apps that only have limited functionality and content.” Its examples include apps that are “static without app-specific functionalities, for example, text only or PDF file apps.”
A five-page restaurant site in a WebView, with no menu bar, no offline content and nothing a browser tab can’t show, fits. So does an app that opens a single landing page with a “Download” button.
4. It breaks during review
The same policy page bans apps that “crash, force close, freeze, or otherwise function abnormally,” including apps that “install, but don’t load.” For WebView apps the cause is usually dull: the site was down during review, the wrapper loads an http:// address, or JavaScript was never switched on. Android’s WebView guide notes that JavaScript is disabled in a WebView by default, which gives you a blank screen on most modern sites.
Sign-in is the other common break. Google blocked its OAuth sign-in in embedded webviews starting on September 30, 2021. A reviewer who taps “Sign in with Google” inside your app sees a disallowed_useragent error. Android’s guide to web content in apps says that for third-party sign-in, “Custom Tabs are the way to go.”
How to give a WebView app a better chance
None of this guarantees approval.
- Wrap only what you own, and say so in the listing.
- Add app-shaped navigation. A bottom tab bar or a drawer that jumps to the three or four pages people use most.
- Put something on the device. An offline help page, a price list or opening hours that load without a connection give the app a reason to be installed.
- Fix the review path. Check that every page loads over HTTPS, that sign-in works inside the app, and that file uploads and outside links do something sensible.
- Give reviewers a way in. If the useful part sits behind a login, provide working test credentials in Play Console.
If your site is already a solid PWA, use a Trusted Web Activity instead. It runs your site in the user’s own browser (Chrome on Android version 72 and above), so Google sign-in and saved passwords behave as they do on the web. I compared it with WebView builders in how to turn a website into an APK without coding.
What happens after a rejection
Google’s enforcement page says a rejected app or update simply isn’t made available, a rejected update leaves the previous version live, and rejections don’t affect your developer account’s standing.
Removals and suspensions are more serious. Repeated removals can lead to suspension, suspensions count as strikes, and multiple strikes can end in termination, which removes every app in your catalog. Google emails the decision along with instructions on how to appeal if you think it got it wrong.
Treat the first rejection as a cheap signal. Read the policy named in the email, change the app so it no longer fits that example, and resubmit once. Resubmitting the same wrapper under a new name is how a rejection turns into removals and a strike.
Personal accounts created after November 13, 2023 need a closed test with at least 12 testers opted in for at least 14 days before production, so a rejection late in the process can cost you weeks. The fees and the testing step are covered in can I convert my website to an Android app for free.
Where WebToAPK Free fits
WebToAPK Free builds WebView apps, so everything above applies to it. It gives you drawer or tab navigation and lets you mix Website, HTML and Text sections in one app, up to 20 per project. HTML and text sections work offline, so they can hold the opening hours or price list mentioned above.
It can’t add push notifications. And a generated AAB is not Google Play approval: the permission, listing, testing and policy work is still yours. The Google Play publishing checklist walks through those steps in order.
FAQ
Is using WebView against Google Play policy?
No. WebView is a standard Android component and plenty of approved apps use it. Google’s policies target apps whose main purpose is to show a website without adding anything, apps that drive affiliate traffic, and apps that wrap a site without the owner’s permission.
Why was my WebView app rejected for limited functionality?
Google’s functionality policy says it does not allow apps that only have limited functionality and content. A wrapper that loads one website with no navigation, offline content or app-specific features fits that description, especially if the site itself is thin.
Does a rejection hurt my developer account?
A rejection on its own does not affect your account’s standing, according to Google’s enforcement page. Suspensions are different: they count as strikes, and multiple strikes can lead to account termination.
Why does Google sign-in fail inside my WebView app?
Google blocked its OAuth sign-in in embedded webviews from September 30, 2021, and shows a disallowed_useragent error. Open the sign-in in a Custom Tab instead, or use a Trusted Web Activity for the whole app.
Can I fix the app and resubmit?
Yes. Read the policy named in Google’s email, change the app so it no longer fits that description, and submit a new version. If you think the decision was a mistake, the email includes instructions on how to appeal.
Sources
- Developer tips and guides: Common policy violations, Android Developers Blog
- Spam policy, Play Console Help
- Functionality, Content, and User Experience, Play Console Help
- Policy enforcement, Play Console Help
- Upcoming security changes to Google’s OAuth 2.0 authorization endpoint in embedded webviews, Google Developers Blog
- Web-based content, Android Developers
- Build web apps in WebView, Android Developers
- Trusted Web Activity, Chrome for Developers
- App testing requirements for new personal developer accounts, Play Console Help