TWA App Rejected on Google Play?
Here Is How to Fix It
If Google keeps refusing production access and blaming your testers, your TWA is the real reason, not your testers. The fix is simple: publish a WebView app instead of a TWA. This guide explains why in plain language and walks you through the fix, step by step.
Quick answer
A TWA opens your website inside Chrome, so Google cannot see your testers using it and rejects the app for low engagement. The fix is to publish a WebView app instead, which runs your website inside your own app where the activity counts. Nothing about your website changes. You can convert it yourself in about an hour with the prompt below, or keep your TWA and run it on the Testers Community Pro plan.
In this guide
What a TWA Is, and Why Google Play Rejects It
A TWA, or Trusted Web Activity, is a thin wrapper that turns your website into an installable Android app. It is what tools like PWABuilder and Bubblewrap produce. When you open your app, the TWA immediately hands your website to the Chrome browser, which shows it fullscreen with no address bar. It looks like a native app, but under the hood it is your website running inside Chrome.
That is exactly where the rejection comes from. To reach production, Google requires 12 testers to actively use your app for 14 days. But with a TWA, the activity happens inside Chrome, not inside your app. Google's review looks at usage inside your app and finds almost none, no matter how active your testers really were. So it rejects production access and points to tester engagement, even though your testers did nothing wrong.
Worth knowing: Google never publishes exactly what its review measures. But this rejection shows up far more on TWA builds than on any other type, and it disappears when the same app is rebuilt as a WebView. Resubmitting the same TWA almost always fails the same way, which is why the fix is a rebuild, not a retry.
TWA vs WebView, and Why WebView Fixes It
Both show your website and both look identical on screen. The only difference is where your website runs, and that single detail decides whether Google can see your testers using the app.
TWA - what you have now
When you open your app, it launches Chrome, and Chrome shows your website.
Your app is really just a launcher that trusts your website. All the activity happens inside Chrome, so Google sees an app that nobody seems to use.
WebView - the fix
When you open your app, it shows your website inside itself.
The website runs inside your own app, using Android's built-in browser engine. All the activity belongs to your app, so Google sees exactly how engaged your testers are.
That is the whole story. Nothing about your website changes and your users see the same screens. Only the wrapper changes, from Chrome's wrapper to your own, and that is enough to solve the engagement rejection.
How to Fix It: Two Ways
There are two clear ways to get your app through to production. Pick whichever suits you.
Convert your TWA to a WebView
Rebuild your app as a WebView so your testers' activity finally counts. You do it yourself in about an hour using the step-by-step approach below and one AI prompt, keeping your app and your testing progress.
See the approach belowKeep your TWA, use the Testers Community Pro plan
The easiest route if you would rather not touch your app. We handle everything for you. A TWA needs steady engagement, so the Testers Community Pro plan gives you 25 active testers, a detailed ASO report to strengthen your store listing, and priority support, with testers starting within 6 hours.
See the Testers Community Pro planIf you would rather not use the Testers Community Pro plan, follow the approach below to convert your TWA into a WebView yourself.
The Approach: Convert Your TWA to a WebView
You do not need to code and you do not need to prepare anything. Your app's folder already has everything the AI needs. Copy the prompt below, paste it into your AI model, and it builds the WebView app for you. Then you just upload the file to Google Play.
Find your app's folder
The one you got when you built your TWA. PWABuilder users: your unzipped download. Bubblewrap users: the folder where you ran it.
Open it in a free AI tool
Google Antigravity is free. Cursor or Claude Code work too. Open the tool, then open your app's folder in it.
Paste the prompt
Copy the prompt below and give it to the AI. It converts your app to a WebView. You just upload.
You are a senior Android engineer taking full ownership of this project. This folder holds an app that is currently a TWA (Trusted Web Activity) wrapping my website. It was built to publish on Google Play, but Google keeps refusing production access because a TWA runs my website inside Chrome instead of inside the app itself, so the app looks unused. YOUR MISSION Convert this app into a standard Android WebView app and give me back a signed file I can upload to Google Play as an update to my existing app. Do the whole job yourself. Only stop to ask me when you are truly blocked by something only I can provide or do. HOW YOU WORK - Be autonomous: read the project, decide, and act. Do not ask me for anything you can find in the files. - Match what my app already does. Do not add features my website does not use. The goal is the same app moved out of Chrome and into its own WebView, not a bigger app. - When you do need me, ask one thing at a time, say why, and give me the exact command or clicks. I may have no Android tools installed and may not know the command line, so for anything that happens on my computer, work out my operating system and give me copy-paste steps, then check they worked. - Keep me posted in plain language, and define any technical word the first time you use it. - Never print, save, or log my keystore passwords. PHASE 1 - SEE WHAT IS HERE Read the folder and work out how this app was built (PWABuilder, Bubblewrap, or something else). Find the facts you will need: the website URL, the applicationId (package name), the app name, icons, colors, and the current versionCode. Also note which features my app actually uses, such as login, file uploads, or camera, so you only rebuild what is really there. Give me a two or three line summary, then keep going. PHASE 2 - IF THERE IS NO SOURCE CODE, HELP ME GET IT A clean conversion needs my real project files. If this folder has only a built .aab or .apk plus some signing files and no source project, do not try to reverse-engineer the binary. Instead help me find my source: - Ask me where this app came from: built on pwabuilder.com, built with Bubblewrap, or made by another service or person. - If PWABuilder: walk me through going back to pwabuilder.com, entering my site again, and downloading the package with the Android project source included, then how to unzip it into this folder. - If Bubblewrap: tell me where the Bubblewrap project usually lives and which files to copy here. If it is gone, walk me through recreating it (installing Node.js if needed) from my web manifest URL. Do not continue until I have real source here. Only if I confirm I genuinely cannot recover it, build a fresh WebView project in this folder using the package name, URL, app name, icons, and versionCode you found, and tell me that is what you are doing. PHASE 3 - MAKE SURE THE BUILD TOOLS EXIST Building an Android app needs a Java JDK (17 or newer) and the Android SDK. Check what is already installed (for example, run java -version and look for the Android SDK). For anything missing, work out my operating system and give me the simplest way to install it: - The easy all-in-one option is Android Studio, which includes the JDK and the Android SDK. Give me the download page (developer.android.com/studio) and the exact install steps for my OS. - If I would rather not install all of Android Studio, give me the lighter option: a JDK such as Temurin 17 plus the Android command-line tools, with the exact commands to accept the licenses and install what you need. Tell me which one you recommend and why, and check it works before relying on it. PHASE 4 - CONVERT THE TWA INTO A WEBVIEW APP Replace the Trusted Web Activity with a standard WebView app. Core: - One full-screen WebView that loads my website, with JavaScript, storage, and cookies enabled. - Keep my own pages inside the app, and open links to other websites in the phone's browser. - Correct Android back button: go back through the page history first, and only close the app when there is nowhere left to go back to. Make it feel like a real app (this is what keeps Google from rejecting it as a thin wrapper): - A splash screen with my app name and colors while the first page loads. - A built-in offline screen with a Retry button when there is no internet or a page fails to load. Never a blank white page or a raw browser error. - Pull down to refresh. Only if my app already uses these, otherwise skip them: - File uploads or camera, through the WebView file chooser with the needed permission. - Location, if my site uses it. - Logins that break inside a WebView: Google and some other sign-ins fail inside a plain WebView with a "disallowed_useragent" error. If my site has one, open just the login page in a Chrome Custom Tab and bring me back signed in, sharing cookies so the session works. Notifications: do not add any push code. If my site asks for web push, just make sure it does not crash. (Native Firebase Cloud Messaging can be added later, after the app is approved.) Then remove all the TWA parts: the androidbrowserhelper launcher, the Trusted Web Activity setup, the DelegationService, and any Chrome Custom Tabs launcher. The app must not depend on the Trusted Web Activity mechanism anymore. PHASE 5 - KEEP THE APP'S IDENTITY So this reaches Google Play as an update and my testing progress survives: - Keep the applicationId (package name) exactly the same. Never change it. - Set versionCode one higher than it is now, and bump versionName sensibly. - Reuse the same app name, icons, and colors. Tell me the old and new versionCode. PHASE 6 - BUILD BOTH FILES - Find the signing key in this folder. PWABuilder usually uses signing.keystore with the alias and passwords in signing-key-info.txt. Bubblewrap usually uses android.keystore with details in twa-manifest.json. If you find the key but not the alias or passwords, ask me. If there is no key at all, tell me clearly: Google requires every update to be signed with the same key. If my app uses Play App Signing (most do) and I lost the key, walk me through requesting an upload key reset in Play Console (Test and release, then App integrity). Only make a new keystore if I confirm this app was never uploaded before. - Build two files with the same signing key: 1. A signed APK, so I can install it on my phone and test it before publishing. 2. A signed release AAB, for the Google Play upload. - If a build fails, read the real error, fix the cause, and build again until it works. Tell me in one line what you fixed. Do not hand me a broken build. PHASE 7 - LET ME TEST, THEN HAND OFF - Give me the exact path of the APK and simple steps to install it on my phone (allow installing from this source, then tap the file). Recommend I open it and check the site loads, the back button works, and the offline screen shows with no internet, and that I do this before uploading anything. - Give me the exact path of the AAB for Google Play. - Confirm plainly: the package name is unchanged, the versionCode went up by one, and no TWA code is left. - Finish with a short checklist: open my existing app in Google Play Console (not a new one), open my closed testing track, create a new release, upload the AAB, and roll it out. My testers update automatically and my 14 days keep running. RULES - Never change the package name. - Never keep or re-add any TWA, androidbrowserhelper, or Chrome Custom Tabs launcher code. - Do not add anything my app does not already use. - Whenever I need to do something on my computer, give me exact commands or clicks for my OS and check they worked. - You are done only when I have both files and I know how to test the APK and upload the AAB.
Nothing to fill in. The AI reads your codebase, converts the app, and builds two files: an APK to test on your phone first, and an AAB for Google Play. Always test the APK before you upload.
No AI subscription? Use Google Antigravity, it is free. Regular chat AI like ChatGPT in a browser will not work here, because it cannot build the app on your computer.
Test It, Then Upload It
The AI builds two files: an APK to install on your phone and check first, and an AAB for Google Play. Always test the APK on your phone before uploading anything. Because the package name stays the same, Google treats the upload as a normal update, so your testing progress is kept.
- 1
Install the APK on your phone. Open the APK the AI built, allow installing from that source, and check the app: does the site load, does the back button work, does the offline screen appear with no internet.
- 2
Open your existing app in Google Play Console. Go to the app you already have. Do not create a new app, that would start everything over.
- 3
Create a new release on the same closed testing track. Test and release, then Closed testing, then your track, then Create new release. Upload the AAB.
- 4
Roll it out. Your testers get the WebView version automatically, and from here their activity finally counts inside your app.
Sign-In and Notifications
These are the two things that genuinely change when you leave the TWA world, so it helps to know about them before you convert.
Google sign-in still works
Google blocks its login page inside plain WebViews. The prompt handles this automatically: the app opens the login page in a secure Chrome tab and brings the user back signed in. Your users will not notice anything unusual.
Add notifications back later
Web push does not work inside a WebView, so the converted app will not send notifications at first. Get production access approved now, then add them back later with Firebase Cloud Messaging as a normal update.
It stays a real app
The prompt adds a splash screen, an offline screen, a working back button, and pull-to-refresh. Those touches are what separate an approved WebView app from one rejected as a thin wrapper.
Frequently Asked Questions
My TWA app got rejected on Google Play. How do I fix it?
Publish a WebView app instead of a TWA. A TWA opens your website inside Chrome, so Google cannot see your testers using the app and rejects it for low engagement. A WebView opens the same website inside your own app, where all the activity counts. Rebuild your app as a WebView, upload it to the same track with the same package name, and the rejection goes away. This guide shows you how with one copy-paste AI prompt, no coding required.
Why does Google say my testers were not engaged when they clearly used the app?
Because of how a TWA works, not because of your testers. A TWA hands your website to the Chrome browser, so every tap and scroll happens inside Chrome, not inside your app. To Google's review, your app itself looks unused. Converting to a WebView app moves all that activity into your own app, where Google can measure it.
Is a TWA the same as a WebView?
No, and this mix-up causes most of the confusion. A TWA (Trusted Web Activity) shows your website through the Chrome browser. A WebView shows your website inside your own app, in your app's own process. They look identical on screen but are completely different to Google's systems: WebView activity belongs to your app, TWA activity belongs to Chrome.
Will switching to a WebView reset my 14 days of closed testing?
No. Keep the exact same package name, raise the versionCode by one, and upload the WebView build as a new release on the same closed testing track. Google treats it as a normal app update. Your testers get the update automatically and your testing days keep counting.
Do I need to know how to code to convert my app?
No. You open your app's existing folder in a free AI coding tool like Google Antigravity (or Claude Code or Cursor) and paste one prompt. The AI reads your app, converts it to a WebView, and builds the files for you: an APK to test on your phone and an AAB to upload to Google Play.
What if I lost my keystore file?
You can recover from this. Almost every app made with PWABuilder or Bubblewrap uses Play App Signing, which means Google holds the final signing key. In Play Console, go to Test and release, then App integrity, and request an upload key reset. Google verifies you and lets you sign updates with a new key. It takes a couple of days, so start early.
Will Google sign-in work inside a WebView app?
Yes, with one standard trick. Google blocks its login page inside plain WebViews for security reasons (the disallowed_useragent error). The fix, which the prompt handles automatically, is to open just the login page in a Chrome Custom Tab and bring the user back signed in. Your users will not notice anything unusual.
Can I keep my TWA and still get production access?
Yes. A TWA needs strong, consistent tester engagement to overcome its weak signal, so if you would rather not change your app, run it on the Testers Community Pro plan, which gives you 25 testers, a detailed ASO report, and priority support. Converting to a WebView is the more reliable long-term fix, but keeping the TWA is a valid choice.
Why is the Testers Community Pro plan the better choice for a TWA app?
Two reasons that matter for a TWA specifically. First, engagement: a TWA's activity signal is naturally weak, so the more active testers it has across the full 14 days, the stronger the signal Google can measure. The Testers Community Pro plan gives you 25 active testers for steady daily engagement, and testers start within 6 hours. Second, the extras that come with it: a detailed ASO report that audits your store listing and keywords so your app performs better once it is live, plus priority support so anything that comes up during your test is handled quickly. It is the most hands-off way to get a TWA through, and it is backed by our guarantee: approved, or your money back.
Bottom line
Your testers were never the problem. Your TWA ran inside Chrome, so Google could not see the engagement. Rebuild it as a WebView app with the prompt above, test the APK on your phone, and upload the AAB to the same track with the same package name. Or keep your TWA and run it on the Testers Community Pro plan. Either way, you have a clear path to production access.
Official links
Ready to Get Production Access?
Convert your TWA with the prompt above, or keep it and run it on the Testers Community Pro plan. Either way, get verified testers who stay active for the full 14 days, starting within 6 hours.