Candy Mass is a web game. It runs in a browser, it is written in HTML, CSS and JavaScript, and there is no native code in it. It is also an app on the Play Store. Both of those are true because of Trusted Web Activity, usually shortened to TWA.

What a TWA actually is

A TWA is a thin Android app whose only job is to open a URL in a Chrome-backed view, with the browser chrome hidden. From the player's side it looks and feels like a native app: full screen, an icon on the home screen, no address bar.

What it is not is a bundle of your files. The app loads your site every time it launches. That means a deploy is live immediately for everyone, with no store review and no update. That is the single biggest advantage of the approach.

The one link that has to be right

Chrome will only hide its address bar if it can prove that the app and the website are controlled by the same owner. It proves this with Digital Asset Links: a file served at a fixed path on the domain that lists the app's package name and its signing certificate fingerprint.

https://yourdomain.com/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.game",
    "sha256_cert_fingerprints": ["AA:BB:CC:..."]
  }
}]

If the file is missing, wrong, or served with the wrong content type, the app still runs — but with a browser address bar across the top. It looks unfinished. This is the single most common mistake in this workflow.

The fingerprint trap

Here is the part that costs people days.

When you upload an app to the Play Store, Google re-signs it with its own key, called Play App Signing. The app that players install is signed by Google's key, not by the key you used to build the upload bundle.

So the fingerprint in your local assetlinks file, copied from your own keystore, is the wrong fingerprint. It matches the APK you built locally and nothing that came from the store.

The correct fingerprint is on the Play Console, under App integrity, on the app signing key certificate. The file must list that one.

And it is safest to list both: the Play signing key and your own upload key. Then a locally installed build and a store-installed build both work.

The symptom if you get it wrong

Nothing errors. There is no log entry to tell you what is wrong. The app simply opens with a URL bar at the top, which makes it look like a bookmark shortcut rather than an app.

That is the confusing part: the failure is silent, and it looks like a packaging problem rather than a certificate problem.

The checklist that works

In order:

Register the package name in the Play Console before building anything. Build the signed bundle with a keystore you have backed up somewhere safe. Upload it, and let Play App Signing do its work. Then read the app signing certificate fingerprint from the console and put it in the assetlinks file. Serve that file at the exact path, with a JSON content type, and no redirects.

Then install from the store, force stop the app, and open it. The address bar should be gone.

What a TWA cannot do

It cannot use most native APIs. There is no access to in-app purchase through the Play Billing library, no native haptics, no push notifications, no Game Center equivalent.

That is the real trade. A TWA gives you instant deploys and one codebase. It costs you native features. For a simple game that is a fair trade. For anything that needs purchases or notifications, you eventually move to a wrapper that bundles the assets — Capacitor or similar — and accept that a deploy now means a store update.

Is it worth it

For a first game, yes. It is the fastest route from "I have a web game" to "I have an app on the Play Store", and it keeps the deploy loop at seconds instead of days.

The catch is that the web-first approach is a phase, not a destination. The moment you need native features, you will rebuild the shell. Knowing that in advance makes the decision easier, not harder.

← Back to all articles