PWA is becoming more and more usual on our phones. If it's so easy to deliver and maintain, why isn't it more widely used?
In this post I'll propose a conceptual "app store" free mobile OS and a very different monetisation model, in a vision which would free us from biased store content and turn the mobile back to the free web.
"I want to make something really clear: We support two platforms at Apple. Two.
The first one is HTML5, a fully open uncontrolled platform (...).
The second one is the App Store. (...)"
- Steve Jobs, 2010
I've discussed how iOS in particular has moved from being the web innovator in 2010 to becoming the internet explorer of the mobile era.
But like... supercharged.
Hear me out -
"Firefox OS again?" Not exactly.
Firefox was bound by 3 concepts we disregard here from the start:
- hybrid downloadable apps from a store
- cheap low-end phones
- lack of monetisation strategy
- do not want a "store"
- assume modern decent phones and PWA standards
- drive phone lifetime monetisation to manufacturer
Note: In case you never heard of PWAs before - read about it here.
- Browser app controls still take considerable space in the mobile web interface :(
- Not an issue on full-screen mode PWA :)
- No longer an issue for DB & cache data
- In DB file storage already available
- Driven by app store
- Driven by app store
- Not an issue for "common" apps in fact, a lot are just webview wrapped HTML5 today...
- Games/3d/AR are quickly catching up (WebGL, WebXR, WebAssembly, WebGPU, etc)
We can see from the above that most issues on mobile web today are bound to the phone OS/store, its marketing and biased strategies, more than the mobile web technology which is coming leaps and bounds since 2010.
"Web content on my phone is simply not the same as apps"
The main reason for this is that you need to cater for the controls of the browser app itself such as address bar, settings, favourites, etc.
We still see the browser as a the app, and the web content as... just content.
The answer would be a web-only mobile OS UI.
By having the concept of “web browser” as the only client runtime, we can immerse the web experience into the mobile phone UI. Apps become just tabs, and “bookmarking” is no different from “installing”.
Let's take our modern phone to a "blank slate" and start off from a basic modern dashboard. Taking Android UI as a baseline, we could merge
switch app buttons into a single button, and take the old
switch app place and use it for
Then when we travel to a web page/app, say gmail, the web page would be an "app" in itself and always present fullscreen
This seems natural!
It doesn't "feel" like mobile web anymore.
But what about browser controls?
context settings button we've added?
Ok - now its even easier to control security and permissions for any app that on a "native" apps phone!
"Yeah but web apps can’t really create and store stuff locally"
Actually today they can.
There is already a suite of solutions for web apps in use today:
Storage API standards:
- IndexedDB API - large amounts of data & files/blobs
- Cache API - in-app assets cache
- Web Storage API - in-app session information
We just need to organise appropriate storage settings and limits for installed and non-installed apps, and enable user review/override when necessary.
Managing in-device storage also becomes much simpler than in other mobile operating systems today that need to account with multiple storage solutions for different app types.
"How are users going to get access to filtered quality content without a store? How are developers going to promote their content?"
The web already knows how to marketing
Ads and SEO have been around for a long time and they are the natural marketing strategies of the web.
It is the natural solution for developers which is provided out-of-the-box by the open web.
Having said this, the manufacturer could consider some kind of branded dashboard/portal where top compatible “apps” can be listed...
"Sounds like a cool project but we can’t really make money without a store"
Enter crypto-currency superpowers
Payment Request API already exists today.
With some work in this field we could easily can turn our phone into a eWallet for web payments.
Phone manufacturers can bundle their own crypto providers to phone users and thus leverage of small micro-transaction fees out-of-the-box with the phone.
Also - using crypto would make payments processing much easier in the web apps themselves.
"But can the content quality ever really match up to native speeds?"
We know things have been evolving incredibly fast - we now have near-native speeds in web content today with WebAssembly, basic 3D graphics via WebGL, augmented reality capabilities via WebXR, threads via workers, and many, many other APIs.
Vulkan/WebGPU is expected to soon enable game developers to reach even closer to native-level graphics with thousands of 3D objects not degrading performance, much above the ~100 objects that we can do today with WebGL.
We don’t have the tools, frameworks and engines today that we do in native apps - but part of the problem is exactly because there has been no real need/business case for it. We just put up a native app instead.
But with broader PWA adoption and newer web APIs, developers will soon create such tools and there is no real technical limitation in the near future for any relevant discrepancy in web vs native experiences.
I've pitched the idea to a few people over the last 3 years, and mostly everyone discards it as meh.
So I've decided to post it here - maybe someone else will agree or build upon the idea :)