What PWA Can Do Today
whatpwacando.today
whatpwacando.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.
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.
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.
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.
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...
This is why people outside this community often dislike their work being shared here, or at least refuse to read the comments.
If it's not Apple, Go or Rust; or some ten-story sandwich stack of cobbled together libraries, it's deemed trash. Don't you dare mention Java.
But what do I know, I'm just a sysadmin after-all. Everything is full-cycle cynicism to me; tomorrow we will be bitching about SPA's again and praising some new reinvented library.
Bring back ActiveX and JavaApplets.
I'm sure I'll get some "deemed worthy" downvotes for this comment; and I think I need more tequila.
It's disappointing because this site was one of the rare occasions I emailed the link to myself so I can add it to my list of things I want to look at. Having a concise demo of PWA functionality that exists is very useful.
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...
I reckon that CEO salary has to come from somewhere though.
[0]: https://www.reddit.com/r/firefox/comments/uwojh7/why_did_fir...
I wonder if that's down to config for the PWA or a Firefox shortcoming. Anyone know?
This is something enforced by android. If every app was able to pin apps to the homescreen without such a badge, phishing would be too easy ... add something that looks like a bank app to the homescreen, get people to type in their password ...
It's not fair, since that's not true for chrome, but there's no obvious solution, other then I guess having some sort of "super trustworthy" status for a few other browsers like firefox.
I find it much easier to open a website from the addressbar then to open an "app" using spotlight.
I always have a browser window open anyway.
In-app tabs are supposed to be the second level of grouping, hence why it gets its own shortcut. What you're describing is an attempt to flatten that hierarchy, which is a valid approach, but why are you surprised that not everybody shares your enthusiasm for it?
- Takes ages to finish loading
- huge number of features/functionality I don’t want a website to have over my phone/desktop
- navigation is broken: swiping back causes some double-navigation stutter.
- history is broken: attempting to navigate back to HN loads the same page again and again with no content change a stack of times, before I can finally escape.
Do I understand your second point correctly? The feature demo is failing at being a feature demo because it demoes some features that you don't like?
Every time someone talks about “how great PWA’s are” and how much better they’ll be after just some more features, I just hear “more stuff for advertisers to abuse”, “more things for half-assed devs to drain my battery and network with” and “more ways to have shittier experiences, slower” the less I’m interested in them.
More concretely, it’s a feature demo that doesn’t work (see navigation) for features I consider anti-features.
I think you're shooting the messenger here.
> 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.
I'm on Android Firefox.
Seems that either the author is only working in Chrome (which is probably reasonable for a prototype or whatever) or Firefox is lacking many of these features.
Many advocates will tell you the thing is just as good, or at least more than good enough, and will deliberately avoid telling you about the many pitfalls and not-so-edge cases that they are very much aware of.
On the other hand i have been using the Eclipse Emulator PWA https://eclipseemu.me/ on iOS for a few days and it works really well! The only issue i've had so far is choppy sound when emulating SNES.
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.
For the file system access API, only the origin private file system is enabled on Android[1].
IMO, the file system access APIs are still a bit immature.
[0]: https://play.google.com/store/apps/details?id=com.messianicr...
So frustrating to be soooo close, and then need to build an iOS app.
How can you “sell” PWA or have subscription for ad removal?
For non-free apps, one thing I've seen is app Stores launch the PWA with some flags indicating it was launched from the Store. If these flags are not present, the app is being launched via direct URL, in which case the app server can give a not authorized response.
[0]: https://developer.chrome.com/docs/android/trusted-web-activi...
https://9to5mac.com/2022/12/13/apple-mulls-opening-browser-e...
I very much hope it's true.
> "First, browser engine choice should become a reality on iOS in the EU in 2024, thanks to the plain language of the DMA. Apple will, of course, attempt to delay the entry of competing browsers through as-yet-unknown strategies, but the clock is ticking. Once browsers can enable capable web apps with easier distribution, the logic of the app store loses a bit of its lustre."
https://chromium.googlesource.com/chromium/src/+/main/docs/i...
https://bugs.chromium.org/p/chromium/issues/detail?id=141170...
Maybe I'm just a little slow with things but alongside janky styling I found it insanely difficult to implement any kind of offline native text to speech (I.e. not just sending sound files over an api call to anither api).
Seeing that it (and lots of other things) are now implementable with PWAs fills me with excitement that "write once, run on iOS/android" might be becoming a real option for apps.
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.
That and the fact that there is a large legal aspect to all of this largely led by the EU that seeks to prevent that kind of anticompetitive behaviour.
Ironically, Apple os is going in the reverse direction it seems as Safari has not much good PWA story.
There is a nested scroll view, sometimes when I scroll up / down, the bottom navigation bar follows with me.
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.
Was very unreliable in iOS, but is much better now.
Even the text seems wrong? The prose seems to indicate it is installable even outside of mobile … but I have no idea. I'd've expected one of those popup "this site wants…" boxes, but nope?
I also sort of thought PWAs were supposed to be responsive in their UI, adjusting to more/less real estate, but this is just the same UI at any size?
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.
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.
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.
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 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.
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.
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.
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?