…and with that, I mean a web app that works and feels exactly like a native app.
Why, what’s wrong with native apps?
Let’s say you come up with a great concept for an app or service, e.g. in my case, a minimalistic micro journaling app. You naturally want it to be available to as many users as possible, no matter where they live and which device(s) they choose to have on their desk, wrist, and/or in their pocket.
For a decent-size corporation that is no big deal, just let your product team come up with a design and hire a bunch of Android-, iOS-, and web devs to implement a version for each platform (3 in total). But for a small organization or an indie hacker that is not an option, you just don’t have the resources to build and maintain three apps.
Well, there are cross-platform solutions out there. The usual suspects are React Native, Ionic, and Flutter. They are all great and give you access to native device APIs. React Native and Ionic even allow you to use the web stack (HTML, JS/JSX, CSS) and frameworks like React or Vue to build your app fast.
(Thanks to Daniel Roe, using Nuxt will soon also be an option with nuxt/ionic)
Image from enappd
Nice, but they all share one problem: the app still needs to be packaged (several times), deployed to the web, and submitted to the respective stores of Apple, Google, and Microsoft.
This is annoying because updates to your app will be delayed by the review processes of each store as well as by users just deciding to not update their apps for ages. Your backend/API, therefore, has to be able, in theory, to work with every version of your app that ever existed. Meee…
Additionally, you are forced to implement multiple payment solutions (including accounting!) according to store policies (3 in this case, plus 1 for the web). And what if you want to accept Lightning payments for example?
What about Progressive Web Apps (PWAs)?
Progressive Web Apps (PWAs) are great and you can even publish them — with limitations — to most of the app stores out there via tools like bubblewrap or PWA Builder. See also Trusted Web Activities (TWAs) and my previous post Publishing a Progressive Web App (PWA) on the PlayStore — What works and what doesn’t (in 2021).
Image from web.dev
But progressive loading and caching are not really what we want when we’re talking about a “native-like” app.
A native app, once downloaded, works offline. That’s also the premise of a PWA, but a Progressive Web App (as the “P” in the name suggests) will only cache pages and update them when visited. So, the app is not really fully offline capable, but rather online with a fallback.
This behavior is useful to enhance the experience of web services and there are stats to prove it, but for a lot of use cases, i.a. my journaling app, this will just not work.
So let’s tweak it a bit…
Native Web Apps (NWAs)
What we really want is a PWA with impromtu caching and immediate full-offline support.
What would it look like?
Let’s look at an idealized concept that would resolve (almost) all of the problems we currently face with native apps as well as PWAs.
Instead of consulting an app store, you open the homepage of the app that you want to acquire, e.g. www.journalisticapp.com. There are two options here, either you are prompted with an install banner à la PWA or there is an install button triggering the installation manually. Ideally, the choice between the two options should be left to the developer.
Once the install is triggered the app will be downloaded (aka. fully cached) to the user’s device and therefore be available for offline use immediately.
There are currently no technical hurdles that stop us from implementing such an app, even though there is no out-of-the-box solution and we will have to tinker with workbox and/or service worker scripts.
However, it will be limited.
I mean, it is clear that we will have to take a performance hit when relying on a JS codebase that executes on a single thread in the browser as opposed to native Java or Swift code optimized for the chip architecture. But not all apps are performance critical. Those that are will not get around a native implementation any time soon I guess.
So what’s missing?
While progress is being made to enable access to more and more device APIs via Web APIs, there are still a lot of critical ones that are missing, e.g. control over the navigation bar color, access to a device’s security chip, or biometric authentication.
It would also be important for an NWA to have dedicated storage that is not shared with the browser and that can be encrypted and/or blocked, e.g. when the user is not authenticated or has locked the app. As of this writing, the only feasible storage option for the web that ships with the browser is IndexedDB.
Summary
It would be amazing to have web apps that are indistinguishable from native apps that combine the best of both worlds and that can be downloaded directly from the web. The latter is especially important when contemplating the decentralized future of applications and web3.
In all likelihood, I’ll keep going down the NWA rabbit hole with Journalistic and keep reporting back on how far I’ll get in the quest to build a web app that is indistinguishable from its native counterparts.
Thanks for reading and have a wonderful day ✌🏽
Top comments (0)