Have we ever found out, why did Mozilla actually remove PWA support from Firefox? Apart from the buzzwordey stuff like “focusing on delivering real value to our users” that the C-levels have been spouting. Between this and their abandonment of Servo, it really seems like they keep shooting themselves in the feet, which, considering their position on the market, just really baffles me.
They didn't. They support all the PWA APIs (ServiceWorkers, Manifests, Push, etc.), they just don't support having PWAs open without browser chrome on desktops only. On android they can be added to the homescreen and they open without browser chrome just like Chromium does.
You are technically correct, but removing a feature for a large number of important platforms is still a weird move, especially in the context of PWAs becoming more and more widely used on all platforms.
It’s still a weird decision, because if I’m going to want a PWA anywhere it’s most likely to be on desktop, not mobile.
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.
I'm guessing they did it for similarity with the chromeless browser windows that created all kinds of security problems at the early 00's for every browser, except Firefox, that gave the control of the chrome appearance to the user instead of the site.
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.
I love PWAs, I use them a lot. Some PWAs I prefer over regular apps, Outlook, Teams (although that doesn't mean I like either app generally...).
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.
It's really two steps, one to initiate the installation and then to approve it ("yes").
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's not hard to get customers to install them. I actually had to intentionally add extra steps to the process, so the customer understood they were installing a PWA, many of them installed it without realizing that they were installing it.
Is the installation different in IOS vs Android? I thought that with Android you get prompted to install it, but in IOS the user has to go out of their way to install it.
Most of the apps on my phone could've been a simple PWA. We need better design and UX for improving communication to the end users in order to make PWA's more discoverable.
I think PWA and "packaged" versions in app stores are absolutely the right route for a significant majority of apps. Obviously anything "game like", apps that needs extensive native features or is incredibly performance critical would be better as a native app. However so many apps are just a version of the web experience anyway, whether it's a content consumption app, something like an online sore, or a business/enterprise data app.
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.
The problem with PWAs is they will never gain parity with the functionality of native development, even with WASM. Unless something changes both with mobile operating systems and their respective app stores, PWAs are a failure.
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.
Because the only two platforms that matter have multiple incentives to keep it that way, and little, if any incentive to make them more useful.
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.
Because you require deep integration with the OS for some tasks, and the browsers will always lag behind that.
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.
> 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 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.
The GP probably meant mobile OS-es, not desktop ones. It would be impossible to make GPU driver or Little Snitch-like app for either iOS or Android, if you are not the OS vendor.
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.
On iOS you can prompt a user to add a WiFi network by showing a WiFi QR in an img tag (it can be set to opacity:0 and put on top of something else) and instructing the user to long-press it and choose "Join Network". I don't think you can do it on Android.
That's not listing wifi networks though, which requires access to the wifi card and the security keyrings, both things you can't do from a PWA because nobody want expose those things to the Web. Not to mention we don't have a uniform way of accessing those (check the python keyring library to see the different implementation).
What you are saying is that some OS are limiting you in what they let you do on non rooted deviced. Any desktop computer don't have this limitation, and pwa is not just about mobile.
In which case it's dubious whether PWA tech was worth using in the first place. It barely solves a problem for someone casually browsing the web, but if deploying one as a native app means using another framework and bundling an app separately then, well, why bother with any PWA APIs at all?
The overwhelming majorities of apps you use, you don't even notice you are using them. They are usually provided by the os by default, like the home screen, the alarm clock, the web browser, the network selector, the file browser, contact selector, text message sender, unlock screen... Most of them is cutstomised on one of my devices, but most users don't even think about it as software. It's just there.
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.
because web browsers are a gimmicky product that still have bugs like in firefox where you download something at it says 5MB/s for the next 2 days but it stays at 10/1000mb progress
That might be true, but as long as your specific app doesn't need the missing features, you're probably better off with a PWA. Not having to meddle with and pay 30% to app stores alone is a huge win.
That is until your app suddenly needs to do something not allowed for PWAs.
> 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.
> The problem with PWAs is they will never gain parity with the functionality of native development, even with WASM.
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.
Well they still don't allow PWAs in the Play Store without bundling them as full apps and going through the regular publishing/update/approval process, which kinda defeats the point.
Which is weird as hell because treating PWAs as apps (from a mobile UI perspective) could be built in to the OS itself. Maybe there's some reason The Google won't do this, but OSes already treats the web as a real thing (integrated web views and such), so PWAs would seem like a next step to that.
It is built into Android. Go to twitter.com, log in and then accept the install prompt that appears. It integrates seamlessly with link sharing OS UI and jump lists.
I agree with you, however keep in mind that the app stores have rules against just shipping a webview.
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.
Yeah I found the prompt annoying so I turned it off. It hid some of my UI and appeared at inappropriate times. Sites don't have enough control over how and where the prompt appears.
Edit: I think PWA installation prompts have improved since I last looked at them a long time ago. They seem maybe OK now, though some of the PWA APIs look OK until you try to use them and find out they don't work as advertised (e.g. web notifications).
My mistake - just read up on it again and Google only prohibits WebView apps of websites you don't own. I guess that explains why I never had trouble publishing apps there!
I agree with you, but it's interesting to me to observe that you haven't been downvoted into oblivion, which I think _would've_ happened if we were speaking of packaged PWAs in the form of Electron/desktop apps. Do you think the same arguments apply in that arena as well?
Electron apps are not PWAs. The difference is that PWAs share the browser engine with the user's default browser, saving memory and disk space and dramatically improving security vs. Electron.
On mobile, "packaged" PWAs are usually still using the user's default browser engine.
I am not sure why you would doubt that running two or more instances of Chromium uses significantly more memory than one, all else being equal (i.e. the same set of loaded sites).
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.
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.
This is 100% correct, but I just want to add that things like the WebView2 runtime on Windows blurs this line. The browser engine is identical to Edge, but you only use the WebView for the UI and the rest is native.
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.
To some extent yes, if you are building a mobile app and go the Capacitor route, and want a desktop app with the same functionality then Electron makes sense.
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.
We've been talking for over 8 years about it in the web developer community. But it's a pipe dream.
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 :)
> We haven't been able to convince the consumer that a website and app are not so different.
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.
Capacitor doesn’t free you from things OP mentioned: App Store updated, marketing material like screenshots, descriptions, App reviews by Apple, ratings, etc.
And all Apple users will claim it to be the best thing since sliced bread: "it's amazing - you don't need to install anything - just go on the website and the app is ready to go, while being perfectly sandboxed within the confines of your browser".
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.
Yeah, I'm aware - wrote an article about this very thing a few years ago. But they also u-turned pretty spectacularly and halted the progress of PWAs for a long time, and still continue to do so. Their supporters claim security/privacy is the main reason, but to me it's fairly clear that they're just protecting their app store revenue.
Kind of close. Here was the relevant portion of the actual iPhone announcement by Steve Jobs saying all you needed to write great native apps for iPhone was ajax and web 2.0. There was no mention of "app store" in the speech: https://www.youtube.com/watch?v=p1nwLilQy64
Yes, exactly! After years of screwing around with app store reviews, bug fixes that were made 10 minutes after discovery but take a week to deploy, and constant anxiety/fear that the elephant would take some step that crushes the ant, we took the approach of just building a mobile web site, and it is absolutely the way to go. Even just ability for people at the company to test drive the app in a browser on whatever desktop/laptop/tablet/phone/etc that they have is a huge win.
Set up an ngrok or localtunnel and they can see updates you make for the app live. During lockdown I worked with our UX designer like that, hashing out some UI details.
You're correct, the end users are the ones who want a "real app". One of the most successful websites that I turned into an app [0] had users constantly asking the owner for an app. There was already a PWA and guide on how to add it to your homescreen available. But now that I created an app that displays the website for the client, the end users are overjoyed and love it. To be fair, I add a couple native elements that improve the UX and add push notification support. But still, in essence it's just the website repackaged.
The most underrated thing about websites vs. apps is that websites have a URL. URL is almost invisible thing since we just take it as granted. Phone apps afford no such visibility into where you are in the app as well as sharing the state with someone.
What is the state of the art here in terms of reliable data persistence?
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?
It's generally still the case. I have two workarounds. Allow replication from the cloud in the event that it is cleared out. And provide a mechanism for the user to manually backup and restore.
I love PouchDB, it's incredible, however I fear its a project that is loosing it momentum (I do think it has pick up a little over the last year though).
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.
We are very close to having WASM SQLite with persistence in the web platform. Until now SQLite compiled to WASM was in memory and you had to write the whole database out as a binary array to save changes. There is absurd-sql (https://github.com/jlongster/absurd-sql), which builds a virtual file system on top of IndexedDB for sqlite, it's incredible, but a bit of an ugly hack.
A reality since browsers support plugins, what we are getting is the reinvention of what they already supported, with the difference of being native browser APIs.
I have written a few backendless PWAs that rely solely on localStorage to store user data, and it's never been purged. I think Safari might be more aggressive about it, though I've no idea since I don't have an iPhone.
For persistence across browsers/devices I provide the possibility to sync data over Dropbox and Google drive.
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.
Companies that size generally don't follow one set of perfectly aligned goals. Both make sense for Google to support, even if they occasionally contradict each other. And that's before you look inside who exactly benefits from which goal.
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.
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.
The PWA space seems to be in a state where you still have to write a lot of boilerplate. Are there any good frameworks / syntactic sugar / wrappers that make life easier for folks who would like to have smart opinionated defaults that work for most common use-cases?
Last I used angular (around v4) you had to buy-in to everything and the hello world size was an enormous JS payload. This is partly why I stopped recommending it for anything other than interactive applications with a small userbase.
It would be nice if you could bring your own site and add PWA support through a third party library.
I can't speak to mobile, I really don't know much about mobile development.
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?
- 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.
Just imagine if instead of sinking hundreds of millions of dollars into poorly specced APIs with horrible usability like service workers[1] browser devs would instead implement something that apps actually need: proper UI controls and components.
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.
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).
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.
The key is "webview", so ignore the "react-native" part and insert "capacitor" or "ionic".
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.
It's hardly any work at all. If you've made a webview you have icons and splash screens, you have what you need to make the manifest.json.
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.
PWAs have enough support that the ever-growing feature set is great. Particularly with push notifications coming to iOS soon. It's already at a place where most app development should just default to it for the sheer simplicity, control, and platform support you get out of the box.
People pick suboptimal tech choices all the time. They will continue to do so. I'm ok having competitive advantages over the wider field.
Which fud am i spreading ? I just said its not worth it when for as much work (by that i mean little) you can have a expo app embedding a webview , same result and you can publish it on the apple store, which at least was not possible for pwa when i tested it in 2021 (as said in a sibling answer i started with a pwa)
It isn't little work in the absolute but if you want to publish on the stores you have to go through it anyway.
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.
But i have already what you said, my app is only webview +a layer of 200 lines to access notification/deep link. Read my comment once again :)
And i started with a pwa so yes I know what is needed, i even got it published on the playstore. But what's the point if i can't get it published on the apple store ?
One problem I face is native apps are too large for phones in developing countries that have limited storage and network capabilities. Most people can get WhatsApp on their phone, and that's it.
Would a PWA make apps more accessible to low-end devices and networks?
I always search these threads for references to dart/flutter.
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.
I was considering using Flutter for a simple Android app, but app size is just unreasonably huge, as it includes Dart runtime. Funny enough, the hybrid web app approach, e.g. using CapacitorJS to package web app to apk weighs a lot less, in some cases it might be even smaller than native app (considering it is using androidx dependencies).
Another problem was, that I have to learn whole new language - Dart, which is not used anywhere else.
YMMW, my own experiences should not stop you from trying out a new framework, maybe it will just work for you just fine.
Google isn't known to be a good long term supplier of dev tools. Risks for adopting Flutter are fairly large. I've heard reports from some experienced devs that it has a "primary" vs "secondary" platform effect, and is simply less mature and involves more obstacles than an HTML5/CSS/JS based app.
151 comments
[ 3.1 ms ] story [ 214 ms ] threadOn 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.
https://angular.io/guide/service-worker-intro
https://whatwebcando.today
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.
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
[1] https://www.izooto.com/blog/ios-safari-push-notifications#:~....
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.
https://www.icloud.com/
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
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 :(
Just the domain, without having to package an Android app. Microsoft added that to their store years ago.
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.
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 ---
https://www.pwabuilder.com/
https://developer.chrome.com/docs/workbox/
It would be nice if you could bring your own site and add PWA support through a third party library.
https://workbox.com
https://progressier.com
https://superpwa.com
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.
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 ---
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
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.