Spam you with spam spamifications. Clutter your mobile device device with more twisty little icons that all look look the same. Attempt to store content with an unreliable storage service.
Move on folks, nothing more to see here. PWAs are just another Google side project, talking about them in 2024 is like still being hung up on a chat app Google killed years ago or being that guy who did his whole house up in Material Design.
Whatever their merits, PWAs are not a Google side project. The idea was first proposed by Steve Jobs and Microsoft is excited about it, too [1]. In other words, all the big players are in on it.
It's a good idea and frankly superior to the current Store+PhoneApp approach to making stateful apps that can run on mobile devices. Contributing helps. Being sour, not so much.
Some of the functionality listed on this site is not part of the web platform, but rather Blink-only APIs Google implemented unilaterally that have been explicitly rejected by Mozilla and Apple.
Mozilla rejects stuff like webusb while apple is blocking add to home screen, push notifications, etc. Stuff that is needed to replace many app store apps.
Firefox supports both add to home screen and push notifications.
PWAs already support push notifications and add to home screen on iOS.
Or by “add to home screen”, are you specifically referring to BeforeInstallPromptEvent / prompt()? That isn’t a web standard. It’s something Google alone have implemented, it’s a Chrome-only feature. Firefox hasn’t implemented it either.
> Status of This Document
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
If its that simple then why is Apple blocking the most useful features like push notifications and add to home screen? Those aren't particularly useful for tracking.
I think web apps are great. The average brand has no business making a mobile app when an web application would do.
It's the "progressive" part I have a problem with. Web apps revolutionized our idea of what an application can do; everything in PWA makes web applications worse, not better.
Just to take a simple example, when I want to visit Hacker news I just type n in the address bar of my iPad and click on the auto-suggest result and I am there.
If I had an app for it, it would compete with all the other apps that have a burnt umber orange icon or that have an "H", an "N" or a "Y" as their own logo. (McDonald's might be the only brand that can pull that off) If I had an app for that I'd also be installing lots of other apps and have 4 or 5 pages of them to scroll through. If anything, brands should be asking for ways to make installed apps as easy to find as uninstalled web pages are.
(Note all the things I complained about originally except the lack of a reliable storage facility, are problems with apps. What makes it a 'side project' is that PWA advocates keep denying that "it just doesn't work" and then act incredulous that nobody wants to waste time with them.)
If anything, most app authors should just quit drinking the Kool-Aid and just make plain ordinary web applications without any of the PWA power-downs. It's like playing a Mario game and finding some mushroom that makes you smaller without any benefit (like being able to go in some hole.)
What are you even talking about?
PWAs are an option on top of an ordinary web app. I guess all PWAs can be opened in the browser without "installing" them.
Also "competing with all other apps" is the fault of OS built-in search. Nothing to do with PWA
First of all, no, even if I did, that would only be hypocritical if I was rooting for the law not to apply to the app store. But I am not expecting either.
So you don't count on the law to free you from the Apple Store (because that is the only major platform with a lock-in), but you hope that somehow magically PWAs will be distributed on iOS?
It’s good to hear that PWAs are still on Firefox Android, even though they’re out of Desktop.
From my [fairly-out-of-the-loop-for-the-past-few-years] vantage point, Mozilla’s been a lot less invested in the PWA ecosystem since they abandoned their Firefox Phone / Boot2Gecko initiative, which was intended to create a middle tier between the expensive smartphones of the early 2010’s and ubiquitous and cheap feature phones (flip phones, classic Nokia candy bars), and expand access to the web across the world with it.
All the apps were PWAs, which made it simple to build out. Eventually Mozilla stopped the project, but KaiOS became a commercial implementation and it still runs on a fair number of feature phones to this day.
But without that pressure for PWA support in Firefox as a critical mobile feature, it was largely serving as an expensive bookmark launcher in the Firefox code base so that folks could alt-tab to the small number of sites that supported it on their desktops. Not a noble end for Mozilla’s support for what should have been / could have been an incredible leverage point for the web ecosystem and open development.
It's kinda sad that the website doesn't prominently display which features have "universal" support across iOS and Android. The whole point of PWAs is to provide cross platforms apps so if a feature isn't available on all/most platforms, I don't think it's fair to say that it's really usable at all in your PWA.
Knowing what will come and be available is also a valid use case. If you want to know about support every feature has links to MDN and caniuse, just check there. The web isn't as simple as comparing iOS/Android. For example Firefox on desktop isn't Firefox on Android and Firefox on iOS is just Safari. The web is a complex ecosystem.
Depends. What if your PWA is an in-house app for operators in your company? They all have an issued device with MDM, one or a few skus, all apple (or all Google).
I think most in-house devs would rather not deal with the app store or the vagaries of getting the MDM side loading pathway working
PWAs are the next step in mobile Web, for most forms over data apps, it isn't really needed.
When I came back to Web/Distributed Systems after my stint dealing with Windows desktop, all the applications I have been involved only had Web frontends, including for mobile devices, not Web views, the actual browser.
"ad-driven websites" and PWAs aren't targeting the same user. Even if they were, there's nothing stopping a PWA developer from adding a Google Ads script to the markup.
Doesn't https://caniuse.com already fill this need? This article is just evangelism, if you want technical sources the community has had you covered for a long time.
Sure you can look things up but it would be nice to look at this evangelism site and tell at a glance that Bluetooth isn’t supported everywhere the way playing a sound is.
To clarify what you're actually trying to say: Access to the low level Bluetooth device API is not as pervasively supported as audio output is. Quite clearly you can play audio to a bluetooth device in a PWA everywhere.
And that kind of ambiguity is why you need to be using a rigorous source like caniuse and not just looking at summary statements for this kind of information.
Right. Audio over BT just counts as audio, the BT permission means something mote like connect to and use arbitrary BT devices.
I didn’t actually mean to compare BT vs BT audio in my original post, I just picked an example every browser will let you do. I hadn’t considered the crossover until I saw your reply.
The whole point of PWAs is to provide cross platforms apps so if a feature isn't available on all/most platforms, I don't think it's fair to say that it's really usable at all in your PWA.
You should be delivering the best possible experience for the user based on what their device can do, not the lowest common denominator of some arbitrary set of features. Progressive enhancement, API detection, and polyfilling are all common strategies that can be used to mitigate almost all device differences.
> Progressive enhancement, API detection, and polyfilling are all common strategies that can be used to mitigate almost all device differences.
Keyword being "almost", and that in some cases if the platform doesn't support your feature, you're shit outta luck.
By far the thing that prevented PWAs from bigger uptake earlier was Apple dragging their feet on push notifications support on iOS. There was simply no workaround or polyfill for that at all, and the biggest use case for PWAs was supporting push. Apple finally released web push notification support last year on iOS but the app needs to have already been installed on the home screen (I think that part is good), and last I checked the "install to home screen" on iOS Safari was still a horrible user experience (the actions is hidden under the "share" menu, which makes no sense to me).
> By far the thing that prevented PWAs from bigger uptake earlier was Apple dragging their feet on push notifications support on iOS.
Is there any evidence that this moved the PWA needle at all, he said hopefully? I would've predicted no effect on PWA adoption.
> …last I checked the "install to home screen" on iOS Safari was still a horrible user experience (the actions is hidden under the "share" menu, which makes no sense to me).
For better or worse, it's how iOS users are trained to "do something" with the current web page. Keeping in mind that "PWA" is jargon that average users won't be familiar with, what would be easier than (1) tap Share, tap (2) Add to Home Screen?
Android allows the site to prompt the user to add it to their home screen, which it can do at a time when it makes sense. e.g. the user orders something, then the "add to home screen" pop-up appears and the user can accept with one tap, which they're likely to want to do because they anticipate wanting to check their order status.
This doesn't work for me. (Android 11, Motorola phone.)
If I add a PWA or shortcut to my Home Screen, it will quite quickly disappear silently. Especially if I use Chrome to do it. The Support community is at a loss to explain this and they're starting to send me nonsensical instructions, showing they are desperate to get rid of my embarrassing question.
Sadly this is caught up in the usual conflict of interests. As someone building a PWA I would love a quick and easy method to pop up an install dialogue for the user. Unfortunately as a user of Safari on iOS the last thing I want is for every single website I interact with to be popping install dialogues, and you just know that's going to be as prolific as the current bombardment of requests to subscribe to mailing lists, and on desktop enable push notifications the moment a web page is opened.
The "natural" UI place for that kind of begging would not be a pop-up, but the head end of the URL bar, where the domain certificate validity is shown. Usually that's also the place where the UI for revoking permissions that are already granted is launched. Assuming the best I suspect that this is already the future plan of browser makers: on both browsers I usr (android chrome and FF on the desktop) hair the begging pop-up point there already, perhaps this is not only done as a hint to the place where the permission can be revoked, but also as training wheels for a less annoying future where the pop-up is replaced with some simple notification state in that place?
As an iOS user, I would certainly not want websites
prompting me for things like that. But I probably also would not want a webshop as an app. That’s a good use for a plain website.
Companies that already have two copies of their app front-end team will certainly not jump at the first hunch that they might perhaps be substituted by a third line. It's a slow process. But five years from the watershed moment of Apple ending their web push boycott (announced 22, executed 23), I expect a noticeable trend. For now, it's probably just orgs that would start from zero with an app questioning the need for a pair of native apps who might pick PWA over faux-native (electron/tauri wrapping a web UI). And perhaps some who already did faux-native, keep their app-store presence but also offer a third variant of the same running unwrapped in regular browsers.
> what would be easier than (1) tap Share, tap (2) Add to Home Screen?
In what universe does "adding to home screen" have anything to do with sharing? It's completely nonsensical.
As others have noted, it would be trivially simple for browser makers to explicitly have something in the address bar or a pop-up that allows users to install.
> By far the thing that prevented PWAs from bigger uptake earlier was Apple dragging their feet on push notifications
For me, it was developers trying to push Android design language via PWAs. In others, it was what should have been a website being packaged as a PWA, which is just clunky. That combination made PWAs feel cheap compared to native apps or sites.
What website uses the Android design language? Every website wants to look different, to stand out. A design language can only exist if it's enforced by an app store.
What does a website packaged as a PWA mean? A PWA is a website.
> You should be delivering the best possible experience for the user based on what their device can do, not the lowest common denominator of some arbitrary set of features.
Technically that's what Progressive means in Progressive Web Apps. That the developer enables features for customers based on the browser API support on their device, inadvertently ending up with software that works differently on every person's device. You might not like it, but that's what peak Chromebook performance looks like.
Apple spent a huge amount of time and money getting Safari in line with PWA standards in the past few years. Your comment would make sense 3 years ago when it was completely unclear whether Apple will flinch.
"You mean to tell me there's this thing called the world wide web, where anyone can just host anything and all people need to access it is a few words typed into a program that runs on anything? They don't need to buy our proprietary iDevices?! They don't even need to pay us a yearly ransom to put their stuff onto our store?! But what if it's something we don't approve of? This is preposterous and I want it dead."
- Tim Apple, probably
I wonder what kind of preachy "we are so brave" excuse it will be this time now that they're finally forced to allow app sideloading by the EU and Japan.
I'm wondering why there isn't a calendar API available. I wanted to create a simple PWA to track upcoming events for my favorite sports. It would be convenient to sync these events with my phone's calendar. Currently, downloading .ical files isn't a sufficient solution because it requires accepting prompts for each event and doesn't allow for modifications (as I am aware).
I might be missing something here but thet "Calendar API" exists for a long time: CalDav.
You can have .ical for a whole Calendar, not only an (offline) event. The calendar can be synced with new events, through CalDav, when they are added to the calendar you shared. You would still have to accept the prompt once but that is it.
This should have big warnings on it. Some of these are not web standards; they are features implemented unilaterally by Google in Blink that have been explicitly rejected by both Mozilla and Apple on privacy and security grounds.
Take Web Bluetooth, for example:
Mozilla:
> This model is unsustainable and presents a significant risk to users and their devices.
> Here are some examples of features we have decided to not yet implement due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns
This is Microsoft’s Embrace, Extend, and Extinguish bullshit applied to the web platform by Google. Google keeps implementing these things despite all other major rendering engines rejecting them, convinces people that they are part of the web, resulting in sites like this, then people start asking why Firefox and Safari are “missing functionality”. These are not part of the web platform, they are Google APIs that have been explicitly rejected.
Thanks for putting it in context, the Bluetooth API has been a big source of frustration in my exploration of PWAs. So many simple setup apps wouldn't need to be native.
A cross platform Bluetooth API for the web would provide really easy PoC with MCUs.
No, they do not get access unless you allow it and explicitly selet a bluetooth device the page is allowed to connect to. The bluetooth dialog is handled entirely by the browser.
PWAs don't have one of the major downsides of Electron, which is bloat - you don't have to package the huge runtime yourself.
That aside, sure, I'll always take a native app if I can have it. But providing native apps across all major desktop and mobile platforms is a lot of effort, especially for small businesses and hobbyists. In that case, a PWA is vastly better than nothing at all, or a native app for one particular platform that just happens to be the one you don't use.
Are you not saying that because you know webtech and not native? I find native easier, webtech with new frameworks and bundlers and fashion every two days is much more annoying to me.
Probably not. I've coded more for webtech, but have done native for Android (and Linux and Windows. And J2ME and Symbian FFS). Luckily very little iOS and MacOS apart from some reverse engineering.
You don't need frameworks or bundlers for simple cases. For many you need just one .html file.
For e.g. Android you need quite a bunch of files and directory structures to do even get a Hello world [1]. You need to compile and bundle and package. And install. And god knows what if you want the application distributed. And then you have to fight with the inconsistent and very boilerplatey Android APIs. And figure out which API was deprecated yesterday and what's today's one that will be deprecated tomorrow.
From what I gather, iOS native is even worse. E.g. have to buy a Mac and use MacOS. And Xcode. And faff with signing keys.
In my experience, Android-Studio creates the app for me. There are many files indeed, but that's nicely solved by the IDE. Then Kotlin is great, and I really like Jetpack Compose.
You can distribute your APK manually, but if you want it on the Play Store you have to jump through loops indeed. Though I don't think it's worse than running a webserver.
> And figure out which API was deprecated yesterday and what's today's one that will be deprecated tomorrow.
That's a bit exaggerated. I have been developing for Android for 10 years, and deprecations take years. There are deprecations, but I find that they are made in a controlled fashion.
> E.g. have to buy a Mac and use MacOS. And Xcode.
Yes, I am not a big fan of that. But many people are, so...
There are plenty of e.g. scaffolding tools to handle the bundlers and deployments etc for web frameworks if you are OK with IDE doing that.
I don't use IDEs or scaffolding tools if I can do without. I use many different languages and platforms, and for that just good old vim and terminal make juggling between them a lot easier.
I do understand that using the tool you know makes things (seem) simple. But it's the same for all tech.
The deprecations were exaggarated (along the tune of your two day). I haven't done Android native in a while, but e.g. the situation with Camera/Camera2/CameraX was quite bad.
> e.g. the situation with Camera/Camera2/CameraX was quite bad.
Yeah, I think overall it all converged a bit. Well Kotlin and Compose are big changes, but I can't really blame a change like that after more than a decade.
> But it's the same for all tech.
Yeah, I think we mostly agree. My opinion is just that I can switch between many languages and platforms, and native is always better integrated than anything cross-platform. Which makes for better apps and nicer development (I am happier learning Swift than debugging JS on the latest weird iOS-JS-framework with no community to help me).
IMO, if you write a simple app, then everything is simple. If you write a complex app, then native is better. As soon as it gets complex, nobody from the webtech community will know the details of the platform in question (unless they also do native dev on this platform). The native community for a specific platform is always bigger than the web community for it, in my experience.
Lots of comments below shooting from the hip and throwing warnings of security issues clearly without any practical knowledge of the current BT API. Someyimes, not saying anything is also an option.
No doubt, but Google probably could've worked with Mozilla and Apple to figure out an approach that addressed their concerns instead of disregarding them and implementing it as-is.
Maybe I remember it wrong, but I think Mozilla said it is unacceptable in any form and they will not even consider it. I don't like the google way either, but Mozilla is stubborn here and Apple fights for control over app market.
The "extinguish" is what happens after a substantial portion of the web is only accessible through Chrome. At some point it no longer makes sense to use a different web browser, and when we reach that point the open web is gone.
Isn't the idea of PWAs that you aren't doing it through Chrome, or not knowingly. You're just running an app, and Chrome (or Blink) is a library that the app can use?
It feels like too complex an example that would need to be constrained in various ways to make it apply. Simpler example: if you've used an Electron app e.g. VSCode, you've used Chrome under the hood.
> The "extinguish" is what happens after a substantial portion of the web is only accessible through Chrome. At some point it no longer makes sense to use a different web browser, and when we reach that point the open web is gone.
I'm saying how a PWA approach doesn't make people switch web browser, when they don't know it happens to be a Chrome library rendering their PWA?
You're still focused on the Bluetooth, but that's just one tiny part of a larger pattern of Google ignoring the rest of the vendors and doing what they want. The death of the web, if it occurs, will be death by a thousand cuts.
I used to have this view until I wanted to build a PWA that communicated with a cash register drawer and found only Chrome supports WebSerial (although others are positive on it).
It may be possible on WebUSB but WebSerial is the perfect match for what I need.
On a purely technical level the main thing stopping PWA adoption is the JS front end universe being addicted to front end frameworks which destroy the UX of websites and PWAs, but there is a key value add with app stores which PWAs will never have: trust, and much as the Apple haters will hate it it is much stronger on the iOS App Store because of the very things they hate about it.
Chrome, for all of Google's sins, is a modern miracle of software engineering. Safari is nothing like as far off as people make out either.
The front end framework mess is just a symptom of the actual problem, which is that the building blocks provided by browsers are too crude/limited to allow for consistent quality, and so Rube Goldberg machine frameworks arise to try to paper it all over.
I think browsers can be a good platform but for that to happen they need to be a bit more batteries-included, with built in APIs for UI and other essentials that rival those of desktop platforms so crazy frameworks are rendered unnecessary.
Honestly, I believe you have this backwards; the problem with browsers is they are too flexible and complicated. If you delivered a consistent MVC framework in the style of the classic NeXT APIs the major complaint would be the imposed look and feel, which from the point-of-view of a user is a feature, but for whatever reason people are drawn like moths to a flame towards that which is at the edge of reasonably possible and so devs and designers will forever be pushing at the limits until this state of chaos recurs.
It depends on what part of browsers are being spoken about. They’re plenty flexible and capable for the case of traditional pages and server-side apps, but it’s a totally different story for interactive widgets and especially full blown SPA’s.
For example, browsers don’t furnish a tableview/datagrid or even a basic single column recycler view, meaning one has to find a third party library to do those things that’s still maintained, fits into your stack, and has holes in functionality that are tolerable for the use case in question, or if none meet those criteria write it themselves. The result is a million reimplementations of the same thing nearly all of which have major shortcomings (some of which are present only because they aren’t implemented as a native browser control).
I totally get that styling is a pivotal part of web apps but I think that can be maintained without requiring devs to build castles from grains of sand instead of giving them more appropriate building materials to use.
Goes back to static vs. dynamic/interactive. That’s fine for static content but falls apart when you need a table view that can be edited, sorted, reordered, can have columns resized/rearranged, and can contain thousands of rows (necessitating recycling of table row DOM elements to maintain performance and efficiency).
This sort of view has been table stakes for desktop UI frameworks for decades and is a common need.
The big question is how the table gets populated with the data and enables things like column based sorting all executed on the client side. (With the associated interactions with scrolling).
The point of recycling views is as row UI elements scroll off the top they are reused for those appearing at the bottom (or vice versa) which reduces system resources for these things a lot. This way the data table can contain 20 million rows but if the user can only see 100 the UI only pays the cost for 100.
This is standard practice in native app dev and I think is a good example for the case they are making. I would argue such a thing would be needed in the hypothetical NeXT type API of course.
> On a purely technical level the main thing stopping PWA adoption is the JS front end universe being addicted to front end frameworks which destroy the UX of websites and PWAs
I would hesitate to conflate PWA adoption with JS framework popularity olympics. On a purely technical level, the only thing stopping you from using a PWA is you.
Perhaps you should reconsider your product and business model if it doesn't work without App Store presence. The App Store cannot sell your product for you. At some point you will need to interact with your actual customers if you want to succeed.
Having an app "in the store" does not equate to trust for me.
> Having an app "in the store" does not equate to trust for me.
It's not about you, but the users. iOS users do trust Apple as a proxy in the App Store and consequently spend much more there than even Android users do in the Play Store (on a per user basis).
The great anomaly to this used to be Amazon where Kindle Fire users used to have even higher ARPUs than iOS, but I've been out of the loop too long to know if this is still the case.
Not too long ago I decided to push the limits to see what web apps can do now and did https://luduxia.com/reversi/ - there are no UI libs here, the whole thing bundles in under a second with esbuild, and it runs perfectly on iOS Safari.
"On a purely technical level the main thing stopping PWA adoption"
I rather think, the main thing stopping PWA are that browsers still can not decide how to treat them. In some ways you can just do anything unrestricted and in other areas your PWA gets treated and limited like a random untrusted website, with no way to get needed rights. At least that was my experience last time I messed with it.
It is of course a problem to do it right, as prompts for confirmation just gets clicked away, but there should be a way to get real user consent for a proper app, that people trust.
But Apple for example wants to keep their app store under their control, so they surely won't provide an easy way to bypass the normal app store by giving developers a way to ship full apps just through the browser.
Not on the list of Apple's priorities I guess. If you have an app, you can include a meta tag on your web page and Safari will show users an Get from app-store banner at the top of the page.
(https://developer.apple.com/documentation/webkit/promoting_a...)
Would it be nice if they did that for PWAs.
Absolutely nobody expects to find installation options under layers of indirection in a share menu.
It’s an intentional choice by Apple that’s hostile to users but very aligned with their strategy to lock users into their own proprietary platform as much as possible.
What do you think the process should be? There are only five buttons on screen, should one of them be permanently dedicated to adding a webpage/PWA to your home screen?
For the record they are the back, forward, share, history/bookmarks, and tabs buttons.
As I explained in another reply, I don’t think Apple is being malicious here. I think they just shove everything that’s not a very common use in there.
I’d be much more inclined to believe that analysis if we were to look at this as a single thing but the moment you look at the consistency of their decisions that they have made regarding the web as a platform it’s close to impossible to impartially come to that same conclusion.
Not really. Not for non-tech savvy users. Try it on an iPhone. First you'll have to find the share button on the browser bar, then scroll down and find the option 'Add to home screen'. I don't think its very obvious.
Most users don't know about it, and need a how-to guide - similar to what the posted link does.
The "share" button is massively overloaded on iOS and has been for ages. It does a bunch of stuff that isn't really related to sharing in any reasonable sense of the word. It's really IMO one of the worst UI elements in what overall is a pretty nice and consistent system
I like this website. I tap on the share button. That lets me do a bunch of things I can do with websites I like, like sharing them or bookmarking them or pinning them to the homescreen.
Perhaps I should have chosen my words more carefully. The obstacle is that its not intuitive that you can install/save this PWA to my home screen via the Share Button. Someone is going to have to tell you the first time. If you open the original link on an iPhone, and click the "Install to Home Screen" button, it'll show you a popup with screenshots and instructions. The user will have to be somewhat determined to install the PWA.
As opposed to an obvious button that says click me to install/download. (The usual Get it on the Appstore buttons), or Smart Banners[1]. The banner/button makes it crystal clear that I can click it to install the app. (Yes, you are correct you may need additional clicks to actually install, but by that time, you are in a familiar workflow).
The only thing holding me back from using PWA's right now is tabbed mode [1].
Browser tabs are so useful and having them open in new windows or in the system browser is a bad experience.
Not sure why this is taking so long, there have been prototypes for years. Not like its even a security question just bringing over a UI that already exists in the browser.
Tabbed isnt enough for me. I don't want an app. I want a website. I want my user-agent! My user agent is what I know, affords me URLs & extensions and a powerful UI with lots of options.
The PWA thing seems sick to me. Henry Ford listens to market research and rebuilds his car as a mechanized horse. For me, the UX is strictly worse in every way. (And I already knew how to put links to webpages on my home screens).
There does seem to be a browser display mode, but it's up to the app maker to decide for the user what mode the app will be in. Why?!
> Progressive Web Apps can run in various display modes determined by the display property in the web app manifest. Examples are fullscreen, standalone, minimal-ui, and browser.
It makes me so sad how much lesser a person a user of a PWA is. The utter lack of user agent, being cast to whatever is provided by the maker, is a horrifying loss. All to ape what felt to me like the descending losing old-guard technologies.
I assume I'm being down voted by pro-native people for calling their preferred tech descending losing old-guard technologies.
Does anyone actually have any comments or reactions to what I was actually arguing about?
PWAs being such brutal downgrade over what the web browser offers seems glaringly obvious to me; I'm shocked there's not more outcry. If people actually feel otherwise, please leave some arguments out in support of blowing away the user agent.
This feels like it always has been the nexus of power where the web gets consistent enriching capabilities and affordances. It's what has made the web powerful & better, rather than every user being cast naked &bat the mercies into whatever app a company decides to cook up.
There's a submission right now on The Eight Golden Rules of Interface Design & the browser alone satisfies 6 or 7 of these, by my judgement, whereas native & PWA apps require the app to carefully construct it's own paradigm that can fully meet these user needs. The user agent is a helpful baseline, and it seems mad that PWAs throw it away to me. https://news.ycombinator.com/item?id=38916663https://www.cs.umd.edu/~ben/goldenrules.html
If people think PWAs offer anything or make any sense versus the web browser, I'd love to hear why. Tabbed design was sooo late relatively to emerge in PWA space, and it feels like just one of a million affordances that are going to be half baked recreations of what we already had in the browser. How is being an app in an OS better than being a tab in a much more powerful & competent & featureful user-agent?
Call me back when PWAs can be registered as share targets on iOS (i.e. it appears as an app on the share sheet when you click "share" on a web page). I really want the ability to bookmark sites I browse on my phone and save it to a self-hosted web application.
This may yet turn into a web standard given more work, but please don’t hold up a Google spec. implemented only by Google as if it were a part of the web platform that Apple are late in implementing.
The only relevant browsers on mobile are google's and apple's, and (modern) web standards are created by enough popular browsers implementing them. Literally all it would take for this to be a reliable web standard would be apple choosing to implement it.
You can apply that logic to literally anything Google thinks up. Google writes something in a spec and no matter how stupid, insecure, or privacy violating it is, by this logic Apple is now falling behind and holding the web back because all it would take to make it a standard is for Apple to do what Google wants. Why are you so keen to hand the web platform entirely over to Google?
Web Share Target API isn't a good experience on Android either.
Partly because it only works if the user visits your site with Chrome for Android (even Chromium browsers don't work).
And partly because receiving a share unrecoverably takes over whatever the user is doing. If the user opens something from your PWA (an external link, another app) and then shares back into your PWA, whatever they were looking at gets killed and your PWA navigates to the share target.
I'm building a web app built around sharing and I'm going to have to wrap it in an Android app solely to get around this.
If you just want something for yourself, you can set that up with a Shortcut and the "Get contents of url" action. You can then configure the shortcut to be available in the Share page so you could then easily share links/whatever to your self hosted app
We push PWAs to iPads & Surface Go devices via Microsoft InTune for some of our clients today.
This path started out very nightmarish (circa 2020) but it's going much smoother today. One of our customers actually came back to us with a slightly improved process based upon the one we gave them. They switched from iPad to Surface Go and used some extra endpoint management to make the PWA experience into a sort of kiosk mode.
The #1 constraint for us is the quality of the environment-facing camera and the level of access we have to its capabilities via the browser. iOS/Safari started out extremely weak on this but is quite good today. I can get a solid 2k environment scan at 30fps from the rear facing iPad camera in Safari today. Things like 2D barcode scan and document capture are 100% feasible now. These items used to make us extremely nervous on product demos but we don't worry anymore.
We almost capitulated and went back to native iOS apps because of the camera issues, but the pain of maintaining a native build chain when you are otherwise a 100% Microsoft shop (with barely 3 developers) was pushing back hard too. We were signing enterprise IPAs for all of our clients for half a decade before we switched to web/PWA. I will never go back to native apps. I'll find a different career path and hobbies if the web goes away.
I don't have a clean answer for B2C other than... I use HN and Twitter in Safari and I don't even process that it's not a native app. Neither of these web properties had to spend a single second worrying about a native app to acquire my business.
Safari doesn't support that API whatsoever so a third party JS library is really your only option. The landscape of open source barcode detection libraries is bleak at the moment.
It does since iOS 17. For now you’ll have to enable it manually through Settings > Safari > Advanced > Feature Flags > Shape Detection API but I expect it to be enabled by default soon.
This is another Google-authored specification, implemented only by Google, which is not currently a web standard. It’s not just Safari that doesn’t support it; Firefox doesn’t either. It’s a Blink-only API.
> Editors:
> Miguel Casas-Sanchez (Google LLC)
> Reilly Grant (Google LLC)
> Status of this document
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
Media constraints are the #1 reason it won't scan in my experience. You need at least ~1000px horizontal to reliably decode PDF417. If the resolution is 720p or lower, you aren't capturing enough information for a decode.
> Scanning 2D barcodes only works reliable on smartphones
We wont even fully certify iPhones for use with this solution because we have seen consistent failure to autofocus on the barcode for "some weird reason". iPads work like magic though. I have to go out of my way to not get a quick scan on recent generation iPad camera.
We went down the hardware scanning path w/ keyboard emulation in the browser, but its kind of clunky when you are considering the overall solution stack in a B2B setting.
If you’re open to using a commercial solution then there is a WebSDK offered by Scandit - https://www.scandit.com/products/web-sdk/ - full disclosure, I manage their website, however I thought this maybe of interest.
As a Microsoft shop: Any experience with Blazor and PWA? I find Blazor very awesome for developing an App using WebAssembly. When using it as a PWA and caching the .NET runtime locally etc, the combination of productivity and ease of deployment could be theoretically really awesome.
Built an application using strictly Blazor wasm for my last assignment (so .Net 7).
It wasn't a easy ride (especially when it comes to LSP support for razor pages). But the overall experience was pretty decent.
Almost half of our users preferred to use the application as a PWA (using windows 10 and edge) instead of an ordinary tab in your browser.
Somethings to consider tho:
Upgrades to service workers and what not can be a bit challenging depending on your situation.
Keep in mind that a lot of firewalls and antivituses may block all those binary downloads (since it's just dll files). There are ways around it ofc, but still expect files to be blocked.
Authorization changed between .net 7 and 8. So make sure you understand what these changes are (if you use packages from Microsoft)
Yes. Tons with server-side Blazor apps. We currently use Blazor for our internal admin UIs, but at this point I'd never put it in something customer facing (even in B2B setting).
We haven't played with the client-side WASM stuff, but the conclusion is that server-side blazor is not a fantastic technology if you want something that "just works". Websockets in particular are kind of nasty when you have a client device ecosystem where screens and apps are frequently changing activity state. Stateless forms are much easier to reason about. iOS/Safari is very aggressive with closing down unused resources. Stateless forms can survive for days on those user agents. Our blazor apps would require refreshes after a few minutes of inactivity.
Vanilla web forms & SSR is what we run with today. Our "framework" is to use string verbatim & interpolation operators in C# to compose our responses. Looks something like PHP and has zero dependencies.
Personally I am in love with Avalonia UI for client-side because it just feels like WPF/Silverlight done right. I can use all my WPF knowledge to develop cross-platform PWA apps. It's the shit.
I see there are a few features not available on my phone (iPhone 15 Pro Max). If possible it would be great if the feature icons could turn grey if they aren’t supported on the current device
I think we have to get used to it, it's the new engineering way. "I see potential profit with blockchain, let's rush and do whatever quick project I can imagine with blockchain". "I see potential with AI, let's rush and do the same with AI".
It's not important to make a good product anymore: you need to be the first or the luckiest. Good products don't win because they are drowned in all the crap. And AI will soon make it infinitely easier to generate more crap.
I dislike that when you install a PWA it is browser specific. For example, if I use Chrome, the installed app will only open in Chrome. Use Firefox on Android and it overlays a Firefox icon on the installed app icon.
PWAs to me sound like "we want everyone to use the same OS (in this case something like ChromeOS), because that's more productive for us".
I get that Google pushes for PWAs because that's how they conquer the OS world. But why do individuals push for that? Because they don't know anything other than webtech and don't want to learn? Have a look at Kotlin and Swift guys, it's kinda cool!
Are you using Windows? I am happy that the people who contributed Linux/BSD/Android/iOS did not have your mentality, otherwise I would be forced to use Windows everywhere.
I'm on Fedora. Of course, there has to be a native UI, but I'm running a two-person company for example. How on earth are we supposed to manage three or more platforms (browser, Android, iOS)?
We're not lazy but limited by our mortality.
> Because they don't know anything other than webtech and don't want to learn?
> How on earth are we supposed to manage three or more platforms (browser, Android, iOS)?
Are you sure you need three or more platforms? In my experience, when I ask small companies what they need, they say "everything". If I listen to them, they even need to run on a Gameboy. Then most startups fail, so apparently the problem was not the number of platforms.
It feels like many times, selecting the platforms may be fine.
In our case, it's a SaaS (pirsch.io) and browser first. But people and I like having an icon on our phones that we can click to open a dashboard quickly. Of course, this could just be a regular link, but it saves resources because PWAs will cache files (2 MB or something JS bundles for example).
"Cool" is not a great reason. Only having to develop something once that serves all users is great, though. Personally, I cannot stand apps, I only use them when absolutely required, using a PWA gets you all the security of the browser (relatively speaking, but it's a lot more secure than a from scratch black box, and look at goon moves like Facebook embedding a browser that retains third party site interactions) and as a developer and user I can use my own extensions and general browser features.
> Only having to develop something once that serves all users is great, though.
Cross-platform usually sucks in some way. If the app is not worse, the development is: "write once, debug everywhere".
Web is solving that by forcing everybody to use the same (Google-controlled) renderer, so that there is no need for cross-platform anymore: just use the Google thing. I don't want that.
Debug everywhere or google controlled, those things seem diametrically opposed. Aside from the murky area of cookies, chrome isn't straying much from web standards.
There's really not much reason to not use a browser, the compatibility issues are pretty much a thing of the past on any browser, unless you're doing something esoteric. Installing a special app should be unusual.
> Debug everywhere or google controlled, those things seem diametrically opposed.
That's what I said.
> the compatibility issues are pretty much a thing of the past on any browser
Because there is only one meaningful browser left: Chromium. It is not a solution to cross-platform, it is just pushing for a monopoly. Just like a few years ago you could have been advocating for supporting exclusively Internet Explorer: that solves the compatibility issues too.
Now PWAs are not trying to kill other browsers (it's done already), but other platforms. That's just the next step.
Internet Explorer did not follow web standards, Chrome does, pretty religiously. That's a huge difference. And Safari and Edge are gaining ground, Safari is not based on Chrome anymore and there are a number of open source browsers based on Chrome.
Well it was following the "IE standards". The difference is only rhetoric to avoid antitrust. Google dominates the standards. Edge is Chromium, Mozilla is maintained in survival mode by Google.
> Chrome does, pretty religiously
I wouldn't call it "religious" when Chrome follows stuff Google wants and Mozilla/Apple don't want.
> there are a number of open source browsers based on Chrome
Based on Chromium, you mean? That's still dominated by Google.
"IE standards" makes no sense. Yes the big companies dominate web standards, but there are still multiple viable niche browsers that work by conforming to that spec, and an extensive spec validation framework anyone can use (web-platform-tests). It's unreasonable to say someone could come up with an IE compatible browser since there's no promise or reality of a stable design.
But you're just putting yourself out on an increasingly brittle limb to defend native apps, which imo work against user interests.
> but there are still multiple viable niche browsers that work by conforming to that spec
Again, Chromium-based browsers don't count if their contribution to the codebase is marginal.
Then Google implements stuff that Apple and Mozilla disagree with, and devs still rely on it (e.g. web bluetooth). Not even mentioning that Mozilla is a joke kept alive by Google for antitrust reasons.
Firefox is still there. There is more than Chromium based browsers. Safari uses its own engine. Gnome, KDE have their own browsers with their own engines, there are text browsers, experimental browsers, etc. There could be a completely new browser next week that works with 99.9999% of web pages, thanks to web standards.
But even a Chromium based browser setting is better than some random app that could have been a web page.
The biggest reason, as I see it, is that the web is a free market, whereas on Android's and iOS's app stores you're beholden to Google's and Apple's taxes, restrictions and whims.
The second reason is the resources available. Going web first means your app is instantly available everywhere, even if not perfect.
We can learn Android and iOS development for sure, but how about both? And have you ever seen shops with the same developers targeting both iOS and Android with their native stacks? I haven't. Besides the web, you're limited in available options for reusing existing code and knowledge, such as React Native, and using cross-platform toolkits may be more risky than targeting the open web.
I guess that's the excuse, yes. But in my experience the native way is not necessarily more expensive. It's just faster to make a prototype in web, I suppose. And most apps end up being prototypes thrown into production nowadays.
So yeah: it's cheaper, not better, but that's enough to win.
No. We may speak about a hypothetical future, but right now, that's false. You don't need to pay the 30% tax on all sales, you don't need permission to publish a web app, you don't need to obey the rules for what's permissible in an app store, you don't go through a review process, you don't get your appeal judged by a kangaroo court. And while there are ways for Google to ban you from Search or flag your website in Chrome, a vast majority of cases had to do with legal censorship requests, copyright law, or blocking malware.
Google doesn't even have that much control because Chromium is FOSS, it already has contributors from companies with deep pockets, it can always be forked, which means Google has to play nice, like all FOSS stewards. Google has some control over the web, but their leeway is vastly overblown, and a bad rhetorical trick.
This isn't even a matter of perspective, and if smart, educated individuals can have disagreements on such clear issues, we are in trouble.
---
> But in my experience the native way is not necessarily more expensive.
We don't share the same experience. If you're speaking about personal projects displaying some simple forms, sure, but all the software companies I know hire separate Android, and separate iOS developers, tripling the frontend cost, with the minimum being one Android developer and one iOS developer. I have in mind companies big or small, start-ups or commercial FOSS even. The one exception I know used React Native, with an emphasis on iOS, the Android experience being terrible.
> all the software companies I know hire separate Android, and separate iOS developers, tripling the frontend cost
I think there is a mistake here, that management unfortunately systematically makes: writing one cross-platform app is not equivalent to writing one native app. The cost difference will depend a lot on the product. If your cross-platform devs spend double the time because they need to debug on the other platform they don't know so well, then... well it costs double the money.
Cross-platform never has the same kind of community for a specific platform. Android experts tend to write native Android apps, and so do iOS experts. My experience with cross-platform is that they are written by people who are experts on neither.
The mobile devs companies I know favor native apps, because in their experience it's not cheaper to use cross-platform frameworks, and the resulting apps are worse. Just like you seem to confirm:
> The one exception I know used React Native, with an emphasis on iOS, the Android experience being terrible.
The experience I have had in companies going cross-platform is that the employees they hire are not mobile devs, the app doesn't feel native at all, the debugging experience is terrible, and overall they struggle a lot. The only advantage I have seen (again, in my experience) with cross-platform frameworks is my "I told you so" moment with management, where whenever they complain about something I can say: "well you wanted cross-platform because you thought it was a fraction of the price, now you live with your choice". Hint: usually they don't like it.
How typical of PWAs that even a demonstration site, which should demonstrate the best that PWAs can be, has a glaring UX bug on iOS.
Namely: if you swipe from the sides of the screen to go back/forward, you get a duplicate animation. If you swipe back from B to A, once the native (interactive) slide animation finishes, the page then jumps back to B and then does another (noninteractive) slide animation to A.
Fixing this would be as simple as disabling the page's slide animation, but whoever made this site didn't notice or didn't bother.
Apple does have some blame here. Disabling the page's slide animation wouldn't be a perfect solution since it wouldn't distinguish slide gestures from other ways to go back/forward (which ideally would still show an animation), like using the browser's back/forward buttons if accessing the site in a browser rather than as an app, or using a keyboard shortcut with an external keyboard. I don't think it's possible to easily detect which kind of gesture triggered navigation (in order to conditionally show the animation).
Another option would be to disable the native slide gesture entirely in favor of a fully JS-based one. In the past it wasn't even possible to disable it, but that has been fixed for years now [1]. However, it's hard to exactly replicate the native behavior.
Ideally there would be a more purpose-built interface to detect and customize the native swipe gesture.
Yes! And the visuals are horrific too, just look at that tabbar. If anything, it’s a showcase of just how hard it’s gonna be to build a good app this way.
Native widgets and UI elements, native navigation functionality. Web apps get worse the more they try and pretend to be native apps and implement things like their own scrolling, or their own back/forwards navigation.
284 comments
[ 4.3 ms ] story [ 260 ms ] threadMove on folks, nothing more to see here. PWAs are just another Google side project, talking about them in 2024 is like still being hung up on a chat app Google killed years ago or being that guy who did his whole house up in Material Design.
It's a good idea and frankly superior to the current Store+PhoneApp approach to making stateful apps that can run on mobile devices. Contributing helps. Being sour, not so much.
[1] https://learn.microsoft.com/en-us/microsoft-edge/progressive...
Firefox supports both add to home screen and push notifications.
Or by “add to home screen”, are you specifically referring to BeforeInstallPromptEvent / prompt()? That isn’t a web standard. It’s something Google alone have implemented, it’s a Chrome-only feature. Firefox hasn’t implemented it either.
> Status of This Document
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
https://wicg.github.io/manifest-incubations/
PWAs would also open the doors to new mobile OSs beyond Google or apple control.
It's the "progressive" part I have a problem with. Web apps revolutionized our idea of what an application can do; everything in PWA makes web applications worse, not better.
Just to take a simple example, when I want to visit Hacker news I just type n in the address bar of my iPad and click on the auto-suggest result and I am there.
If I had an app for it, it would compete with all the other apps that have a burnt umber orange icon or that have an "H", an "N" or a "Y" as their own logo. (McDonald's might be the only brand that can pull that off) If I had an app for that I'd also be installing lots of other apps and have 4 or 5 pages of them to scroll through. If anything, brands should be asking for ways to make installed apps as easy to find as uninstalled web pages are.
(Note all the things I complained about originally except the lack of a reliable storage facility, are problems with apps. What makes it a 'side project' is that PWA advocates keep denying that "it just doesn't work" and then act incredulous that nobody wants to waste time with them.)
If anything, most app authors should just quit drinking the Kool-Aid and just make plain ordinary web applications without any of the PWA power-downs. It's like playing a Mario game and finding some mushroom that makes you smaller without any benefit (like being able to go in some hole.)
I don't know... laws?
> PWAs would also open the doors to new mobile OSs beyond Google or apple control.
Or force everyone into ChromeOS once and for all.
Maybe. I am not impressed so far, though.
>Or force everyone into ChromeOS once and for all.
I don't see that happening on iOS.
How does that work?
From my [fairly-out-of-the-loop-for-the-past-few-years] vantage point, Mozilla’s been a lot less invested in the PWA ecosystem since they abandoned their Firefox Phone / Boot2Gecko initiative, which was intended to create a middle tier between the expensive smartphones of the early 2010’s and ubiquitous and cheap feature phones (flip phones, classic Nokia candy bars), and expand access to the web across the world with it.
All the apps were PWAs, which made it simple to build out. Eventually Mozilla stopped the project, but KaiOS became a commercial implementation and it still runs on a fair number of feature phones to this day.
But without that pressure for PWA support in Firefox as a critical mobile feature, it was largely serving as an expensive bookmark launcher in the Firefox code base so that folks could alt-tab to the small number of sites that supported it on their desktops. Not a noble end for Mozilla’s support for what should have been / could have been an incredible leverage point for the web ecosystem and open development.
I think most in-house devs would rather not deal with the app store or the vagaries of getting the MDM side loading pathway working
When I came back to Web/Distributed Systems after my stint dealing with Windows desktop, all the applications I have been involved only had Web frontends, including for mobile devices, not Web views, the actual browser.
They managed perfectly fine.
For subscription app may be, but all ads revenue websites will reject it.
I reject them
I cannot tolerate apps with ads
And that kind of ambiguity is why you need to be using a rigorous source like caniuse and not just looking at summary statements for this kind of information.
I didn’t actually mean to compare BT vs BT audio in my original post, I just picked an example every browser will let you do. I hadn’t considered the crossover until I saw your reply.
You should be delivering the best possible experience for the user based on what their device can do, not the lowest common denominator of some arbitrary set of features. Progressive enhancement, API detection, and polyfilling are all common strategies that can be used to mitigate almost all device differences.
Keyword being "almost", and that in some cases if the platform doesn't support your feature, you're shit outta luck.
By far the thing that prevented PWAs from bigger uptake earlier was Apple dragging their feet on push notifications support on iOS. There was simply no workaround or polyfill for that at all, and the biggest use case for PWAs was supporting push. Apple finally released web push notification support last year on iOS but the app needs to have already been installed on the home screen (I think that part is good), and last I checked the "install to home screen" on iOS Safari was still a horrible user experience (the actions is hidden under the "share" menu, which makes no sense to me).
Is there any evidence that this moved the PWA needle at all, he said hopefully? I would've predicted no effect on PWA adoption.
> …last I checked the "install to home screen" on iOS Safari was still a horrible user experience (the actions is hidden under the "share" menu, which makes no sense to me).
For better or worse, it's how iOS users are trained to "do something" with the current web page. Keeping in mind that "PWA" is jargon that average users won't be familiar with, what would be easier than (1) tap Share, tap (2) Add to Home Screen?
If I add a PWA or shortcut to my Home Screen, it will quite quickly disappear silently. Especially if I use Chrome to do it. The Support community is at a loss to explain this and they're starting to send me nonsensical instructions, showing they are desperate to get rid of my embarrassing question.
In what universe does "adding to home screen" have anything to do with sharing? It's completely nonsensical.
As others have noted, it would be trivially simple for browser makers to explicitly have something in the address bar or a pop-up that allows users to install.
For me, it was developers trying to push Android design language via PWAs. In others, it was what should have been a website being packaged as a PWA, which is just clunky. That combination made PWAs feel cheap compared to native apps or sites.
What does a website packaged as a PWA mean? A PWA is a website.
So the exact opposite of PWAs.
Apple laughs at your universal support.
They have tried to hobble the web as a platform for fairly obvious reasons for as long as they could.
They don’t deserve any credit for whatever progress they made, it was done unwillingly at gunpoint.
- Tim Apple, probably
I wonder what kind of preachy "we are so brave" excuse it will be this time now that they're finally forced to allow app sideloading by the EU and Japan.
You can have .ical for a whole Calendar, not only an (offline) event. The calendar can be synced with new events, through CalDav, when they are added to the calendar you shared. You would still have to accept the prompt once but that is it.
Take Web Bluetooth, for example:
Mozilla:
> This model is unsustainable and presents a significant risk to users and their devices.
— https://mozilla.github.io/standards-positions/#web-bluetooth
Apple:
> Here are some examples of features we have decided to not yet implement due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns
— https://webkit.org/tracking-prevention/
This is Microsoft’s Embrace, Extend, and Extinguish bullshit applied to the web platform by Google. Google keeps implementing these things despite all other major rendering engines rejecting them, convinces people that they are part of the web, resulting in sites like this, then people start asking why Firefox and Safari are “missing functionality”. These are not part of the web platform, they are Google APIs that have been explicitly rejected.
The gatekeeping/FUD/wringing-of-pewrls over this seems absurd, cruel, and most of all arbitrary to me. Insubstantial naysaying.
That aside, sure, I'll always take a native app if I can have it. But providing native apps across all major desktop and mobile platforms is a lot of effort, especially for small businesses and hobbyists. In that case, a PWA is vastly better than nothing at all, or a native app for one particular platform that just happens to be the one you don't use.
If they are simple, why not making them native?
You don't need frameworks or bundlers for simple cases. For many you need just one .html file.
For e.g. Android you need quite a bunch of files and directory structures to do even get a Hello world [1]. You need to compile and bundle and package. And install. And god knows what if you want the application distributed. And then you have to fight with the inconsistent and very boilerplatey Android APIs. And figure out which API was deprecated yesterday and what's today's one that will be deprecated tomorrow.
From what I gather, iOS native is even worse. E.g. have to buy a Mac and use MacOS. And Xcode. And faff with signing keys.
[1] https://github.com/IanDarwin/AndroidTemplate
You can distribute your APK manually, but if you want it on the Play Store you have to jump through loops indeed. Though I don't think it's worse than running a webserver.
> And figure out which API was deprecated yesterday and what's today's one that will be deprecated tomorrow.
That's a bit exaggerated. I have been developing for Android for 10 years, and deprecations take years. There are deprecations, but I find that they are made in a controlled fashion.
> E.g. have to buy a Mac and use MacOS. And Xcode.
Yes, I am not a big fan of that. But many people are, so...
I don't use IDEs or scaffolding tools if I can do without. I use many different languages and platforms, and for that just good old vim and terminal make juggling between them a lot easier.
I do understand that using the tool you know makes things (seem) simple. But it's the same for all tech.
The deprecations were exaggarated (along the tune of your two day). I haven't done Android native in a while, but e.g. the situation with Camera/Camera2/CameraX was quite bad.
Yeah, I think overall it all converged a bit. Well Kotlin and Compose are big changes, but I can't really blame a change like that after more than a decade.
> But it's the same for all tech.
Yeah, I think we mostly agree. My opinion is just that I can switch between many languages and platforms, and native is always better integrated than anything cross-platform. Which makes for better apps and nicer development (I am happier learning Swift than debugging JS on the latest weird iOS-JS-framework with no community to help me).
IMO, if you write a simple app, then everything is simple. If you write a complex app, then native is better. As soon as it gets complex, nobody from the webtech community will know the details of the platform in question (unless they also do native dev on this platform). The native community for a specific platform is always bigger than the web community for it, in my experience.
Web BT permissions can be disabled if not needed. I reject Mozilla's and Apple's reasoning.
That's a big difference. What if I sold you a Linux computer that was actually running Windows with a UI that looks like Linux?
I use the JetBrains IDEs, made for the JVM.
> The "extinguish" is what happens after a substantial portion of the web is only accessible through Chrome. At some point it no longer makes sense to use a different web browser, and when we reach that point the open web is gone.
I'm saying how a PWA approach doesn't make people switch web browser, when they don't know it happens to be a Chrome library rendering their PWA?
It may be possible on WebUSB but WebSerial is the perfect match for what I need.
Chrome, for all of Google's sins, is a modern miracle of software engineering. Safari is nothing like as far off as people make out either.
I think browsers can be a good platform but for that to happen they need to be a bit more batteries-included, with built in APIs for UI and other essentials that rival those of desktop platforms so crazy frameworks are rendered unnecessary.
For example, browsers don’t furnish a tableview/datagrid or even a basic single column recycler view, meaning one has to find a third party library to do those things that’s still maintained, fits into your stack, and has holes in functionality that are tolerable for the use case in question, or if none meet those criteria write it themselves. The result is a million reimplementations of the same thing nearly all of which have major shortcomings (some of which are present only because they aren’t implemented as a native browser control).
I totally get that styling is a pivotal part of web apps but I think that can be maintained without requiring devs to build castles from grains of sand instead of giving them more appropriate building materials to use.
<table> and <ol>? Or am I missing something?
This sort of view has been table stakes for desktop UI frameworks for decades and is a common need.
The point of recycling views is as row UI elements scroll off the top they are reused for those appearing at the bottom (or vice versa) which reduces system resources for these things a lot. This way the data table can contain 20 million rows but if the user can only see 100 the UI only pays the cost for 100.
This is standard practice in native app dev and I think is a good example for the case they are making. I would argue such a thing would be needed in the hypothetical NeXT type API of course.
I would hesitate to conflate PWA adoption with JS framework popularity olympics. On a purely technical level, the only thing stopping you from using a PWA is you.
Perhaps you should reconsider your product and business model if it doesn't work without App Store presence. The App Store cannot sell your product for you. At some point you will need to interact with your actual customers if you want to succeed.
Having an app "in the store" does not equate to trust for me.
It's not about you, but the users. iOS users do trust Apple as a proxy in the App Store and consequently spend much more there than even Android users do in the Play Store (on a per user basis).
The great anomaly to this used to be Amazon where Kindle Fire users used to have even higher ARPUs than iOS, but I've been out of the loop too long to know if this is still the case.
Not too long ago I decided to push the limits to see what web apps can do now and did https://luduxia.com/reversi/ - there are no UI libs here, the whole thing bundles in under a second with esbuild, and it runs perfectly on iOS Safari.
I rather think, the main thing stopping PWA are that browsers still can not decide how to treat them. In some ways you can just do anything unrestricted and in other areas your PWA gets treated and limited like a random untrusted website, with no way to get needed rights. At least that was my experience last time I messed with it.
It is of course a problem to do it right, as prompts for confirmation just gets clicked away, but there should be a way to get real user consent for a proper app, that people trust.
But Apple for example wants to keep their app store under their control, so they surely won't provide an easy way to bypass the normal app store by giving developers a way to ship full apps just through the browser.
That’s it. It’s not complicated or restricted in any way.
Adding bookmarks, finding on the page, printing, triggering extension actions/scripts… it’s a junk drawer.
It’s not hard to explain to users at least. It certainly could’ve been much worse. Not high praise but it is what it is.
It’s an intentional choice by Apple that’s hostile to users but very aligned with their strategy to lock users into their own proprietary platform as much as possible.
For the record they are the back, forward, share, history/bookmarks, and tabs buttons.
As I explained in another reply, I don’t think Apple is being malicious here. I think they just shove everything that’s not a very common use in there.
Most users don't know about it, and need a how-to guide - similar to what the posted link does.
As opposed to an obvious button that says click me to install/download. (The usual Get it on the Appstore buttons), or Smart Banners[1]. The banner/button makes it crystal clear that I can click it to install the app. (Yes, you are correct you may need additional clicks to actually install, but by that time, you are in a familiar workflow).
1. https://developer.apple.com/documentation/webkit/promoting_a...
Browser tabs are so useful and having them open in new windows or in the system browser is a bad experience.
Not sure why this is taking so long, there have been prototypes for years. Not like its even a security question just bringing over a UI that already exists in the browser.
https://developer.chrome.com/docs/capabilities/tabbed-applic...
The PWA thing seems sick to me. Henry Ford listens to market research and rebuilds his car as a mechanized horse. For me, the UX is strictly worse in every way. (And I already knew how to put links to webpages on my home screens).
There does seem to be a browser display mode, but it's up to the app maker to decide for the user what mode the app will be in. Why?!
> Progressive Web Apps can run in various display modes determined by the display property in the web app manifest. Examples are fullscreen, standalone, minimal-ui, and browser.
It makes me so sad how much lesser a person a user of a PWA is. The utter lack of user agent, being cast to whatever is provided by the maker, is a horrifying loss. All to ape what felt to me like the descending losing old-guard technologies.
Does anyone actually have any comments or reactions to what I was actually arguing about?
PWAs being such brutal downgrade over what the web browser offers seems glaringly obvious to me; I'm shocked there's not more outcry. If people actually feel otherwise, please leave some arguments out in support of blowing away the user agent.
This feels like it always has been the nexus of power where the web gets consistent enriching capabilities and affordances. It's what has made the web powerful & better, rather than every user being cast naked &bat the mercies into whatever app a company decides to cook up.
There's a submission right now on The Eight Golden Rules of Interface Design & the browser alone satisfies 6 or 7 of these, by my judgement, whereas native & PWA apps require the app to carefully construct it's own paradigm that can fully meet these user needs. The user agent is a helpful baseline, and it seems mad that PWAs throw it away to me. https://news.ycombinator.com/item?id=38916663 https://www.cs.umd.edu/~ben/goldenrules.html
If people think PWAs offer anything or make any sense versus the web browser, I'd love to hear why. Tabbed design was sooo late relatively to emerge in PWA space, and it feels like just one of a million affordances that are going to be half baked recreations of what we already had in the browser. How is being an app in an OS better than being a tab in a much more powerful & competent & featureful user-agent?
But some websites really are apps, and browser-oriented chrome just gets in the way.
> Editors:
> Matt Giuca (Google Inc.)
> Eric Willigers (Google Inc.)
> Status of This Document
> This specification was published by the Web Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track
— https://w3c.github.io/web-share-target/level-2/
Firefox doesn’t implement it either: https://bugzilla.mozilla.org/show_bug.cgi?id=1476515
Apple raised a concern about spoofing which seems to have gone unaddressed by the spec authors in over a year: https://github.com/w3c/web-share-target/issues/109
This may yet turn into a web standard given more work, but please don’t hold up a Google spec. implemented only by Google as if it were a part of the web platform that Apple are late in implementing.
Partly because it only works if the user visits your site with Chrome for Android (even Chromium browsers don't work).
And partly because receiving a share unrecoverably takes over whatever the user is doing. If the user opens something from your PWA (an external link, another app) and then shares back into your PWA, whatever they were looking at gets killed and your PWA navigates to the share target.
I'm building a web app built around sharing and I'm going to have to wrap it in an Android app solely to get around this.
This path started out very nightmarish (circa 2020) but it's going much smoother today. One of our customers actually came back to us with a slightly improved process based upon the one we gave them. They switched from iPad to Surface Go and used some extra endpoint management to make the PWA experience into a sort of kiosk mode.
The #1 constraint for us is the quality of the environment-facing camera and the level of access we have to its capabilities via the browser. iOS/Safari started out extremely weak on this but is quite good today. I can get a solid 2k environment scan at 30fps from the rear facing iPad camera in Safari today. Things like 2D barcode scan and document capture are 100% feasible now. These items used to make us extremely nervous on product demos but we don't worry anymore.
We almost capitulated and went back to native iOS apps because of the camera issues, but the pain of maintaining a native build chain when you are otherwise a 100% Microsoft shop (with barely 3 developers) was pushing back hard too. We were signing enterprise IPAs for all of our clients for half a decade before we switched to web/PWA. I will never go back to native apps. I'll find a different career path and hobbies if the web goes away.
I don't have a clean answer for B2C other than... I use HN and Twitter in Safari and I don't even process that it's not a native app. Neither of these web properties had to spend a single second worrying about a native app to acquire my business.
Which JS library do you use?
I couldn't find a single library that can reliably scan PDF417 barcodes.
> Editors:
> Miguel Casas-Sanchez (Google LLC)
> Reilly Grant (Google LLC)
> Status of this document
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
— https://wicg.github.io/shape-detection-api/
Media constraints are the #1 reason it won't scan in my experience. You need at least ~1000px horizontal to reliably decode PDF417. If the resolution is 720p or lower, you aren't capturing enough information for a decode.
Scanning 2D barcodes only works reliable on smartphones with good camera and with good lighting.
I needed it for a ticket scanner used on an old phone at night entries for concerts.
Went and bought a hardware scanner (for 30€ or something) that connects itself as a "Bluetooth keyboard". Works like a charm.
We wont even fully certify iPhones for use with this solution because we have seen consistent failure to autofocus on the barcode for "some weird reason". iPads work like magic though. I have to go out of my way to not get a quick scan on recent generation iPad camera.
We went down the hardware scanning path w/ keyboard emulation in the browser, but its kind of clunky when you are considering the overall solution stack in a B2B setting.
It wasn't a easy ride (especially when it comes to LSP support for razor pages). But the overall experience was pretty decent.
Almost half of our users preferred to use the application as a PWA (using windows 10 and edge) instead of an ordinary tab in your browser.
Somethings to consider tho: Upgrades to service workers and what not can be a bit challenging depending on your situation.
Keep in mind that a lot of firewalls and antivituses may block all those binary downloads (since it's just dll files). There are ways around it ofc, but still expect files to be blocked.
Authorization changed between .net 7 and 8. So make sure you understand what these changes are (if you use packages from Microsoft)
The dll/firewall should be solved in .NET8 since the browser stack defined a native format (cil I think).
Thanks for the pro tips!!!
We haven't played with the client-side WASM stuff, but the conclusion is that server-side blazor is not a fantastic technology if you want something that "just works". Websockets in particular are kind of nasty when you have a client device ecosystem where screens and apps are frequently changing activity state. Stateless forms are much easier to reason about. iOS/Safari is very aggressive with closing down unused resources. Stateless forms can survive for days on those user agents. Our blazor apps would require refreshes after a few minutes of inactivity.
Vanilla web forms & SSR is what we run with today. Our "framework" is to use string verbatim & interpolation operators in C# to compose our responses. Looks something like PHP and has zero dependencies.
Going to a website and it loads some massive chunk of overengineered javascript when all I need to do is display one piece of text is infuriating.
It's not important to make a good product anymore: you need to be the first or the luckiest. Good products don't win because they are drowned in all the crap. And AI will soon make it infinitely easier to generate more crap.
Most apps do not need to be made by 10x developers who code in assembly.
I don't think we have the same definition what a "native app" means.
I get that Google pushes for PWAs because that's how they conquer the OS world. But why do individuals push for that? Because they don't know anything other than webtech and don't want to learn? Have a look at Kotlin and Swift guys, it's kinda cool!
Because we don't have the resources to build a native app for every OS out there.
We're not lazy but limited by our mortality.
> Because they don't know anything other than webtech and don't want to learn?
Are you sure you need three or more platforms? In my experience, when I ask small companies what they need, they say "everything". If I listen to them, they even need to run on a Gameboy. Then most startups fail, so apparently the problem was not the number of platforms.
It feels like many times, selecting the platforms may be fine.
Doesn't make it necessary. Just like analytics, actually: people like to have them, yet most of the time they don't do anything meaningful with them.
(Don't get me wrong: you are perfectly entitled to sell something people like, and people love spending time looking at analytics)
Web is free and people can build and release web apps they want.
Android is free, isn't it? Most smartphones use Android.
Then writing Desktop apps is free, too.
The PWA functionality will be fairly simple, mostly around reminders and badges.
Cross-platform usually sucks in some way. If the app is not worse, the development is: "write once, debug everywhere".
Web is solving that by forcing everybody to use the same (Google-controlled) renderer, so that there is no need for cross-platform anymore: just use the Google thing. I don't want that.
There's really not much reason to not use a browser, the compatibility issues are pretty much a thing of the past on any browser, unless you're doing something esoteric. Installing a special app should be unusual.
That's what I said.
> the compatibility issues are pretty much a thing of the past on any browser
Because there is only one meaningful browser left: Chromium. It is not a solution to cross-platform, it is just pushing for a monopoly. Just like a few years ago you could have been advocating for supporting exclusively Internet Explorer: that solves the compatibility issues too.
Now PWAs are not trying to kill other browsers (it's done already), but other platforms. That's just the next step.
Well it was following the "IE standards". The difference is only rhetoric to avoid antitrust. Google dominates the standards. Edge is Chromium, Mozilla is maintained in survival mode by Google.
> Chrome does, pretty religiously
I wouldn't call it "religious" when Chrome follows stuff Google wants and Mozilla/Apple don't want.
> there are a number of open source browsers based on Chrome
Based on Chromium, you mean? That's still dominated by Google.
But you're just putting yourself out on an increasingly brittle limb to defend native apps, which imo work against user interests.
Again, Chromium-based browsers don't count if their contribution to the codebase is marginal.
Then Google implements stuff that Apple and Mozilla disagree with, and devs still rely on it (e.g. web bluetooth). Not even mentioning that Mozilla is a joke kept alive by Google for antitrust reasons.
But even a Chromium based browser setting is better than some random app that could have been a web page.
Don't you think you are slightly underestimating the complexity of a browser that works with 99.9999% of webpages?
The second reason is the resources available. Going web first means your app is instantly available everywhere, even if not perfect.
We can learn Android and iOS development for sure, but how about both? And have you ever seen shops with the same developers targeting both iOS and Android with their native stacks? I haven't. Besides the web, you're limited in available options for reusing existing code and knowledge, such as React Native, and using cross-platform toolkits may be more risky than targeting the open web.
Controlled by Google with Chromium, right?
> The second reason is the resources available.
I guess that's the excuse, yes. But in my experience the native way is not necessarily more expensive. It's just faster to make a prototype in web, I suppose. And most apps end up being prototypes thrown into production nowadays.
So yeah: it's cheaper, not better, but that's enough to win.
No. We may speak about a hypothetical future, but right now, that's false. You don't need to pay the 30% tax on all sales, you don't need permission to publish a web app, you don't need to obey the rules for what's permissible in an app store, you don't go through a review process, you don't get your appeal judged by a kangaroo court. And while there are ways for Google to ban you from Search or flag your website in Chrome, a vast majority of cases had to do with legal censorship requests, copyright law, or blocking malware.
Google doesn't even have that much control because Chromium is FOSS, it already has contributors from companies with deep pockets, it can always be forked, which means Google has to play nice, like all FOSS stewards. Google has some control over the web, but their leeway is vastly overblown, and a bad rhetorical trick.
This isn't even a matter of perspective, and if smart, educated individuals can have disagreements on such clear issues, we are in trouble.
---
> But in my experience the native way is not necessarily more expensive.
We don't share the same experience. If you're speaking about personal projects displaying some simple forms, sure, but all the software companies I know hire separate Android, and separate iOS developers, tripling the frontend cost, with the minimum being one Android developer and one iOS developer. I have in mind companies big or small, start-ups or commercial FOSS even. The one exception I know used React Native, with an emphasis on iOS, the Android experience being terrible.
I think there is a mistake here, that management unfortunately systematically makes: writing one cross-platform app is not equivalent to writing one native app. The cost difference will depend a lot on the product. If your cross-platform devs spend double the time because they need to debug on the other platform they don't know so well, then... well it costs double the money.
Cross-platform never has the same kind of community for a specific platform. Android experts tend to write native Android apps, and so do iOS experts. My experience with cross-platform is that they are written by people who are experts on neither.
The mobile devs companies I know favor native apps, because in their experience it's not cheaper to use cross-platform frameworks, and the resulting apps are worse. Just like you seem to confirm:
> The one exception I know used React Native, with an emphasis on iOS, the Android experience being terrible.
The experience I have had in companies going cross-platform is that the employees they hire are not mobile devs, the app doesn't feel native at all, the debugging experience is terrible, and overall they struggle a lot. The only advantage I have seen (again, in my experience) with cross-platform frameworks is my "I told you so" moment with management, where whenever they complain about something I can say: "well you wanted cross-platform because you thought it was a fraction of the price, now you live with your choice". Hint: usually they don't like it.
This is why (imo) PWAs should not try to replicate native app functionality, but instead recognize the web for what it is and play to its strengths.
Sounds like common SPA application features to me.
Was very unreliable in iOS, but is much better now.
Namely: if you swipe from the sides of the screen to go back/forward, you get a duplicate animation. If you swipe back from B to A, once the native (interactive) slide animation finishes, the page then jumps back to B and then does another (noninteractive) slide animation to A.
Fixing this would be as simple as disabling the page's slide animation, but whoever made this site didn't notice or didn't bother.
Apple does have some blame here. Disabling the page's slide animation wouldn't be a perfect solution since it wouldn't distinguish slide gestures from other ways to go back/forward (which ideally would still show an animation), like using the browser's back/forward buttons if accessing the site in a browser rather than as an app, or using a keyboard shortcut with an external keyboard. I don't think it's possible to easily detect which kind of gesture triggered navigation (in order to conditionally show the animation).
Another option would be to disable the native slide gesture entirely in favor of a fully JS-based one. In the past it wasn't even possible to disable it, but that has been fixed for years now [1]. However, it's hard to exactly replicate the native behavior.
Ideally there would be a more purpose-built interface to detect and customize the native swipe gesture.
[1] https://pqina.nl/blog/blocking-navigation-gestures-on-ios-13...