If you publish a website-based app and get rejected, the odds are the email cites Minimum Functionality. It is the most misunderstood policy in the Play Console because the wording is short and the enforcement is judgement-based. This guide separates what the policy says from how it is applied, and gives you the features that reliably satisfy it.
What the policy says
Google's Minimum Functionality policy has two parts that matter here.
Broken functionality and user experience. Apps must provide a stable, responsive experience — no crashes, no force-closes, no features that don't work, no "apps designed to do nothing or have no function". This is the part that catches a 404 link or a blank screen in aeroplane mode.
WebViews and affiliate spam. Google says it doesn't allow apps whose primary purpose is to drive affiliate traffic to a website, or that provide a WebView of a website without permission from the website's owner. Read that carefully: wrapping your own website is not what this clause prohibits. It targets people packaging sites they don't control.
So why do owners of their own sites get rejected under it? Because reviewers apply the spirit of the whole policy: an app that adds nothing to the website — no capability a browser bookmark lacks — is judged as not providing a basic degree of functionality. The rejection template often reads: "your app provides little to no functionality beyond a WebView of a website". Permission is necessary but not sufficient.
What reviewers actually test
From rejection patterns and Google's own guidance, a reviewer with a website app in front of them does roughly this:
- Opens it. Does anything happen besides a web page loading? Is there a splash, a menu, any native element?
- Turns the network off and reopens. A raw WebView error page ("net::ERR_INTERNET_DISCONNECTED") is a broken-functionality finding.
- Taps every visible link and button, including footer links. Any 404, any "coming soon", any dead button counts.
- Compares the listing to the app: do the screenshots show this app (no browser bar)? Does the description promise notifications the app doesn't request?
- Checks whether the app asks for permissions it can't justify.
- Asks the question the policy is about: why does this exist as an app?
Features that answer the question
These are the additions that convert wrappers into approved apps, in rough order of weight:
- Push notifications. A browser bookmark cannot notify anyone. Enable OneSignal in the builder, request permission properly (Android 13+ prompt), and mention notifications in the description — then actually send some.
- Offline handling. A branded offline screen with retry, and cached pages where possible. Reviewers test this explicitly.
- Native navigation. A menu or bottom navigation to the main sections, pull-to-refresh, exit confirmation, a proper back stack. Small, visible, native.
- An About screen with real contact details and the privacy policy link.
- Purpose in the listing. "Order ahead and get notified when it's ready" tells the reviewer what the app is for. "Our website as an app" tells them it isn't.
- A site that has a reason to be reopened: a shop, a schedule, a publication, a portal. This is not a feature you can toggle, and it is the honest limit of the approach.
Cases where the honest answer is "don't list"
- A static brochure or landing page with no recurring use. No amount of native chrome makes it an app; reviewers see through it, and users wouldn't keep it anyway.
- A site you don't own. The WebView clause prohibits it outright, and impersonation policies stack on top. Get written permission and publish under the owner's account, or don't.
- A site whose value is affiliate links. Explicitly named in the policy.
For these, a home-screen web app installed from the site itself needs no review and does the job; the comparison lays it out.
Decoding the rejection email
| Wording | What they found | Fix |
|---|---|---|
| "…provides little to no functionality beyond a WebView…" | No app-only features detected | Push, offline, navigation, About; resubmit with a description that names them |
| "…does not provide a basic degree of functionality… broken…" | A link, form or media element failed, or offline showed an error | Fix the site; add the offline screen; test every link |
| "…WebView of a website without permission…" | Developer name/brand doesn't match the site | Prove ownership: matching developer details, contact email at the domain, a note in review notes pointing to the site's About/contact page |
| "…designed to do nothing…" | App opened to a blank or placeholder page | Check the start URL loads without login; supply credentials in App access if login is required |
Resubmitting
Fix, rebuild, upload a new version code, and use the review notes field (App content → App access / Notes) to state plainly what changed: "Added push notifications for order updates, offline mode, native navigation; developer is the site owner (see /about)". Reviewers read those notes. Appeals through the policy status page are for cases where you believe the decision was wrong; a rejection you agree with is simply fixed and resubmitted.