Why I Stopped Recommending Website-to-APK Tools to Clients (And Built My Own)

Megson Morgan — Sat, 19 Sep 2026 06:54:04 +0000

If you do freelance or agency work in Nigeria/Ghana, you've probably had this conversation: a client with a working website asks "can you just make this an app?" The honest technical answer is usually yes — Google's Trusted Web Activity (TWA) makes this genuinely straightforward, no native code required. The less honest part is what happens after you hand the APK over.

The actual mechanics of a website-to-APK conversion

A TWA is essentially a signed Android app that launches a trusted, chrome-free instance of Chrome pointed at your site. Under the hood, most tools in this space (including mine) use Google's own Bubblewrap CLI to generate the Android project, sign it, and produce an installable APK or AAB. The two real technical requirements are:

A valid web app manifest (manifest.json) — name, icons, start_url, display: standalone.
A Digital Asset Links file (assetlinks.json) served from /.well-known/ on your domain, which is what lets the TWA hide the browser chrome instead of showing an "unverified" bar at the top.

Most tools handle #2 automatically once you provide your signing key's fingerprint. Where they differ — and where I kept running into client complaints — is #1: a huge number of ordinary business sites simply don't have a manifest at all, and plenty of converters just fail outright when one's missing, dumping a cryptic error on a non-technical client.

The subscription-lock problem nobody mentions upfront

The bigger issue wasn't technical, though — it was the business model of the popular tools. Several of the well-known converters are Windows desktop apps that gate rebuilding behind an active subscription. Your client pays once, gets an app, everything's fine — until the subscription lapses (easy for a small business juggling a dozen bills) and now nobody can touch that build again. Not a new feature, not a bugfix, not even a simple icon change. The app they paid to have built becomes frozen, indefinitely.

That's not a TWA limitation. It's a decision someone made about how to monetize the tool.

What I built instead: Mega2APK

I built Mega2APK as a browser-based alternative specifically to remove that lock-in:

No desktop app — it's a web app, so no OS restriction, no ".exe, trust me" friction.
Builds are permanent. A lapsed plan never revokes access to apps you've already built — your build history stays attached to your account indefinitely.
Auto-generates a missing manifest. If a site doesn't have manifest.json, Mega2APK detects that and generates a working one automatically instead of failing the build.
A second, native build engine (real Kotlin/Gradle, not just TWA) for people who eventually want more than a WebView wrapper — AdMob, biometric auth, deeper native hooks.

Every account starts with one free build credit — no card required — so you (or your client) can see the real output before deciding anything. Paid tiers start at $15 one-time, with $29/yr and $59/yr for custom package names, push notifications, in-app purchases, and AAB output for Play Store submission.

If you build client sites, this is worth having in your toolkit

Even if you'd rather build native apps by hand for bigger clients, having a fast, honest way to answer "can we get an app?" for a small-business client who just needs a Play Store presence is a genuinely useful thing to have bookmarked. Try it here — happy to answer technical questions about the TWA/Bubblewrap side in the comments if anyone's curious.

DEV Community: Megson Morgan

Why I Stopped Recommending Website-to-APK Tools to Clients (And Built My Own)

The actual mechanics of a website-to-APK conversion

The subscription-lock problem nobody mentions upfront

What I built instead: Mega2APK

If you build client sites, this is worth having in your toolkit