Google Play Rejected Your WebView App? Here's Why, and How to Fix It

Google Play accepts thousands of apps that load a website inside a native shell. News apps, store apps, booking apps and SaaS dashboards do it every day. But Google also rejects a lot of them, and the rejection email rarely tells you exactly what to change. This guide covers the reasons apps built from websites get rejected, what each policy actually means, and the specific fixes that get them approved.

Google Play doesn't reject WebView apps for being WebView apps. It rejects apps that give users nothing a browser tab doesn't.

First: find the exact policy

Before changing anything, open Play Console and go to Policy and programs, then Policy status. The rejection email is often vague, but Policy status names the exact policy, the app version it applies to, and sometimes a screenshot from the reviewer. A rejected update doesn't take down the version that's already live. Fix the issue named there, increase the version code, and resubmit.

The 7 most common rejection reasons

1. Webview spam

Google's Spam policy specifically names apps that are just a WebView of a website, especially a website you don't own or don't have permission to use. Two things trigger this: wrapping someone else's site (a news site, a popular store, a government portal), and publishing many near-identical apps for different sites from one account. The fix is simple: only publish apps for websites you own or are authorised to represent, and be ready to prove it if Google asks. Agencies should publish client apps under the client's own developer account, or keep written permission on file.

2. Minimum functionality

Google wants apps to offer a stable, engaging, responsive experience. A site that opens with a desktop layout, a hamburger menu and a cookie banner looks like a bookmark, not an app. What helps most:

• A native bottom tab bar with your main sections, instead of relying on the website's menu.
• A branded splash screen and a status bar that matches your colours, so the app doesn't look like a browser.
• Push notifications that bring users back to specific content.
• Hiding website-only elements, like "get our app" banners and huge footers, inside the app with custom CSS.
• A friendly offline screen with a retry button, rather than Android's default error page.
• Features that make sense to keep installed: accounts, saved items, bookings, orders or member content.

Capsule apps include the native splash screen, coloured system bars and offline screen by default, and you can add the tab bar, push notifications, custom CSS and a biometric app lock from the dashboard.

3. Broken functionality

Reviewers install the app and use it. If a page fails to load, a button does nothing, or the app crashes on their test device, it's rejected. The usual culprits in website-based apps are links that open in a new window, file upload buttons with no permission to open the photo picker, and pages that block embedding. Before submitting, install the release build on a real phone and tap every tab, every form and every external link.

4. The reviewer couldn't sign in

If any part of your app is behind a login, you must give Google working credentials under App content, then App access. Make the test account stable: no two-factor codes sent to your phone, no expiry, and sample data already loaded. Also check that your sign-in method works inside an app at all. Google blocks its own sign-in page inside WebViews, so a "Sign in with Google" button that works on the website fails in the app. See fixing the Google sign-in WebView error.

5. Data safety or privacy policy issues

Your Data safety form has to match what the app, and your website inside it, actually collects. If your site uses analytics, account sign-up, contact forms or payments, declare them. You also need a privacy policy at a public URL that names your app or company, and it should be reachable from inside the app as well as from the store listing.

6. Permissions you don't need

Asking for location, camera or microphone access that the app never uses gets flagged. Some permissions also trigger extra declarations in Play Console. Turn on only the permissions your site really uses. In Capsule each one is a separate switch, and features that are off never prompt the user.

7. Payments policy

If users can buy digital content, subscriptions or premium features in the app, Google generally requires Google Play's billing system for those purchases, with some regional exceptions. Physical goods and real-world services, like food, bookings and rides, can use any payment provider. SaaS apps are the most common case here: read the current Payments policy for your markets before you submit.

Pre-submission checklist

That last item catches many older wrapper apps: from August 31, 2026, new apps and updates must target Android 16 (API level 36). Read more in Google Play's target API level requirement.

Resubmitting after a rejection

Make the changes, build a new version with a higher version code, upload it to the same track and send it for review. If you think the reviewer got it wrong, for example they missed your test login, you can appeal from Policy status, explaining briefly and politely what they should look at. Don't upload the same build again unchanged and hope for a different reviewer; repeated rejections can lead to account-level action. For the full publishing walkthrough, see how to publish an app on Google Play.