TWA App Rejected on Google Play? Switch to WebView

This is one of the most frustrating rejections an indie developer can hit. Your testers were genuinely active. You had your 12 people. The 14 days passed. And Google still came back with "your testers were not engaged enough." If you built your app as a Trusted Web Activity (TWA) or a PWA wrapper, you are not imagining the pattern - across 4,500+ apps we have onboarded, wrapper builds run into this specific rejection far more often than standard native or WebView builds. This guide explains why, shows you the architecture difference that matters, and walks through switching to WebView without throwing away the testing days you already banked.

Why Do TWA Apps Run Into Closed Testing Rejections?

A Trusted Web Activity renders your website through Chrome's Custom Tabs surface rather than drawing the screens inside your own app. It is a fast way to turn a site or PWA into something installable, and for plenty of production apps it works fine. The trouble shows up specifically when a personal developer account has to clear the mandatory 14-day closed testing requirement before production access.

In our experience helping over 4,500+ apps through that process, TWA and PWA-wrapper builds hit the "testers were not engaged" rejection far more often than standard native apps, even when the testers were genuinely active every single day. The pattern is consistent enough that we now steer developers away from TWA whenever an app still has to pass the 14-day closed test.

What a TWA Actually Is (and How It's Built)

Before fixing the rejection, it helps to understand exactly what you shipped. A Trusted Web Activity is an Android app that is, in essence, your website running fullscreen inside a real browser engine - with no address bar, no browser chrome, nothing that tells the user they are looking at a web page. To the user it looks and feels like a native app. Under the hood, it is your live website.

TWAs are usually generated with Google's Bubblewrap CLI or PWABuilder, both of which sit on top of Google's androidbrowserhelper library. You point the tool at a URL, it produces an Android project, you sign it and upload the AAB to Google Play.

Why Developers Reach for a TWA

The Trade-Off That Causes the Rejection

The same thing that makes a TWA cheap makes it fragile for closed testing:

• It needs the internet. It is a window onto your site, so a weak connection means a weak app unless your PWA has solid offline support.
• Play Store rejection risk. The Minimum Functionality / repackaged-content policy targets apps that are "just a website in a wrapper." A TWA with no real native capability can be rejected or removed, especially on new submissions. Adding native features (push notifications, offline mode, camera, share targets) is how you stay on the right side of that line.
• The engagement-signal problem covered above, which is why personal accounts facing the 14-day closed test keep getting the "testers not engaged" message.

The Misconception: A TWA Is NOT a WebView

This is the part most articles get wrong, and it is worth being precise because it changes how you fix the problem. A TWA does not use Android's WebView component at all.

Because a TWA uses the engine behind Custom Tabs, you get the same rendering engine, JavaScript engine, and security sandbox as the real Chrome browser, plus shared cookies and storage with Chrome (so a user already logged in on the web stays logged in), automatic browser updates, and full web-platform support. That is genuinely powerful for a normal published app - but it also means your screens run out-of-process, inside Chrome, not inside your own app. That is the root of both the engagement-signal dilution and the low active-user counts.

The Launch Flow, Step by Step

The Trust Check: Digital Asset Links

Chrome only removes the address bar if the app can prove it owns the website, using Digital Asset Links. The app declares which website it represents, and the website must serve a file at /.well-known/assetlinks.json that names the app's package and its signing certificate fingerprint (SHA-256).

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp.name",
    "sha256_cert_fingerprints": [
      "AB:CD:EF:...:99"  // your signing cert SHA-256
    ]
  }
}]

The Engagement Signal Path: TWA vs WebView

The simplest way to understand the rejection is to follow where a tester's activity actually goes. In a TWA, your screens live one layer removed from your app - inside Chrome's Custom Tabs surface. In a WebView app, the same screens run inside your own application's process, attributed directly to your package. That single difference is what changes how strongly the activity registers.

How to Recognize a TWA (From the Outside and the Inside)

Not sure whether the app you (or a contractor) shipped is actually a TWA? Here is how to confirm it - first by eye, then definitively from the APK or a connected device.

Quick Visual Tells (as a user)

• It behaves exactly like the website, because it is the website.
• If the developer misconfigured it, you will see a browser address bar at the top - a dead giveaway (see the assetlinks bug above).
• Content updates without an app update appearing in the Play Store.

Definitive Technical Tells (inspecting the APK / device)

Confirm It With adb

On a connected device (or emulator), two commands settle it:

# Is it a TWA? Look for the delegation service:
adb shell dumpsys package <package.name> | grep -i DelegationService

# Which site does it wrap, and is the trust check passing?
adb shell pm get-app-links <package.name>
#   -> "verified"  = Digital Asset Links pass (fullscreen)
#   -> "1024"      = verification failed (address bar shows)

TWA vs WebView for Closed Testing: Side by Side

Both architectures wrap web content. The difference that matters for passing the 14-day closed test is where that content runs and how its activity is attributed. Here is how they compare on the metrics that decide whether you reach production in one cycle.

The Fix: Build a Standard WebView App Instead

Instead of patching a TWA or trying to coax better signals out of it, the cleaner path is to rebuild the app around a WebView component and publish that build. You have three mainstream ways to do it, all of which load your site inside your own application:

The Minimum WebView Setup (Copy-Ready)

The core is small: a WebView that loads your URL with JavaScript and storage enabled, keeps navigation inside the app instead of bouncing out to Chrome, and wires up the back-button handler Google's review expects. Switch the tab to your language and copy the baseline:

val webView = findViewById<WebView>(R.id.webview)
webView.settings.apply {
    javaScriptEnabled = true          // most sites need this
    domStorageEnabled = true          // localStorage / sessionStorage
    cacheMode = WebSettings.LOAD_DEFAULT
}

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.webViewClient = WebViewClient()
webView.loadUrl("https://yourwebsite.com")

// The exact back-button handler Google looks for
onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
    override fun handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack()
        } else {
            finish()
        }
    }
})

WebView webView = findViewById(R.id.webview);
WebSettings settings = webView.getSettings();
settings.setJavaScriptEnabled(true);      // most sites need this
settings.setDomStorageEnabled(true);      // localStorage / sessionStorage
settings.setCacheMode(WebSettings.LOAD_DEFAULT);

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.setWebViewClient(new WebViewClient());
webView.loadUrl("https://yourwebsite.com");

// The exact back-button handler Google looks for
getOnBackPressedDispatcher().addCallback(this, new OnBackPressedCallback(true) {
    @Override
    public void handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack();
        } else {
            finish();
        }
    }
});

# Wrap an existing web/PWA project in a native WebView shell
npm install @capacitor/core @capacitor/cli
npx cap init "YourApp" "com.yourapp.name"

# Point Capacitor at your live site (capacitor.config.ts)
#   server: { url: "https://yourwebsite.com", cleartext: false }

npm install @capacitor/android
npx cap add android
npx cap sync

# Capacitor handles back-button + DOM storage natively.
# Open in Android Studio to build a signed AAB:
npx cap open android

The Three Things You Must Add to Pass Review

A bare WebView that just calls loadUrl() is still a thin wrapper. These three additions are what make it a real app and keep testers off blank screens:

How to Switch Without Restarting Your 14-Day Clock

If you are already partway through testing, you do not have to start over. The 14-day counter survives an app update as long as you stay on the same track with the same package name. Here is the safe migration:

Does a WebView App Still Count as a "Thin Wrapper"?

This is the trap that catches developers who think WebView is a magic bullet. Switching from TWA to WebView addresses the engagement-signal problem, but it does not exempt you from Google's Spam and Minimum Functionality policy. A WebView that is nothing more than your homepage in a frame can still be rejected as a thin wrapper, the same way a bare TWA can.

It helps to see these as two separate gates. A testing service or a WebView rebuild can help you clear one of them, but not the other.

So the goal is not just "WebView instead of TWA," it is a WebView app with enough genuine value and native behavior to stand on its own. Practically, that means:

Want the deeper checklist on what triggers a quality rejection? Our guide on why closed testing gets rejected breaks down the most common policy and review failures beyond engagement.

Not Sure If Your App Is a TWA? We Check It the Moment You Order

You do not have to run adb commands or dig through your APK yourself. Yes - PrimeTestLab can confirm whether your app is a TWA for you. The moment you order our testing service, our team inspects your build, identifies whether it is a TWA or PWA wrapper, and if it is, we tell you exactly what to fix before the 14-day clock is wasted on an architecture that will get flagged for engagement.

What Happens the Moment You Order

How PrimeTestLab Helps (The Other Half of the Problem)

Architecture is one half of the problem. The other half - the one that stops most solo developers - is finding 12 testers who will actually opt in and stay opted in for 14 unbroken days. That is what PrimeTestLab handles.

We provide verified, opted-in testers on real Android devices who keep your closed test active across the full requirement, so a single tester dropping out never breaks your 14-day streak. You share your closed testing opt-in link; we handle invitation, opt-in verification, daily engagement monitoring, and 14-day retention. 4,500+ apps and counting, at a 99.9% first-attempt success rate.

Current Packages

Frequently Asked Questions

Bottom Line