Google Play rejected it because, to the reviewer, the app looked like it did too little or didn’t work. Its policy bans “apps that only have limited functionality and content” and apps that crash, freeze or don’t load. A WebView app that shows one website with nothing extra, or that showed a blank or broken page during review, fits one of those two descriptions.
What the policy actually says
The rule lives on Google’s Functionality, Content, and User Experience policy page. Two parts of it matter here.
The first is limited functionality and content. Google’s examples:
- “Apps that are static without app-specific functionalities, for example, text only or PDF file apps”
- “Apps with very little content and that do not provide an engaging user experience”
- “Apps that are designed to do nothing or have no function”
The second is broken functionality: “We don’t allow apps that crash, force close, freeze, or otherwise function abnormally.” The examples are apps that don’t install, apps that install but don’t load, and apps that load but aren’t responsive.
The page never mentions WebView. What gets you rejected is what the reviewer sees when they open the app.
Why WebView apps hit this rule so often
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,” mostly made “with a primary purpose of driving traffic rather than providing engaging app experiences.” Those, it said, “are considered webview spam, and are removed from Play.”
So the reviewer opens your app wanting to know what it does that the website doesn’t. If the answer is “the same page with a different icon,” the limited functionality rule is the easiest one to cite.
The same post names a second route. Abandoned apps with broken features “will also be flagged as violating the minimum functionality policy.” That covers WebView apps whose website moved, went down or started showing errors.
The usual causes, in the order I’d check them
The reviewer couldn’t get past a login
It’s the cheapest fix. Your app opens on a sign-in screen, the reviewer has no account, and all they can judge is a form. Play Console’s App access section exists for this. Google’s requirements for sign-in details say they must be “accessible at all times, reusable, and valid regardless of user location.” If you use two-step verification or one-time codes, give credentials that bypass them. And Google warns: “If the provided password expires, we may not be able to review your app and, therefore, the app may be rejected.”
The site was blank, slow or broken in the WebView
A page that works in Chrome can still fail inside an app. Pop-ups, file downloads, third-party sign-in and external links often behave differently. If the reviewer tapped “Download invoice” and nothing happened, the app looked broken. I covered the common breakages in how to turn a website into an APK without coding.
The app is one page
A landing page, brochure site or link-in-bio page in a frame is the textbook case of “very little content.”
It’s not your website
If you wrapped a site you don’t run, expect a rejection under a different policy. Google’s spam policy bans apps that “provide a webview of a website without permission from the website owner or administrator.” Its own example is “Ted’s Shopping Deals,” an app that “simply provides a webview of Google Shopping.” No amount of extra features fixes that one.
How to fix it before you resubmit
Google’s advice in the 2020 post is a good test: think about “what users can do or do better with the app than in a web experience,” then build that. For a WebView app, that usually means some mix of these:
- Give reviewers a working way in. Fill in App access with a test account that never expires, and write one line on where to tap first.
- Test the app as a stranger would. Install the release build on a phone you haven’t logged in on. Turn on airplane mode and open it. Tap every menu item. Anything that shows a blank screen, a raw error page or a Chrome sign-in prompt needs fixing.
- Add structure the website doesn’t have. App-style navigation (a drawer or tabs) to your most-used pages makes it feel like an app rather than a bookmark.
- Add something that works offline. A help page, a price list, a menu, a timetable or a how-to guide bundled into the app works without a connection. That gives the reviewer something real even when your server is slow.
- Make the app about one job. A restaurant app that opens on the menu with a call button beats one that opens on the homepage slider.
A concrete example: a local gym wraps its whole website, and the app opens on a marketing homepage. A stronger version opens on the class timetable, has tabs for “Book a class,” “Opening hours” (bundled, works offline) and “Contact,” and gives the reviewer a test member login.
When you’ve changed the app, raise the version code, build a new AAB and submit it. If you’re starting from the general rules, read do WebView apps get rejected by Google Play first.
Rejected or removed: what changes
Check Play Console under Policy status in the left menu of your app. Google’s policy status page says that “if your app was rejected, the last version that you successfully published is still available on Google Play.” So a rejected update doesn’t pull your live app.
It also says: “Until a policy violation has been fixed, don’t republish a rejected or removed app.” Sending the same build back and hoping for a different reviewer wastes time and adds to your history. If you truly think the reviewer got it wrong, Google’s help center has a page on policy-review outcomes with information on filing appeals.
Where WebToAPK Free fits, and where it doesn’t
WebToAPK Free builds WebView apps, so the same rules apply to anything you make with it. What it gives you toward the fixes above: up to 20 Website, Text or HTML sections per project, drawer or tab navigation, and self-contained HTML and text sections that work offline. That’s enough to turn a one-page wrapper into an app with a few real screens. The guide to publishing a WebView app on Google Play walks through the store side.
The limitation is real, though. It doesn’t add push notifications, and an AAB from any builder is not Google Play approval. If your app’s only content is a thin website, no builder can make that pass. You have to add the value yourself.
My take
I’d treat a minimum functionality rejection as a fair question rather than a bug in Google’s review. If you can’t name one thing your app does better than the website in a browser, a reviewer can’t either. Fix the login and broken pages first, since those are cheap, then add one offline section that people would actually open. If you’re still deciding whether an app is worth it at all, converting a website to an Android app for free covers the cheaper routes.
FAQ
Does Google Play ban WebView apps?
No. The functionality policy doesn’t mention WebView at all. It bans apps with limited functionality and content, and apps that crash or don’t load. A WebView app gets caught when it is only a copy of a website or when it breaks during review.
What counts as limited functionality on Google Play?
Google’s examples are static apps without app-specific features (text-only or PDF apps), apps with very little content, and apps that do nothing. A single-page website in a frame often looks like the first case to a reviewer.
Can a broken website cause a minimum functionality rejection?
Yes. The same policy page covers broken functionality: apps that don’t install, don’t load or aren’t responsive. If your site was down, slow or blocked behind a login during review, the app looked broken.
Is my live app removed when an update is rejected?
No. Google says that if your app was rejected, the last version you successfully published is still available on Google Play. Only the rejected update is held back.
Should I just resubmit the same build?
Google advises not to republish a rejected app until the policy violation has been fixed. Change the app first, then submit a new version. If you believe the decision was wrong, Google’s help center explains how to appeal.