The PWA Tightrope: Automating Android While Big Tech Kills the Web Dream

TLDR

Staying loyal to Progressive Web Applications (PWAs) in 2026 feels like a survival game against predatory tech monopolies. Apple’s aggressive gatekeeping and degraded iOS performance have crippled "write-once, run-anywhere" ideals. While Microsoft’s PWA Builder templates languish, its underlying engine (Bubblewrap CLI) still functions exceptionally well for Android. For solopreneurs, automating this 3-step Docker workflow—init, build, and fingerprint—is critical to maintaining an active Google Play Console account and avoiding automated purges. Ultimately, building native wrappers from web code remains a political, locked-in battleground; the true future of digital sovereignty lies beyond monolithic app stores in decentralized, serverless Peer-to-Peer (P2P) network protocols like Pear/Holepunch and libp2p.

Staying loyal to Progressive Web Application technology, despite the apparent ease by which they can be converted to become 'native apps' can leave us feeling vulnerable. It can seem like being a small rodent, waiting to be picked off by predators.

If you've been working with Progressive Web Applications (PWAs) over the last few years, you would be right to wonder if they are dead in 2026.

There has been bad press for PWAs brought about by Apple practically cancelling the tech, acting on what some described as 'aggressive compliance' to regulation by the European Union. This has at least in part been revoked but did little to instil confidence.

Pure PWAs are still significantly degraded in stability and performance by iOS restrictions on service workers and local storage. Even PWA startups can fail in some circumstances leading to bad user experiences that would likely never happen on Android.

Looking at the Microsoft supported PWA Builder is a next logical step to address some of these shortfalls in the Apple walled citadel. But if you check on PWA Builder code repositories, some do not seem to have received meaningful updates for several years. Their starter template is now 3 years since getting significant change. Yet this is referred to in their documents as the way to get started with PWAs and their builder.

The PWA Builder itself, however has received updates and currently works well to create native packages for Android. The PWA need not be based on an out of date starter project. This I can attest to and was able to use vite-plugin-pwa to do most of the heavy lifting as regards building the assets required for an application to be served as a PWA. Practically any web application such as one built with Laravel, React and Inertia can be made into a PWA.

PWA Builder should also work for iOS and Windows, but for now, I am preoccupied with Android as I have to keep my own account and customer accounts active for them not to be shut down by Google. Google has become more aggressive lately in seeking to purge all but the most active users on their platform.

Needless to say, a solopreneur trying to 'write once' using common web technology to run it anywhere has become complicated by politics, non compliance and monetisation. There is little individuals can do to navigate with certainty in an uncertain landscape. We live in a world owned by a powerful few, who have little concern for customers that they see more as resources to be consumed.

There is hope though, as Bones allegedly said to Kirk in Star Trekin,

It's life Jim, but not as we know it

And there is hope but not in a form many are aware of in the last decade of centralised, monopolistic monolithic software as a service.

Closing the gap on PWA Builder

PWA Builder is a convenient tool for creating 'native apps' from PWAs but this is not an automated process. Under the hood, PWA Builder uses Bubblewrap CLI and this can be automated and form part of automated pipelines. This has to be part of a maintained and active Google Play Console account.

Bubblewrap CLI can build an aab and apk file in just 3 steps

• initial setup

• build

• create asset link

The build step can be repeated ad infinitum by incrementing version numbers for subsequent build cycles.

Docker and a container from Bubblewrap CLI first initialises a progressive web application folder

#!/bin/bash
docker run --rm -ti \
-v "$(pwd):/app" -w /app
ghcr.io/googlechromelabs/bubblewrap:latest \
init --manifest="https://pwa.example.com/manifest.json"

This initialisation process is interactive, where you need to supply information for correct application naming and a valid certificate file.

The build, also using docker run command, can be parameterised with environment variables to be substituted for current version numbers.

#!/bin/bash
# versionCode: Increment by 1 for EVERY release (test, beta, production)
# versionName: Semantic versioning - MAJOR.MINOR.PATCH
VERSION_CODE=1
VERSION_NAME="1.0.0"
echo "Building Android app with versionCode: $VERSION_CODE, versionName: $VERSION_NAME"
echo "y" | docker run --rm -i \
-v "$(pwd):/app" -w /app \
-e BUBBLEWRAP_KEYSTORE_PASSWORD="${PASSWORD}" \
-e BUBBLEWRAP_KEY_PASSWORD="${PASSWORD}" \
ghcr.io/googlechromelabs/bubblewrap:latest \
build --versionCode "$VERSION_CODE" --appVersionName "$VERSION_NAME" --signingKeyAlias="com-example-pwa-app-alias"

to complete the apps on line presence and prior to uploading the app file to Google Play, a fingerprint ID and asset link file can be created with

!/bin/bash
docker run --rm -i \
-v "$(pwd):/app" -w /app \
ghcr.io/googlechromelabs/bubblewrap:latest \
fingerprint add "${FINGERPRINT}"

The application fingerprint can be extracted from the twc manifest json file created already by Bubblewrap CLI

cat twa-manifest.json | jq '.fingerprints[0].value'

the asset link file must be made available from your progressive web address using a well known address

https://pwa.example.com/.well-known/assetlinks.json

Further automating the upload of an aab file to a test track will enable a pipeline to keep the app active in the eyes of the Google Play Store robots. This can be done using Googles own API and by creating a credentials file and a service with appropriate permissions. I leave this for the reader to implement as this is outside intended range for this article. If you are interested in complete workflow, contact me and I can publish another article covering this whole process in more depth.

At least, for now we have an automated pipeline that can keep accounts active in Google Play and until new rules are introduced and old ones are possibly entirely broken.

PWA Builder State of Play

At this time, using a PWA to create apps that can run both as web applications and as native applications can at least in part be achieved using PWA Builder.

A couple of caveats exist in an ever shrinking window of opportunity. I believe that

• An app that just serves web content will likely be blocked by Apple and soon, if not already, Google. So an app must demonstrate some kind of user benefits over that of just being a blog or a news website. Examples of this could be early access to content prior to being published publicly. Another could be content that is curated for certain criteria such as user profiled preference or usage patterns.

• Selling content or services directly outside of the stores own sales platform own will lead to an immediate rejection or outright ban. Apple wants their 30% cut as this is a major revenue stream for them. This is something Apple will not give up without a fight, regardless what the European Union, let alone the US Department of Justice may have to say.

It is at this point I would reflect on the analogy of us as rodents waiting to be devoured by predators.

If Apple, Google and Microsoft can resist what even the governments of their origins demand, what chance do we as consumers have to influence their self serving dominance ?

An Imperfect World

I do not think that today it is possible to 'write once' and deploy anywhere in any way that could be termed 'easy' or 'straightforward'. Google, Apple, Microsoft are all gate-keeping each of their respective fiefdoms so as to protect their dictated view on what technology runs and where.

We are left with political battles left to be fought between big tech and legislators over anti competition and complicated lock-in strategies that only benefit the providers. Legislators such as the European Union may be the only hope for real change. What reforms that are implemented will always lag behind the rapid rate of technological change that law makers cannot keep up with.

Over my own observations spanning nearly 30 years in Internet, e-Commerce and social media I would see private or self hosted, personalised applications as the only, relatively safe technology to rely upon. Some countries, China being a case in point, require even for websites to be licensed as compliant with their state laws and restrictions. Should this become a requirement globally, we could see even the 'right to run a website', something of a notion rather than a given.

Beyond this, peer to peer (P2P) I think offers hope, so long as we are 'allowed' to run software on our own devices that we choose over those that are digitally signed and attested by by the stores of Google, Microsoft or Apple and the like.

Keet, an application by Holepunch uses their Pear library to deliver a P2P messaging, video, voice call and conference app that is almost entirely server-less. An initial connection between peers is first established so as to create a hole-punched network connection, where after each peer communicates without any server infrastructure. The initial 'seed' operation is served by Holepunch servers. They act, I guess, as relays. Nostr follows a similar pattern I believe but Keet and Pear 'feels' more like a true peer to peer experience to me.

Another P2P solution could be libp2p which has a number of implementations in JavaScript, Go, Python and Rust. A concrete implementation of InterPlanetary File System (IPFS) in go called Kudo claims to be the first of its kind.

The 'pursuit of root' was in the early days the measure of complete control over a server and its users but now, the owners of a platform as a service usurp this model. The Broligarchy now behaves as once countries did in the age of colonialism. The new world is not a place but a realm of internet connected services and platforms. Who owns these spaces still means a centralised single application or service. Breaking this hold will mean decentralisation of not just servers but also protocols and fundamentals, such as storage, compute and inter process communication layers.

The new battleground may well be upon network protocols rather than physical assets.

Photo by Ralph: https://www.pexels.com/photo/close-up-shot-of-a-mouse-7164046/