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 cancelled the tech, acting on what some have 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 refereed 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. This I can attest right now. It 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 aggressive lately in seeking to purge all bu the most active users on their platform in recent months.

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 one person can do to navigate with certainty in a world increasingly owned by a powerful few that seem to have little concern for customers that they seem to see more as a resource than people.

There is hope though, as Bones said to Kirk in Star Trek of old, "It's life Jim, but not as we know it". And there is hope but not in a form many of us are perhaps as aware of or familiar with in these decades 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 each cycle.

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

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

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 your interested in how the 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 number of caveats exist in an ever shrinking window of opportunity.

I believe that any 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 with direct selling outside of any of the stores 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 bitter fight, regardless what the European Union, let along the US Department of Justice, deepening on their current administration may demand from time to time.

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 to 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 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 changes actually happen will lag behind the rapid rate of 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 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 fully 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 pear (P2P) I think offers some glints of hope, so long as we are 'allowed' to run software on our devices that we choose over those that are digitally signed and atested by a stores owned by Google, Microsoft or Apple.

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. In 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 gues,s as sort of relays. Nostr follows a similar pattern I believe but Keet and Pear 'feels' more like a true peer to peer experience to me.

Another reason for hope could be libp2p which has a number of concrete 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 battle ground may be based on network protocols rather than physical assets.

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