Learn PWA
web.dev
web.dev
The old thoughts about the performance of PWAs and apps built with PhoneGap/Cordova are complexity superseded now. The performance of webkit/blink on mobile devices is so impressive a well made app will be indistinguishable from a native mobile app.
If you are looking at packaging a PWA for app stores take a look at PWABuilder (https://www.pwabuilder.com) and Capacitor (https://capacitorjs.com). I particularly like Capacitor as it is so extendable, you can easily have extra functionality using native features for your packaged app. Combine Capacitor with NativeScript (https://capacitor.nativescript.org/introduction.html) and you have one codebase in one language (JS or TypeScript) that covers all your font end, on all platforms, including all native apis.
Packaging a PWA for app stores is also the best way to make them discoverable right now - he majority of users will default to looking there.
On top of that, with WASM you can increasingly use things such as SQLite (https://sql.js.org/) as you local datastore for PWAs and then, with Capacitor, use native SQLite for the packaged version, unifying your entire front end.
I do agree, however, that PWAs have adequate performance. Even back 9 years ago, performance on mobile could be acceptable, but you just couldn't overload the frontend with countless UI modules.
The problem with PWAs is they will never gain parity with the functionality of native development.
Even if we lived in a world where new features didn't have to be continually gimped and restricted in the name of tracking prevention and general security, there will never be any significant motion on PWAs so long as the Apple/Google duopoly exists.
Here, how to officialy create packages for the Android app store, https://developer.chrome.com/docs/android/trusted-web-activi...
How do you create a menu to select a wifi network from a PWA right now? Or a new driver for you graphic card? Or an equivalent to LittleSnitch?
You can't.
The only way it would be possible would be that browser, os vendors and standard commitees manage to formalize an API for every single OS behavior accross all major platforms, and do so every time something new appear on them.
This would require a level of resources and cooperation that simply doesn't exist. We already have a hard time cooperating of thing that accessing BT and USB which have been there forever.
You also cannot do those examples on native apps, they are usually only allowed by the OS itself.
Anything CRUD related can be easily done on modern browsers, games are one of the few exceptions as WebGL/WebGPU will never be a match to what Metal/DX12/Vulkan are capable of.
Still, plenty of fun can be had with Playstation 3 like graphics.
Well, that's not true.
Windows: https://docs.microsoft.com/en-us/windows/win32/nativewifi/na...
Apple OSes: https://developer.apple.com/documentation/devicemanagement/w...
Android: https://developer.android.com/reference/android/net/wifi/Wif...
And LittleSnitch is specifically an app made by a non-OS third-party that does exactly the things OP mentioned. One of the older app dev shops. https://www.obdev.at/products/littlesnitch/index.html
Not even true, if you want advanced features. Do you want sync over the local network? Nope, WebRTC cannot use Bonjour or Avahi to detect other peers without accessing the internet. Do you need your CRUD app to be able to accept parameters different configuration file granularity and from env vars? Forget about it, you don't have access to most of the FS, nor env vars. Do you need it to query a specialized database yet work offline (e.g: sig)? Shim over localStorage won't cut it. Do you need smart search, or completion? Better it not work with machine learning, cause as soon the network is down, you are on your own.
So you can do a CRUD in the sense of what microsoft access used to allow you to do. That's useful, but it's a far cry from what native can do.
It's about native vs a web app, in general.
Sure, but this is exactly where frameworks like Capacitor/Cordova can bridge the gap.
Need some widely used native functionality? There's probably already a Plugin for that. If not, you need to write your own.
It's still much less effort than maintaining a full native app. Especially if it's mostly a CRUD app with just a few native features.
An overwhelming majority of the native apps I've used on my phone need none of that, or similar OS level features.
They'd work fine as a PWAs.
None of them can now be pwa. Not event something as simple as the alarm clock because of the device going to sleep.
Some of them can be pwa but the experience is terrible on mobile: map apps and video apps are an example.
> Not having to meddle with and pay 30% to app stores alone is a huge win.
Why would Apple or The Google do that? There's nothing stopping them from charging developers for listing their PWAs on the stores. The only reason I can think of is if they think PWAs are sufficiently nerfed such that they don't need to do code review, which further backs up my original point.
If that's the case, put it into Cordova or something. Just lazily pay the price when you actually getting something for it.
They will have as much parity as the platform manufacturer wants them to. If more people and developers adopt PWA then Apple/Google really have no option but to loosen their control over their ecosystems. Maybe then we'll finally have a third competitor in the race.
Disclosure: I founded https://webtoapp.design where I create apps based on websites, which is how I know the following.
If you have a well performing website that feels like an app (e.g. by being a SPA), you can get accepted with an app consisting of just a webview. If you have a regular website on the other hand, there's a high chance you'll get rejected by Apple (Google has the rule too but basically never rejects webview apps). You can get around this by replacing some parts of your website with native components (e.g. app bar instead of website header, native drawer menu) which will make your app feel more like an app, so it's no longer in violation to the guidelines.
That's basically what I'm doing for my customers with great success (never failed to publish an app because of this rule). Of course keep all the other App Store guidelines in mind, such as whether you need to use in app purchases, provide a login with apple, etc.
I published mine years ago and it's awesome because I never have to touch it. I don't go through app review, I just update my site whenever and however I want, and my store listing just stays there. https://play.google.com/store/apps/details?id=com.darpinian....
I also published on the Windows store, which works similarly, but nobody uses it.
I went to https://james.darpinian.com/satellites/ which I found by visiting the link provided in the Play Store page and installed it as a true PWA.
I got no prompt that it was available as a PWA though, I had to open Chrome's menu and tap "Install app" manually.
However, after that you can handle it basically however you want.
E.g.: https://developers.google.com/codelabs/pwa-training/pwa04--p...
The App Store™®©
Not all app stores.
Or even multiple.
Careful, please.
On mobile, "packaged" PWAs are usually still using the user's default browser engine.
Undoubtably
> saving memory
Less certain
> dramatically improving security
How so? That seems pretty dubious to me.
As for security, as a user you can be sure that a PWA is bound by the browser's security policies which are in general quite restrictive even for installed apps. An Electron app is not bound by any browser security policy and can do literally anything that a native app can do. And if the app has any kind of JavaScript injection vulnerability then those capabilities are exposed to malicious code. There's a history of Electron apps having vulnerabilities like this. Furthermore, browsers are frequently updated to address security issues in the browser engine, while Electron apps almost always receive the same updates much less promptly. So if the Electron app ever renders HTML or JS that comes from the network (which most of them do in one way or another), you are vulnerable to those issues too.
> How so? That seems pretty dubious to me
With an electron app, I have access to your file system and can start deleting things. Yes, some operating systems might gate access but it's not standard or granular enough.
While the file system api in browsers requires your approval.
For me, this is the sweet spot for technology. Your frontend can be built once for the browser and "native", and the OS native APIs are all accessible to enhance the experience to a degree PWAs would take an enormous amount of time to catch up to.
Electron is not the ideal solution for this problem in my opinion (having developed an app professionally) - what you want is OS packaged browser runtimes to keep your bundle small and give you the evergreen web feature experience, and full OS API access. It's the best of both worlds.
Something like Flutter would be ideal if you want to avoid the DOM, but it's struggling against the web momentum and still has performance issues.
However, electron bundles it’s own WebKit, so it’s bulkier. I would quite like a platform similar to electron that uses a shared WebKit distribution. There are a few trying to do that by hooking into OS level WebKit on Mac and Windows.
WebKit is used only by Safari, and a select few open source browsers.
Tauri is an Electron alternative that uses OS provided webviews
We haven't been able to convince the consumer that a website and app are not so different.
I've been setting up Saas tool for fitness apps and its such a pain to deal with the app stores, the reviews, updates, commissions and lack of control.
It would be great if Google could direct their marketing budget to the consumers, not the devs :)
So don't! just build a PWA as your web front-end and package it as an app for the stores to distribute it (see PWABuilder - https://www.pwabuilder.com or Capacitor - https://capacitorjs.com). You get the best of both worlds, unified simple development and the App Store distribution model.
"Cross-platform apps have never been easier. All the features customers love from native now on the web... We call it iApps."
They tried. They dumbed down native programs to look more and more like web apps. The only success was Teams. /s
Then they allowed third party apps on their app store and realized how easily they could be monitized... Just watch the original announcements for the iphone and the jobs interviews from that time period.
For me the change was beneficial and customers happy because it removed the feature delay between web and apps.
So yes, there's a long way to go, but it still feels like a right direction.
Just deliver mobile Web sites, the PWA part is an optimization.
[0] I founded https://webtoapp.design
On mobile OSes there’s usually mobile apps available for a given service, but that’s not the case on desktop, where it’s sometimes useful to eschew browser chrome and defer window management to the OS window manager.
Or maybe it's for similarity with the xul applications, that created security problems by the second half of the 00's because they got control of the chrome appearance.
As a rule, every time browsers gave control of the chrome to the content, it went badly. It's the kind of problem that can certainly be solved by creating the right set of capabilities, but the Firefox developers decided to focus on some other problem.
But I feel like the only reason I know about PWAs is because I'm a developer, and I really don't think about providing them to customers / introducing them. Explaining a PWA, how to install it and all... it's not really apparent to end users what is going on / why they have to go through these steps.
I feel like PWAs are this wonderful little secret ... but have been for so long I wonder if non technical folks will adopt them.
You mean the single step of clicking "yes" when prompted to install.
It's one thing to ask technical folks to do a thing, another less technical.
You need to design some intentional onboarding for this to work consistently.
Including one that I probably wrongly assume is true of everyone - that they will be very selective about what apps they install.
You can wrap the initiation any way you like. I prefer to make it resemble an app store people are familiar with. Screen shots, user feedback, a description with a "download" button. This communicates the intention pretty well even though it adds an extra step to the process.
I find the biggest hurdle is that people don't realize they can install an "app" so easily and so I try to bridge the knowledge gap.
It might actually be too easy.
I keep saying: there's a reason all the CSS and UI frameworks on the web re-implement the same paltry dozen of the most primitive components and rarely if ever tackle anything complex.
https://open-ui.org is too little too late.
[1] To quote Dan Abramov, https://dev.to/ben/why-the-react-community-is-missing-the-po...
--- start quote ---
React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a carousel they get an aside. Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up).
--- end quote ---
Last I was seriously looking at the PWA route, I understood that they were best suited for apps with always-online access because anything stored locally could be more or less jettisoned as soon as the device felt disk pressure. Is that still the case or did I dream that up?
In the morning, it syncs pouchdb with couchdb server, cache all the pages then goes to offline first mode.
Anytime they get internet signal, the serviceworker would send the data to postgresql.
Pouchdb takes care of sync and all the multi browser storage problem.
It has a very aggressive stale bot closing issues (this search shows 700 closed stale issues https://github.com/pouchdb/pouchdb/issues?q=is%3Aissue+stale...), some which I really don't think it should have. It gives the impression of a very active but stable platform that I don't necessarily think is accurate.
For example I found a version hash collision bug while working on a side project, the issue was closed as stale (https://github.com/pouchdb/pouchdb/issues/8257)
But the core features (store JSONs locally, sync them up with CouchDB) have been stable and reliable for many, many years and just work.
However, the new File System Access apis (https://developer.mozilla.org/en-US/docs/Web/API/File_System...) that are landing in browsers will fix this. One of the things it does is enable very efficient block level read/write access to a privet sandboxed filesystem for the websites origin, perfect for persistent sqlite. There is more here: https://web.dev/file-system-access/#accessing-files-optimize...
For persistence across browsers/devices I provide the possibility to sync data over Dropbox and Google drive.
I lost my Wordle stats thanks to that feature :(
[1] https://www.izooto.com/blog/ios-safari-push-notifications#:~....
Just the domain, without having to package an Android app. Microsoft added that to their store years ago.
But when it comes to the desktop, what's the motivation for a PWA over something like Electron?
I appreciate the app size would be much smaller, but then you're back to fighting browser and platform compatibility issues (such as those browsers that have weak support for PWAs). Seems that inevitably you'll be doing "Yes, its a PWA, but it only works/only been tested on Chrome". Well, may as well go full Electron and lock that choice in, right?
Or am I overblowing it?
- Low friction install process. Prompt user and you're done.
- No extra distribution channel (same build as web, auto updates baked in)
- Permissions sandboxed by browser.
Cons:
- Compat (though for some simple apps using mature APIs this is not a big issue)
- Limited to browser features and performance. Can't integrate deeply with OS.
- PWAs have much lower download requirements, whatever your SPA page weight is pretty much the download size. 1-3MB is pretty common.
- PWAs will use lower memory overhead as you don't need a new copy of the browser - it shares with the likely default system browser.
- Launch time can be very snappy even on lower end systems if the base browser is already loaded and you manage offline assets well.
- Don't need to build for Windows, Linux, MacOS. One build serves Web, Windows, MacOs, and Linux users.
Additional cons:
- No guarantee of local storage remaining unmolested by the browser. In practice, it's fine unless a user's disk is filling up then you can get purged.
- Most obvious OS integration limitation is the inability to control the menus on MacOS. You get a generic set that comes with the PWA.
Don't forget that they also get Android and iOS, unlike an Electron app.
It would be nice if you could bring your own site and add PWA support through a third party library.
Would a PWA make apps more accessible to low-end devices and networks?
A PWA is basically a web app that can be 'installed' (cached) so it can run without a network connection.
I guess this just depends on the application.
Most of my phone's apps take dozens if not hundreds of MBs for some inexplicable reason.
Not only is storage a constraint, sending text is free on WhatsApp[0]. Even if an SPA was small, they still have to pay for data.
[0] - https://prepaid-data-sim-card.fandom.com/wiki/Indonesia
I'm a beginner in this area. I'm going to be creating a simple app soon. I would like it to run on desktop and mobile, not the web, and don't want to have to create 2-3 different versions. I'm looking at dart/flutter.
I'm not adverse to PWA but due to limited integration with the underlying OS I have kind of ruled out the web because I don't want to run a website for this.
Dart/flutter hardly ever gets mentioned on HN and when it does its generally not well received. So my question is what's the issues? My probably naive view is dart/flutter is the way to go.
Cordova, React native, Etc.
Which ones are best? Dart/flutter seem to offer everything. Though I have heard there are size issues with the resultant program.
Oh yeah! That's a good feature of Firefox. I would hate your crappy web site to go full screen without me choosing that.
If you are a small business / entrepreneur and you have a working product on one platform, you should be able to port to another platform with minimal effort, where you can at least have a MVP without having to recreate your front-end from scratch.
- If you already have a website and you want to do an app, PWA is probably a simpler path compared to recreating your front-end in Flutter.
- Likewise if you already have a working Flutter mobile app and your users start to ask for a web or desktop version, it's easy to get some sub-optimal version out with less effort if you can re-use a lot of your Flutter code.
It also makes it easier to maintain if you structure your code in a way that separates out the logic that's specific to platforms.
If you manage to achieve product-market fit and your business benefits from your users being first-class citizens on the web and on the phone, you can start to invest in those development teams.
That is what happens when each business unit has their own agenda.
Within Chrome it's Chrome vs Android (and possibly a few other teams). To quote https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
--- start quote ---
When performing Valley Kremlinology, it is useful to see Google policies as stemming from a conflict between internal pro-web and anti-web factions. We web developers mainly deal with the pro-web faction, the Chrome devrel and browser teams. On the other hand, the Android team is squarely in the anti-web camp.
When seen in this light the pro-web camp’s insistence on copying everything appy makes excellent sense: if they didn’t Chrome would lag behind apps and the Android anti-web camp would gain too much power. While I prefer the pro-web over the anti-web camp, I would even more prefer the web not to be a pawn in an internal Google power struggle. But it has come to that, no doubt about it.
--- end quote ---
Just this morning, I was asked to rip out some popular javascript frameworks and advanced browser concepts like indexdb and PWA from our enterprise tech stack.
just create a web app (SPA or plain old multi-page app) and embed it in a react-native-webview. (or any equivalent)
You will just need a thin layer of react-native-code to handle push notification/a nice splash screen/deeplinking and for 99% of your user it will be the same
We've been doing that at Rosaly.com for now 2 years, and we've never have any issue from Apple/Google reviews and our "think layer" is now ~200 LOC of react native around a multi-page old website (plain html and link to other page, with a "app" design, no react/angular) and it's totally transparent for our users, while allowing us to deploy 10 times a day.
React-native doesn't let you easily reuse your webstack to build it. It's not a web view but a way to create a javascript controlled runtime for a native interface. In my experience it's a rewrite and every effort to share components between react-native and react-web hasn't panned out well.
You can create the simplest of service workers and your done.
If you want better offline ability, you need more TLC in the service worker - which you would need anyway if you want your webview to work offline as well.
The "extra work" takes a few hours. The boons of the PWA over the webview, updates are much much easier to roll out. You don't have a bunch of ancient versions running around. If you don't need access to native APIs this might be worth pushing users to use it.
So much FUD around them...
People pick suboptimal tech choices all the time. They will continue to do so. I'm ok having competitive advantages over the wider field.
my point is that
* with PWA you just can't on the Apple App Store (to the extent of my knowledge, I would love to be proven wrong, once again I started with PWA because I wanted it to be the silver bullet)
* with Expo you can, it is work, but it's far less than without, in 2021 we used bitrise.io which required us only to drag and drop pre-made steps, it will soon be 2 years since the app has been first published and I still don't own a mac nor I have opened android studio even once. in 2022 I think Expo provide a Saas to make it even simpler.