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.
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.
— 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.
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.
So many simple setup apps wouldn't need to be native.
If they are simple, why not making them native?
Because in native even simple is complicated?
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.
Provisioning IoT devices has to be done through native apps if Web Bluetooth isn't viable. It's a total PITA.
Web BT permissions can be disabled if not needed. I reject Mozilla's and Apple's reasoning.
Yes I really want random websites to have access to Bluetooth
They're not random websites though. They're apps that you have installed. And given permissions to.
The gatekeeping/FUD/wringing-of-pewrls over this seems absurd, cruel, and most of all arbitrary to me. Insubstantial naysaying.
I have never heard and end user say - “you know Electron apps are so great on the desktop, it would be really great if all apps on phones were PWAs.”
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.
And a massive exploit capability for malware.
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.
Extinguish? The web is "existinguished" by websites being able to use bluetooth, after asking for permission?
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?
or not knowingly
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?
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.
Yeah, I refuse to use VScode because it's ElectronJS. I have colleagues who now find it super cool to use it from GitHub, I don't understand.
I use the JetBrains IDEs, made for the JVM.
...okay, but in the context of:
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?
If bluetooth is so essential that a substantial portion of the web will rely on it, then maybe other browsers should support it.
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.
Bluetooth is the example that you chose, and that I used to make a general point, which also applies to any other API.
I'm not OP
Another API that Google implemented that Mozilla and Apple made similar objections to is WebUSB.
Very useful for flashing microcontrollers and devices without need of native apps. No installation, no drivers, works cross platform.
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.
So sad, if FirefoxOS still where a thing they wouldn't bat an eye.
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.
"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.
Go to any webpage/PWA, hit the share button, hit “add to home screen“.
That’s it. It’s not complicated or restricted in any way.
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.
Its not intuitive for the average user. "Share" does not usually imply "Install" , and the add to home screen option for me is way down in the menu.
You’re not wrong. But at this point Apple has buried EVERYTHING inside the share sheet.
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.
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.
Hm, last time I checked and tried this, there were still limitations, but it has been a while and maybe something improved.
it has changed, at least on MacOS Sonoma. I can "add a website to dock" and it launches in fullscreen if the manifest.json is set up correctly.
On IOS, I can't install a PWA/add to home screen with a simple click. I think thats the bigger obstacle.
Can't you? You just hit Share->Add to Home Screen, granted that's two clicks, but it seems pretty straight-forward.
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.
You can't install an app from the App Store with a single click.
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).
1. https://developer.apple.com/documentation/webkit/promoting_a...
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.
For example, browsers don’t furnish a tableview/datagrid or even a basic single column recycler view
<table> and <ol>? Or am I missing something?
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.
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!
But why do individuals push for that?
Because we don't have the resources to build a native app for every OS out there.
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).
But people and I like having an icon on our phones that we can click to open a dashboard quickly.
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)
Yeah, only privileged white people can build apps.
Web is free and people can build and release web apps they want.
only privileged white people can build apps.
Android is free, isn't it? Most smartphones use Android.
Then writing Desktop apps is free, too.
"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.
Internet Explorer did not follow web standards
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.
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.
is that the web is a free market
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.
Controlled by Google with Chromium, right?
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.
I’m looking to release two web apps as PWAs. This will make the experience close to native on iOS and android without going through the app stores.
How do you release them? You don't have to go through the Play Store to release an Android native app, and I think the EU is making it change for iOS.
By Release I mean Create on the web, make downloadable as a PWA. No App Store necessary.
The PWA functionality will be fairly simple, mostly around reminders and badges.
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.
2D barcode
Which JS library do you use?
I couldn't find a single library that can reliably scan PDF417 barcodes.
I assume the built in one that OP has? https://developer.mozilla.org/en-US/docs/Web/API/Barcode_Det...
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.
Can't you take a C library and compile to JS?
Wasm should also work, no?
That's a shame. Works really well on Android.
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.
https://github.com/zxing-js/library
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.
I tried zxing too.
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.
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.
We've also not had the best luck with keyboard emulation scanners, but unless you want to add a native wrapper, there aren't a ton of good options.
Oh how come?
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.
Scandit customer here. Their stuff works well. The only drawbacks are reliance on npm and frequently changing APIs.
Full disclosure: I work for Scanbot SDK, but we do offer PDF417 scanning for JS. It's a commercial solution that comes with a not-insignificant price tag, but it might be what you're looking for. You can check out the demo and documentation here: https://scanbot.io/trial/demo-web/barcode-demo/ , https://docs.scanbot.io/barcode-scanner-sdk/web/introduction...
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.
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.
Yeah, server side blazor is IMHO a bad product. Blazor with wasm on browser or PWA or Blazor with MAUI and a web view (without wasm) is the deal.
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)
Editing in VS Code is really bad right now. It got worse actually.
The dll/firewall should be solved in .NET8 since the browser stack defined a native format (cil I think).
Thanks for the pro tips!!!
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.
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.
[1] https://learn.microsoft.com/en-us/microsoft-edge/progressive...
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.
Apple wants to keep in control with the app store. PWAs threaten that control. So much so apple doesn't allow other browsers.
While Google wants as much access to your phone as it can get. Why would that be?
What access does Google gain here?
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.
That argument would work if it were only Apple rejecting them. Mozilla rejects them on the same grounds.
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.
What's with the FUD. What else besides PWAs promise to free everyone from app store rent and anticompetitive policies?
PWAs would also open the doors to new mobile OSs beyond Google or apple control.
What else besides PWAs promise to free everyone from app store rent and anticompetitive policies?
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.
laws?
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.
Still you count on the law to force iOS to accept PWAs, right? Isn't that a bit hypocritical?
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?
How does that work?
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
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.
Web Share Target API (manifest: share_target) - it allows a website to specify itself as a share target. Of course, it's not yet supported on iOS.
This is not a web standard. Google wrote the specification and only Google have implemented it. It’s an unofficial draft:
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.
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?
Well until that point, and until it’s ratified as one, it’s not a web standard, so you can’t get disappointed that nobody else implements it.
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
this is foreseen to come eventually, the APIs are there https://web.dev/articles/web-share?hl=en
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.
Sure would be nice if Firefox desktop would join the browsers that support PWAs. We build an app that has been PWA-first, but it is unfortunate that this generally requires users to have a Chrome instance running. Would much rather point people to Firefox, and it seems like it would be to their advantage to give apps a reason to recommend FF, if they built a smoother PWA integration than Chrome.
Firefox on Android is worse experience than Chrome too, at least for this app. The app is harder to install (no prompt), the icon looks worse, and the icon has a Firefox badge on it.
I wonder if that's down to config for the PWA or a Firefox shortcoming. Anyone know?
and the icon has a Firefox badge on it
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.
At least with Nova launcher, you can "edit" a PWA icon once it's on the home screen and un-check the badge to make it look more seamless.
Agreed. On Firefox, if I navigate to the main page I can scroll and look at all the items. If I go to a sub-page, then back to the main page, I can no-longer scroll to see all of the "supported" features. :/
I really wish they would do that.
Mozilla's removal of SSB support (single-site browser[0]) which is the key missing piece here is completely mystifying.
I reckon that CEO salary has to come from somewhere though.
[0]: https://www.reddit.com/r/firefox/comments/uwojh7/why_did_fir...
I don't understand the point of PWAs on desktop.
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.
This page was the first time I had heard of the Contact Picker API. I tried to select the text to google it and this page has somehow disabled select/copy/paste of text. This is an ironic way to show that the web is just as capable/incapable as native apps.
I’m perfectly able to select the text.
I tried on Safari and Chrome. Maybe I need to install a special browser to use that web page. I wonder if they make an app.
Just tap and hold, works fine for me on iOS and Android
I see that it works fine for me also on mobile. Somehow they have managed to neuter the desktop experience. A perfect demonstration of PWA today.
Desktop works as well
The website applies -webkit-user-select: none to everything in the feature grid. The website author has intentionally disabled this functionality.
I tried two of the features at random (face detection and vibration). Face detection told me my device wasn't supported, and vibration just straight up didn't work. Then I tried to back out of the website and it wouldn't let me.
I'm on Android Firefox.
Unfortunately, feature detection indicates that Firefox on Android supports vibration, but it doesn't currently work.
Par for the course on Firefox I'm afraid. Every time I give it a chance it lets me down.
Same experience for me on Android Firefox. Couldn't return to HN via the back button, and most of the features were either "not supported" or just didn't work (e.g. Vibration)
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.
I thought it was just me because I'm using uBlock. But even with the site first party scripts and line allowed it didn't work.
This is what happens for a lot of "this is just as good!" type features in any domain.
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.
My estimate is there are 5,000-10,000 really poor PWA/SPA/etc for every actual good PWA/SPA.
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.
Gatekeeping is strong here.
Most apps do not need to be made by 10x developers who code in assembly.
Some things should be kept at gates.
Then just serve a text file, literally 99% of PWA/SPAs could be static sites
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.
Please don’t call this engineering.
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.
[1] https://pqina.nl/blog/blocking-navigation-gestures-on-ios-13...
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.
Is there anything about native apps or conventional websites/apps that would improve the visuals?
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.
I’m the creator of this and haven’t been able to reliably fix this so far but I’ll give your suggestion a try.
Not everyone has apple devices to test on for their toy project. I know I don't.
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).
Most calendars have the option for you to subscribe to an ical by pasting in the web address. Which they will then keep in sync.
I track sport events with Fantastical’s interesting calendars.
You're looking for SOGo. https://en.m.wikipedia.org/wiki/SOGo
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.
firefox killed of pwas
How? Did it even reach significant mobile share at any point?
Also, Firefox on Android still supports PWAs, it was only removed on the desktop.
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.
How so? FF has minimal market share, most of it on desktops.
Just wondering why mobile platform gate keepers, even Google would allow PWAs which will erode the value of their platform.
Because holding customers hostage is a shit strategy?
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.
I of course was aware of PWAs but didn't know that so much is possible just with the Web APIs now that only but maybe some highly specialized apps would need native apps which are difficult to develop and are subject to an approval process on top.
Ironically, Apple os is going in the reverse direction it seems as Safari has not much good PWA story.
Google makes more money from the Web platform than the Android platform.
the elephant in the room is the lack of support from Apple, by this alone, its apps store should be legally challenged, before that happens, it's hard to sell PWA, which is great on a tech standpoint.
It's rumored Apple may finally allow outside browser engines due to pressure from the EU (also behind the USB-C switch).
https://9to5mac.com/2022/12/13/apple-mulls-opening-browser-e...
I very much hope it's true.
It's not a rumor, it's reality: https://infrequently.org/2024/01/the-web-is-the-app-store/
"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."
Blink can now be compiled for iOS, but without JIT or WASM:
https://chromium.googlesource.com/chromium/src/+/main/docs/i...
https://bugs.chromium.org/p/chromium/issues/detail?id=141170...
Why does the HN crowd love to leave comments of mean criticism as if it was certain the creator of the submitted site wasn't going to see it? You can levy critique without being rude. Not many are doing this, but it doesn't take much. Maybe letting harsher-than-necessary criticism wash over you is necessary for putting any creation out into the world, but it still feels bad to see.
This is why people outside this community often dislike their work being shared here, or at least refuse to read the comments.
A lot of the criticism seems to be about the UI and the site is about functionality that's available. It doesn't make sense to criticize the implementation details in my opinion.
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.
Especially for an article about... PWAs. It's so weird to be this worked up about this, like sure maybe they suck but that's not the point of the article. It's like getting mad at someone for writing a c++ article because it's not a memory safe language... like... okay!
The HN crowd are mainly developers who feel that their opinion is strictly correct with no leeway; as per developer culture.
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.
If this site is supposed to be a good demo of what they’re capable of, it’s failing pretty hard for me.
- 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.
I understood this as a showcase of the features that PWAs can use, and I think it does a pretty good job at that.
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?
If you demoed a car, whose feature set included “often opening the glove box into your shins” and “texting inappropriate things to your ex”, you’d be pretty leery of using it. If random people kept going on about how much they love this car, and the ex-texting features were so good, that they hoped to upgrade them into “actively calling your ex” you’d be a bit leery of what they were talking about.
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.
If there was a car with those features and someone sold it to me without talking about them, I would be pretty angry.
I think you're shooting the messenger here.
I'm working on a minimal music player for Android that just plays from a directory on device. Can I do this with a PWA? I just tried the File System Acecss API -> Open directory but it did nothing.
Firefox doesn't support the File System API btw.
I have a music player PWA published on Android[0]. It works pretty good, my users are happy (rated 4.5 stars), and I haven't encountered any significant issues with it.
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...
iOS PWA notifications are a pain in the ass to set up without using something like firebase, but they are so nice to have finally.
Why are they a pain? Do they have extra requirements over the standard Web Push API?
They don’t
As soon as I tapped into this site, the browser's back button got hijacked and half of the features don't work.
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.
That it can break my back button is also what i took away from this before closing the tab and reopeing hackernews.
As soon as I tapped into this site, the browser's back button got hijacked and half of the features don't work.
Sounds like common SPA application features to me.
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.
https://developer.chrome.com/docs/capabilities/tabbed-applic...
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=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?
Man, the amount of ux bugs really describes the state of this. Is this the best experience we can give users through pwa?
What UX bugs specifically?
When swiping to navigate back, it stutters.
There is a nested scroll view, sometimes when I scroll up / down, the bottom navigation bar follows with me.
I really love how PWA goes. But one aspect for some use cases is monetizing.
How can you “sell” PWA or have subscription for ad removal?
For in-app purchases of PWAs in app Stores, you can use the Digital Goods API[0]. It works for Google Play and Microsoft Store.
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...
Doesn't work with JavaScript disabled.
This is an example showcase and PWAs require JavaScript to register the service workers for these features (as well as to operate them of course).
A GitHub repo with just a bug tracker and no source code is kind of lame. If they really want to promote PWA they should have full source on there.
They don't want to promote PWAs. They want to promote their own business.
Is there such a thing as _live_ geolocation?
Geolocation API has "watchPosition", so it sends updates as often OS/browser decides.
Was very unreliable in iOS, but is much better now.
A PWA is much smaller than a native app. Your users no longer need to install tens of megabytes of code.
I don't think we have the same definition what a "native app" means.
A big limitation is that pwabuilder doesn't support push notifications on ios
Pretty buggy for me. Wonder if better connectivity will lead to remote streaming apps and skip this mess altogether.
We built hellowonder.ai as a PWA first, and it was almost amazing! But we use voice input, and ios would pop up the microphone permission repeatedly after a few minutes, even if it had been approved recently. I couldn't figure out how to keep the microphone permission!
So frustrating to be soooo close, and then need to build an iOS app.
Things PWAs can't do: 1. On mobile, access full-definition camera/video as part of MediaDeviceCapture. There are new javascript APIs for this, but they're only partialy supported (the name of the new escapes me)
Couldnt add it to homescreen on ios firefox because the option in the share menu wasn’t there
Will wait for the next version of the website: whatpwacandosafely.never
I fell for the marketing and built a PWA for an app that needs to receive notifications even with the device in "deep sleep". It kind of worked, but not quite, which was a huge deal breaker. It took me a lot of googling to find an obscure Chromium bug report stating that this doesn't work as reliable as in native apps and is in that nasty "we will never close this ticket but we will never work on it either" state. Complete with many many howls of outrage from people like me who depended on this working right and now have to rewrite their app.
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
Slightly misleading domain when a large number of those arent actually supported in major browsers, certainly not at enough consistency.
Whoever made this, this is incredible, thank you.
Is this satire? I'm not sure what about this is supposed to be a convincing argument for PWA?
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?
This blows me away! I did a tiny bit of prototyping a year or so ago with an app for react native that required text to speech.
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.
I'm still glad I invested time in flutter for a cross platform framework.
Several of the features in this demo app are broken (not just not implemented on iOS 17). That's how Apple likes it, i guess.
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.
Isn’t there storage limitations for mobile PWAs?
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.
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.
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.
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.
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 Android user I don't feel bombarded by install requests, so I don't really know what you're talking about.
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.
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.
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.
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 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.
PWAs are cheap compared to native apps. That's the whole point.
So the exact opposite of PWAs.
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.
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.
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
"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.
There are many types of applications out there besides ads.
Wouldn't that be the opposite? Subscriptions through the App stores, ads as PWA?
Apple laughs at your universal support.
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.
It just happened to coincide with the moment the EU started looking quite seriously at what they were doing.
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.
"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.
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.
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
If you open the site on a target device, it'll tell you whether the feature works on that browser or not.