TWA or Bubblewrap App Rejected: "More Testing Required"

This page is for apps built as a Trusted Web Activity (TWA) — with Bubblewrap, PWABuilder or Android Browser Helper. If your app is native, Flutter, React Native or a game, our general "more testing required" page covers the same message.

Does Google treat TWA apps differently?

Not according to anything Google publishes. Google's testing requirements give two reasons it may require more testing: fewer than 12 opted-in testers, or insufficient tester engagement during the testing period. Neither the requirement nor the questionnaire mentions app architecture, web apps, TWA or WebView. TWA apps are allowed on Google Play and go through the same closed test as any other app.

Some developers and testing services say they see "testers were not engaged" more often with TWA apps. Google has not documented how it measures engagement, for TWA or for any other app, so treat that as an unconfirmed report — not a rule, and not a reason to rebuild your app as WebView before you have looked at your own test evidence.

Why a TWA test can read as thin

A TWA opens your website full screen inside the browser installed on the phone; the browser renders the content. That has practical consequences for a closed test:

1. Opt-in is not usage. Testers opting in and installing from Google Play counts toward the 12-tester minimum, but the questionnaire asks what they actually did in the app. A tester who opened it once and saw a splash screen gives you nothing to describe.
2. A visible browser address bar. Chrome's own documentation ties removing the URL bar to the association between the app and the website (Digital Asset Links, the /.well-known/assetlinks.json file). If testers see an address bar, the app is running as a browser tab instead of a full-screen app on that origin. That does not mean Google will reject the app, but it is a visible defect testers should report — and a common cause is a fingerprint mismatch: with Play App Signing, the key Google signs your release with is not your upload key.
3. Sign-in and checkout that leave the app. Login providers, payment pages and links to another domain can open outside your verified origin. Testers should go through them on purpose and say where the flow broke.
4. Offline and back navigation. A web app has to handle no connection, the Android Back button and coming back from the background. These are the first things a reviewer-style test exercises, and the first things a website wrapped as an app tends to miss.
5. Updates that change nothing in the app. Many TWA fixes ship on the website, not in a new build. That is fine, but write down what changed and when, so "what did you change after feedback" has a concrete answer.

How Testers14 tests a TWA

We accept TWA and Bubblewrap apps on every plan. On top of the 12+ testers who stay opted in for the full test, we run functional sessions on real Android devices: the core screens of your site used as a person would use them, background and resume, and a check on every session of whether the browser address bar is showing — so a Digital Asset Links problem shows up as a reported bug with a screenshot, not as a surprise. Each bug is retested on the next build, or after you tell us the site changed, and marked fixed or still open.

What we do not promise: Google alone decides production access. The Testing Coverage Guarantee covers the tester coverage in your plan, not Google's decision.

Before you reapply

Check the row-by-row evidence audit on our general "more testing required" page — it applies to TWA apps unchanged. Then add the TWA-specific points: the address bar is gone on every device you tested, sign-in and payment stay inside the app, and you can name the website changes made during the test.