Microsoft and Google collaborate to make PWAs better(medium.com)
medium.com
Microsoft and Google collaborate to make PWAs better
https://medium.com/pwabuilder/microsoft-and-google-team-up-to-make-pwas-better-in-the-play-store-b59710e487
196 comments
I agree. Apple is stifling innovation by not supporting certain APIs.
They need to stop doing this, or they will hurt themselves in the long run. As it is, most people use Safari on iOS because they are forced to - all other browsers on iOS are forced to use WKWebView, which basically means they are wrappers around Safari's view.
To this day, I can't understand why their users stand for this. In this regard, Apple reminds me of a cult leader brainwashing their followers into believing the cult's way is the best way. Makes me a little sick actually.
They need to stop doing this, or they will hurt themselves in the long run. As it is, most people use Safari on iOS because they are forced to - all other browsers on iOS are forced to use WKWebView, which basically means they are wrappers around Safari's view.
To this day, I can't understand why their users stand for this. In this regard, Apple reminds me of a cult leader brainwashing their followers into believing the cult's way is the best way. Makes me a little sick actually.
Apple is making the right decision here.
My iOS device has never once shown me "this website requires Chrome." I get to use the mobile web without needing Google. And Apple is the only reason why.
Maybe some day, web apps will become so undeniably awesome that Safari's position is untenable. But the agitation is not coming from iOS users missing out on awesome PWAs. Instead it's web developers, who are just annoyed that they have to actually respect the conventions of the platform they're building for.
My iOS device has never once shown me "this website requires Chrome." I get to use the mobile web without needing Google. And Apple is the only reason why.
Maybe some day, web apps will become so undeniably awesome that Safari's position is untenable. But the agitation is not coming from iOS users missing out on awesome PWAs. Instead it's web developers, who are just annoyed that they have to actually respect the conventions of the platform they're building for.
I couldn’t agree more. As a developer, PWAs are amazing. Write once, run more or less everywhere. Our enterprise software deployments wouldn’t have been possible if we had to target iOS, Android and Windows specifically.
As an end user, I dread the days PWAs ever go mainstream. They’re horribly inefficient from a power and performance point of view, and never have I come across a PWA with a user experience half as good as native apps (especially on mobile). Until they’re indistinguishable from native apps in terms of user experience, I want nothing to do with them. Beyond that, there’s some very serious privacy concerns as well with PWAs, especially with developers abusing APIs for fingerprinting
As an end user, I dread the days PWAs ever go mainstream. They’re horribly inefficient from a power and performance point of view, and never have I come across a PWA with a user experience half as good as native apps (especially on mobile). Until they’re indistinguishable from native apps in terms of user experience, I want nothing to do with them. Beyond that, there’s some very serious privacy concerns as well with PWAs, especially with developers abusing APIs for fingerprinting
I also build PWAs for enterprise and I have to disagree on performance and UX. My users love them.
Many didn’t understand what a web app was until recently and now they want nothing else. For starters the speed and ease of deployment can also impact the user experience; people love seeing problems fixed and tweaks made on the fly in reaction to their feedback.
But more than anything they’re thoroughly impressed with the interfaces compared to other shitty desktop enterprise software they use. At the end of the day it’s the same story as with all software: quality often depends more on craftmanship than on the flavor of tool that you’re using. PWAs offer enough means to build beautiful and performant software, with full offline capabilities that can make them nearly indistinguishable from a native app.
I can’t disagree that native apps have advantages in some use cases. For the most part I wouldn’t build something like a graphics editing program as a web app - companies like Figma challenge this, but they’re using techniques at the edge of web dev that go beyond PWA capabilities (eg, WebAssembly), and unless you have an all-encompassing product strategy like they do you’d probably be better off building something like that native.
For many CRUD app use cases however PWAs can be more than sufficient. I’m very bullish about their future, and I wouldn’t be if I hadn’t seen real, happy users, because that's what matters to me the most.
Many didn’t understand what a web app was until recently and now they want nothing else. For starters the speed and ease of deployment can also impact the user experience; people love seeing problems fixed and tweaks made on the fly in reaction to their feedback.
But more than anything they’re thoroughly impressed with the interfaces compared to other shitty desktop enterprise software they use. At the end of the day it’s the same story as with all software: quality often depends more on craftmanship than on the flavor of tool that you’re using. PWAs offer enough means to build beautiful and performant software, with full offline capabilities that can make them nearly indistinguishable from a native app.
I can’t disagree that native apps have advantages in some use cases. For the most part I wouldn’t build something like a graphics editing program as a web app - companies like Figma challenge this, but they’re using techniques at the edge of web dev that go beyond PWA capabilities (eg, WebAssembly), and unless you have an all-encompassing product strategy like they do you’d probably be better off building something like that native.
For many CRUD app use cases however PWAs can be more than sufficient. I’m very bullish about their future, and I wouldn’t be if I hadn’t seen real, happy users, because that's what matters to me the most.
> Beyond that, there’s some very serious privacy concerns as well with PWAs, especially with developers abusing APIs for fingerprinting
If TikTok was a PWA it couldn't have done a fraction of the tracking it was doing. The irony is that apple is forcing you to use a much more privacy-invasive alternative to PWAs.
If TikTok was a PWA it couldn't have done a fraction of the tracking it was doing. The irony is that apple is forcing you to use a much more privacy-invasive alternative to PWAs.
> If TikTok was a PWA it couldn't have done a fraction of the tracking it was doing.
This is misleading when the motives of PWA is to make the web browser acquire as much capabilities as a native app. If browsers keep on expanding access to the underlying platform without any regards of the consequences, TikTok would be able to track you more without you ever having to install anything. This would kill the web as we know it because you’ll have to give websites the same trust you give to software when you install them on your computer. We won’t be able to browse the web freely as we do now.
This is misleading when the motives of PWA is to make the web browser acquire as much capabilities as a native app. If browsers keep on expanding access to the underlying platform without any regards of the consequences, TikTok would be able to track you more without you ever having to install anything. This would kill the web as we know it because you’ll have to give websites the same trust you give to software when you install them on your computer. We won’t be able to browse the web freely as we do now.
Misleading how? You have one platform that already allows crazy privacy violations natively, and you have another platform that you suspect might some day allow similar levels of privacy violation, yet you champion the privacy stance of the first platform.
Makes no sense to me.
Makes no sense to me.
> Misleading how?
I pretty much explained everything after the first three words of my comment.
> You have one platform that already allows crazy privacy violations natively,
Give me a single example of an OS for a personal computing device where you don't have to trust what you install.
> and you have another platform that you suspect might some day allow similar levels of privacy violation
No, this isn't speculation, this is the inevitable future of going the PWA route. If browsers expand access to a platform that, as you put it, "allows crazy privacy violations," then it's bound to allow similar levels of privacy violations, plain and simple.
One of the best things about the browser runtime is that it has (or perhaps, had) pretty good isolation from the host platform [1]. This is great for browsing because you can click on a link without thinking twice about it. When that isolation is rendered meaningless, you really have to stop and think about whether you trust the website you're going to visit, just like you would when you install native apps on your device. So get ready to kiss bye-bye to visiting a random blog you saw on HN.
> yet you champion the privacy stance of the first platform
You've made that one up. I explicitly mentioned that you have to trust the apps that you install.
Please note that I'm not hating on PWAs for the sake of it. I just don't want to sacrifice the privilege of being able to browse the web freely because of it.
[1]: I know, there are bugs in the implementation, but they're relatively costly to exploit in a meaningful way, especially at scale
I pretty much explained everything after the first three words of my comment.
> You have one platform that already allows crazy privacy violations natively,
Give me a single example of an OS for a personal computing device where you don't have to trust what you install.
> and you have another platform that you suspect might some day allow similar levels of privacy violation
No, this isn't speculation, this is the inevitable future of going the PWA route. If browsers expand access to a platform that, as you put it, "allows crazy privacy violations," then it's bound to allow similar levels of privacy violations, plain and simple.
One of the best things about the browser runtime is that it has (or perhaps, had) pretty good isolation from the host platform [1]. This is great for browsing because you can click on a link without thinking twice about it. When that isolation is rendered meaningless, you really have to stop and think about whether you trust the website you're going to visit, just like you would when you install native apps on your device. So get ready to kiss bye-bye to visiting a random blog you saw on HN.
> yet you champion the privacy stance of the first platform
You've made that one up. I explicitly mentioned that you have to trust the apps that you install.
Please note that I'm not hating on PWAs for the sake of it. I just don't want to sacrifice the privilege of being able to browse the web freely because of it.
[1]: I know, there are bugs in the implementation, but they're relatively costly to exploit in a meaningful way, especially at scale
> pretty good isolation from the host platform
Define "pretty good". Compare the permission model of the browser against the appstores. Think about what their manual review process actually is for 99% of the submissions.
> When that isolation is rendered meaningless
PWSs don't and won't do that. That's your whole argument and it's misleading.
Define "pretty good". Compare the permission model of the browser against the appstores. Think about what their manual review process actually is for 99% of the submissions.
> When that isolation is rendered meaningless
PWSs don't and won't do that. That's your whole argument and it's misleading.
> Define "pretty good".
It's a well-known fact. Actually, I'm pretty sure you're aware of this, considering this statement of yours:
> If TikTok was a PWA it couldn't have done a fraction of the tracking it was doing.
As for this:
> Compare the permission model of the browser against the appstores.
What are you even talking about? It has nothing to do with browser isolation.
> PWSs don't and won't do that. That's your whole argument and it's misleading.
That's an interesting assertion but you haven't left me any clue why you think so.
I also notice that you chose to quote a conditional sentence out of my argument, claiming that it was my "whole argument," but I'd also like to add that I did explain the hows and whys that lead it.
It's a well-known fact. Actually, I'm pretty sure you're aware of this, considering this statement of yours:
> If TikTok was a PWA it couldn't have done a fraction of the tracking it was doing.
As for this:
> Compare the permission model of the browser against the appstores.
What are you even talking about? It has nothing to do with browser isolation.
> PWSs don't and won't do that. That's your whole argument and it's misleading.
That's an interesting assertion but you haven't left me any clue why you think so.
I also notice that you chose to quote a conditional sentence out of my argument, claiming that it was my "whole argument," but I'd also like to add that I did explain the hows and whys that lead it.
sorry, I misquoted the first quote, I mixed up contexts.
> the motives of PWA is to make the web browser acquire as much capabilities as a native app
This is misleading. To get to the point, your argument is that PWAs strive to be just like apps, but run in the browser instead of the OS. This is simply not true.
If you want back the web of old times, just documents and links, then you can pick up any one of such initiatives. Reality however is that PWAs are a successful model: just go to a URL and use it. It runs on a protocol, not some proprietary platform, which gives users enough control (e.g. tracking), while being useful.
> the motives of PWA is to make the web browser acquire as much capabilities as a native app
This is misleading. To get to the point, your argument is that PWAs strive to be just like apps, but run in the browser instead of the OS. This is simply not true.
If you want back the web of old times, just documents and links, then you can pick up any one of such initiatives. Reality however is that PWAs are a successful model: just go to a URL and use it. It runs on a protocol, not some proprietary platform, which gives users enough control (e.g. tracking), while being useful.
> To get to the point, your argument is that PWAs strive to be just like apps, but run in the browser instead of the OS. This is simply not true.
I'm confused, because it's supposed to be PWA's major selling point. Google says as much in their documentation [1], as do many commenters in this thread.
> If you want back the web of old times, just documents and links, then you can pick up any one of such initiatives. Reality however is that PWAs are a successful model: just go to a URL and use it.
Don't get me wrong, I don't hate web apps in general. On the contrary, I happily use them on a daily basis. However, I don't like the direction PWA seems to be heading. Acquiring more "native" capabilities is one thing, though I won't be going over this again. Another important point is that it doesn't fit quite well with the "browsing" aspect of browsers. Web apps are nice, but they're hardly the only kinds of websites I visit. I visit quite a lot of random websites every day, many from HN, and I want almost none of these websites spinning up Service Workers or asking me to turn on push notifications. Web apps being more capable is nice, but I don't want them at the cost of a more spammy browsing experience.
I do want the web to be more capable, but careful design and consideration is equally as important when it comes to making the web a better place. I feel that many accusing some browsers of "holding the web back" are overlooking this point.
[1]: https://web.dev/what-are-pwas/
I'm confused, because it's supposed to be PWA's major selling point. Google says as much in their documentation [1], as do many commenters in this thread.
> If you want back the web of old times, just documents and links, then you can pick up any one of such initiatives. Reality however is that PWAs are a successful model: just go to a URL and use it.
Don't get me wrong, I don't hate web apps in general. On the contrary, I happily use them on a daily basis. However, I don't like the direction PWA seems to be heading. Acquiring more "native" capabilities is one thing, though I won't be going over this again. Another important point is that it doesn't fit quite well with the "browsing" aspect of browsers. Web apps are nice, but they're hardly the only kinds of websites I visit. I visit quite a lot of random websites every day, many from HN, and I want almost none of these websites spinning up Service Workers or asking me to turn on push notifications. Web apps being more capable is nice, but I don't want them at the cost of a more spammy browsing experience.
I do want the web to be more capable, but careful design and consideration is equally as important when it comes to making the web a better place. I feel that many accusing some browsers of "holding the web back" are overlooking this point.
[1]: https://web.dev/what-are-pwas/
> Beyond that, there’s some very serious privacy concerns as well with PWAs, especially with developers abusing APIs for fingerprinting
Do you think native platform APIs are more restrictive?
Do you think native platform APIs are more restrictive?
What's the problem with enterprise deployments?
>My iOS device has never once shown me "this website requires Chrome." I get to use the mobile web without needing Google. And Apple is the only reason why.
Let's be real though, Apple didn't enforce this to save user's the small annoyance of 'use browser X' popups. Instead it gives them full control over what web APIs are available on iOS devices, so they can avoid implementing those APIs that would impact on their App Store revenue. They have a clear financial benefit in not supporting the PWA technology that would move the 'simpler' apps off their app store and into web - where they wouldn't receive their developer license fees, a cut of paid apps and a cut of paid subscription fees (outrageous). Also, I believe it was Steve Jobs who first shared the vision of web applications on iPhone “that look exactly and behave exactly like native apps” ?
> Instead it's web developers, who are just annoyed that they have to actually respect the conventions of the platform they're building for.
Developers already get around this to some extent with cross platform tools such as React Native, Xamarin, Flutter. Native apps will always have a place, PWAs are not going to replace sufficiently complex app experiences, much like on Android or Windows.
Let's be real though, Apple didn't enforce this to save user's the small annoyance of 'use browser X' popups. Instead it gives them full control over what web APIs are available on iOS devices, so they can avoid implementing those APIs that would impact on their App Store revenue. They have a clear financial benefit in not supporting the PWA technology that would move the 'simpler' apps off their app store and into web - where they wouldn't receive their developer license fees, a cut of paid apps and a cut of paid subscription fees (outrageous). Also, I believe it was Steve Jobs who first shared the vision of web applications on iPhone “that look exactly and behave exactly like native apps” ?
> Instead it's web developers, who are just annoyed that they have to actually respect the conventions of the platform they're building for.
Developers already get around this to some extent with cross platform tools such as React Native, Xamarin, Flutter. Native apps will always have a place, PWAs are not going to replace sufficiently complex app experiences, much like on Android or Windows.
Not many websites explicitly require Chrome. I don't know what you mean by 'My iOS device has never once shown me "this website requires Chrome."'
Why would your iOS device ever need to show such a message, unless it's implemented by the website itself? I don't understand the scenario you're describing at all.
Why would your iOS device ever need to show such a message, unless it's implemented by the website itself? I don't understand the scenario you're describing at all.
You missed their point.
Apple only allows the Safari browser engine to run on their phone.
So Google (and other web developers) can't do what they do on other platforms which is only test their website on Chrome or block users of other browsers.
For example, Firefox on Android gets a crap Google search from like 2005 unless you spoof your user agent and it works perfectly.
By that mandate has kept complete control over the browser space from Google.
Apple only allows the Safari browser engine to run on their phone.
So Google (and other web developers) can't do what they do on other platforms which is only test their website on Chrome or block users of other browsers.
For example, Firefox on Android gets a crap Google search from like 2005 unless you spoof your user agent and it works perfectly.
By that mandate has kept complete control over the browser space from Google.
I've very rarely seen a website block a user because of their browser in the last 10 years.
If a website doesn't work in Safari, it just doesn't work. That's it. I do know that devs have to work A LOT harder to get things to work in Safari when compared to Chrome or Firefox. It's like Safari is the new Internet explorer.
If a website doesn't work in Safari, it just doesn't work. That's it. I do know that devs have to work A LOT harder to get things to work in Safari when compared to Chrome or Firefox. It's like Safari is the new Internet explorer.
I last had it two days ago. Zencaster: requires Firefox or Chrome, won’t work with Safari.
> respect the conventions of the platform they're building for
Do you mean UI conventions, or the "30% revenue cut and a gag order on even mentioning non-appstore signups" convention?
Justifying blatant anticompetitive and user-hostile practices by native UI holyness is getting kinda old.
Do you mean UI conventions, or the "30% revenue cut and a gag order on even mentioning non-appstore signups" convention?
Justifying blatant anticompetitive and user-hostile practices by native UI holyness is getting kinda old.
This is a false dichotomy. People can dislike PWAs and be critical of AppStore practices at the same time.
People "can" do that but that's not what either the commenter or Apple is doing.
And it's a package deal anyway. As long as PWAs do not provide viable competition to App Store on iOS, you can criticize App Store till you're blue in the face and nothing will change. So if you choose to force native UI holyness on others, at least take the responsibility for what else this brings as well.
And it's a package deal anyway. As long as PWAs do not provide viable competition to App Store on iOS, you can criticize App Store till you're blue in the face and nothing will change. So if you choose to force native UI holyness on others, at least take the responsibility for what else this brings as well.
> People "can" do that but that's not what either the commenter or Apple is doing.
It’s not even remotely fair to pretend that HN commenters and Apple share the exact same interests. It’s not anyone besides Apple’s fault that they are doing what they’re doing in the AppStore.
> So if you choose to force native UI holyness on others, at least take the responsibility for what else this brings as well.
Again, what responsibility? The idea that anyone who dislikes PWA has to take “responsibility” for Apple’s actions is plain ridiculous to begin with.
Another thing I’d like to mention is that there are also reasons for disliking PWAs other than worshipping “UI holiness.” Honestly, I don’t care as much for that.
The main issue I have with the pro-PWA agenda is that it’s pushing for browsers to expand access to their underlying platforms. If browsers keep on doing this, we’d have to give websites the same trust we give to apps when we install them on our devices. This would mean the end of browsing as we know it because we’d have to think twice before choosing to click on a link.
It’s not even remotely fair to pretend that HN commenters and Apple share the exact same interests. It’s not anyone besides Apple’s fault that they are doing what they’re doing in the AppStore.
> So if you choose to force native UI holyness on others, at least take the responsibility for what else this brings as well.
Again, what responsibility? The idea that anyone who dislikes PWA has to take “responsibility” for Apple’s actions is plain ridiculous to begin with.
Another thing I’d like to mention is that there are also reasons for disliking PWAs other than worshipping “UI holiness.” Honestly, I don’t care as much for that.
The main issue I have with the pro-PWA agenda is that it’s pushing for browsers to expand access to their underlying platforms. If browsers keep on doing this, we’d have to give websites the same trust we give to apps when we install them on our devices. This would mean the end of browsing as we know it because we’d have to think twice before choosing to click on a link.
There's a difference between merely "disliking" something as a personal preference and insisting that other people should not have the things you dislike.
Neither the commenter I responded to nor Apple are simply "disliking" PWAs. Apple is not allowing PWAs to bolster their monopolistic moat, and the commenter is supporting Apple's decision to not allow _other people_ to build & use PWAs on iOS, seemingly just because they personally prefer native UX. Both of those are far beyond just "disliking".
This might seem like mere semantics about what "disliking" is, but while simply having personal preferences is fine, taking _actions_ that affect _other people_ or publicly expressing support for such actions necessarily comes with some moral responsibility for those actions I think. Perhaps some puny PWAs and their market effects aren't important enough for people to consider that, but the principle is all the same I would think.
Neither the commenter I responded to nor Apple are simply "disliking" PWAs. Apple is not allowing PWAs to bolster their monopolistic moat, and the commenter is supporting Apple's decision to not allow _other people_ to build & use PWAs on iOS, seemingly just because they personally prefer native UX. Both of those are far beyond just "disliking".
This might seem like mere semantics about what "disliking" is, but while simply having personal preferences is fine, taking _actions_ that affect _other people_ or publicly expressing support for such actions necessarily comes with some moral responsibility for those actions I think. Perhaps some puny PWAs and their market effects aren't important enough for people to consider that, but the principle is all the same I would think.
> This might seem like mere semantics about what "disliking" is
Yes it is. Because you have cherry-picked a single word out of my whole argument to make your point. I dedicated an entire paragraph describing the undesired consequences of going the PWA route and you refused to acknowledge it, claiming it's only the "UX" people are taking issues with.
Yes it is. Because you have cherry-picked a single word out of my whole argument to make your point. I dedicated an entire paragraph describing the undesired consequences of going the PWA route and you refused to acknowledge it, claiming it's only the "UX" people are taking issues with.
My original comment was in response to a particular commenter who did in fact imply that UI conventions were the reason. I even asked a question to clarify if that was the case. Snarky it was, but still a question. You have your own reason to not want PWAs, that's fine. Your reason is not the reason I'm protesting.
Not including your reason in my question does not make it a false dichotomy. I never stated that UI conventions were the _only_ reason to dislike PWAs, it was simply the only reason the commenter implied.
If _you_ think promoting walled gardens and Apple's monopolistic power is less of a problem than expanding browsers' scope of functionality, I disagree, but that's not what I came here to argue about, that doesn't have anything to do with my original comment that you have an issue with.
Not including your reason in my question does not make it a false dichotomy. I never stated that UI conventions were the _only_ reason to dislike PWAs, it was simply the only reason the commenter implied.
If _you_ think promoting walled gardens and Apple's monopolistic power is less of a problem than expanding browsers' scope of functionality, I disagree, but that's not what I came here to argue about, that doesn't have anything to do with my original comment that you have an issue with.
>My iOS device has never once shown me "this website requires Chrome."
Why would any PWA say that, if Safari had proper support for PWA?
>Instead it's web developers, who are just annoyed that they have to actually respect the conventions of the platform they're building for.
Say the developer is from a village in India or Nigeria who has just a Raspberry Pi to develop apps -
•What if the developer didn't have thousands of dollars to invest in new equipments just to develop for iOS?
•What if the developer wasn't able pay $99 every year for the Apple developer license?
•What if the just didn't want to give 30% cut to Apple from the revenue each time?
For all the times Apple uses 'Equality' in its marketing, the Apple platform & ecosystem restrictions clearly seems to be aimed at the privileged, pushing the agenda that 'Privileged is good' and 'Everyone should aim at being privileged'.
Less empathetic would respond, 'Well that's not Apple's fault that they aren't privileged'; Well then, we have to go back into colonial imperialism & American capitalism to prove why they aren't privileged in the first place and why Apple holds a responsibility every time it uses 'Equality, Human etc.' in it's marketing; which would be digressing from the topic.
Why would any PWA say that, if Safari had proper support for PWA?
>Instead it's web developers, who are just annoyed that they have to actually respect the conventions of the platform they're building for.
Say the developer is from a village in India or Nigeria who has just a Raspberry Pi to develop apps -
•What if the developer didn't have thousands of dollars to invest in new equipments just to develop for iOS?
•What if the developer wasn't able pay $99 every year for the Apple developer license?
•What if the just didn't want to give 30% cut to Apple from the revenue each time?
For all the times Apple uses 'Equality' in its marketing, the Apple platform & ecosystem restrictions clearly seems to be aimed at the privileged, pushing the agenda that 'Privileged is good' and 'Everyone should aim at being privileged'.
Less empathetic would respond, 'Well that's not Apple's fault that they aren't privileged'; Well then, we have to go back into colonial imperialism & American capitalism to prove why they aren't privileged in the first place and why Apple holds a responsibility every time it uses 'Equality, Human etc.' in it's marketing; which would be digressing from the topic.
> Why would any PWA say that, if Safari had proper support for PWA?
For the same reason that far too many desktop websites say that today.
> Say the developer is from a village in India or Nigeria who has just a Raspberry Pi to develop apps
Apple is not catering to this developer demographic.
> For all the times Apple uses 'Equality' in its marketing, the Apple platform & ecosystem restrictions clearly seems to be aimed at the privileged
You're conflating developers with users. What fraction of iPhone users are writing apps? If you wanted to prioritize users, there's much tougher questions you could ask.
For the same reason that far too many desktop websites say that today.
> Say the developer is from a village in India or Nigeria who has just a Raspberry Pi to develop apps
Apple is not catering to this developer demographic.
> For all the times Apple uses 'Equality' in its marketing, the Apple platform & ecosystem restrictions clearly seems to be aimed at the privileged
You're conflating developers with users. What fraction of iPhone users are writing apps? If you wanted to prioritize users, there's much tougher questions you could ask.
Parent said it's the web developers who argue for PWA, I just stated why they have reasons to do that.
Yeah, agreed. The web is now the most developer-friendly platform by far.
Ha. Using Foundation, Swift and SwiftUI I can write an app that doesn't require a trip to GitHub or Node.js in order to work properly. I can prototype my UI right there in Xcode, and if there's something I need that hasn't made it into SwiftUI yet I can bring in things from UIKit without very much effort. Best of all, I can build for macOS as well as iOS from the same codebase now. It's really hard to get more developer-friendly than that, unless you mean "web-developer-who-doesn't-want-to-learn-iOS-friendly".
This argument is a great example of straw man.
Or, a translation, this argument is BS.
99.9% of users don’t even know what a browser engine is. Why would they care that they’re using WebKit instead of gecko or chromium? What they want is their bookmarks and such to sync between browsers across devices, and Apple lets that work just fine.
As an iPhone user I actually like that all phones use the same engine. It prevents the “this website is better viewed in <browser>” pop up from affecting mobile users (and in particular it forces google to support a browser other than chrome). In other words, the engine monoculture means that making a site work for any iOS users means it will work for every iOS user, which I as a user really appreciate.
As an iPhone user I actually like that all phones use the same engine. It prevents the “this website is better viewed in <browser>” pop up from affecting mobile users (and in particular it forces google to support a browser other than chrome). In other words, the engine monoculture means that making a site work for any iOS users means it will work for every iOS user, which I as a user really appreciate.
In this regard, Apple reminds me of a cult leader brainwashing their followers into believing the cult's way is the best way. Makes me a little sick actually.
Are you sure you aren’t the one being brainwashed?
Why should anyone trust Google, since they make virtually all of their revenue from ad tech, which means tracking users across the web, even when they don't want to be. Advertisers are Google's customers, not the users of their browsers or operating systems.
And since Apple makes virtually all of their revenue from selling devices and services, who's more credible on the issue of privacy?
If we are to believe Apple cares about its users, then it makes perfect sense why they don't allow slower, less power efficient, less secure and less private web engines available on iOS.
"But shouldn't this be up to the user?" some will say ask. Yes, but to a point. There are already so many ways on the web to shoot yourself in the foot. Apple is making it clear that if you want a platform where there are no safeguards, then this isn't the platform for you.
There are certainly a tiny, vocal minority of iOS users who complain a lot about wanting the ability to shoot themselves in the foot if they so choose. But Apple knows those aren't their core users and their revenue show that.
They need to stop doing this, or they will hurt themselves in the long run.
People have been saying this for many years and now they're valued at over $1.5 trillion during an economic collapse and global pandemic. Please tell me when the lack of web APIs that would make it easier for their users to be tracked on the web is going to have any material effect on them.
Are you sure you aren’t the one being brainwashed?
Why should anyone trust Google, since they make virtually all of their revenue from ad tech, which means tracking users across the web, even when they don't want to be. Advertisers are Google's customers, not the users of their browsers or operating systems.
And since Apple makes virtually all of their revenue from selling devices and services, who's more credible on the issue of privacy?
If we are to believe Apple cares about its users, then it makes perfect sense why they don't allow slower, less power efficient, less secure and less private web engines available on iOS.
"But shouldn't this be up to the user?" some will say ask. Yes, but to a point. There are already so many ways on the web to shoot yourself in the foot. Apple is making it clear that if you want a platform where there are no safeguards, then this isn't the platform for you.
There are certainly a tiny, vocal minority of iOS users who complain a lot about wanting the ability to shoot themselves in the foot if they so choose. But Apple knows those aren't their core users and their revenue show that.
They need to stop doing this, or they will hurt themselves in the long run.
People have been saying this for many years and now they're valued at over $1.5 trillion during an economic collapse and global pandemic. Please tell me when the lack of web APIs that would make it easier for their users to be tracked on the web is going to have any material effect on them.
Oh man, not sure where to begin with responding to this.
I'm not saying Google is incredible (my opinion is quite the contrary actually). However, I am saying Apple is holding the web back, in a fairly annoying way, for developers.
The fact that they are a rich corporate does not mean they always will be, or that they're conducting their business in the best way possible. There are plenty of examples of rich tech businesses that lost their market share very quickly. We don't even need to look that far into the past for an example: BlackBerry sticks out in my mind. I believe their stubbornness and resistance to change caused their downfall. I feel it may be a similar fate for Apple, and for similar reasons, unless they change their attitude towards the web.
I'm not saying Google is incredible (my opinion is quite the contrary actually). However, I am saying Apple is holding the web back, in a fairly annoying way, for developers.
The fact that they are a rich corporate does not mean they always will be, or that they're conducting their business in the best way possible. There are plenty of examples of rich tech businesses that lost their market share very quickly. We don't even need to look that far into the past for an example: BlackBerry sticks out in my mind. I believe their stubbornness and resistance to change caused their downfall. I feel it may be a similar fate for Apple, and for similar reasons, unless they change their attitude towards the web.
"Holding the web back" lol. What the web is today, is coming straight out of Google's playbook, with WHATWG just a miniscule puppet organization consisting of Chrome devs promoting whatever Chrome does as standard. It's a scam to subvert what once was the web into a monopolistic tracking network and a 20 year project to morph a document viewer into the most absurd, power-inefficient, and clunky app platform imaginable that still can't do most anything that you'd want a smartphone to do, such as phoning. The narrative that big brother Google protects us from evil proprietary vendors somewhere lost its credibility; today, we need protection from Google more than anything else. Almost all new HTML5 APIs and even CSS can and will be used for fingerprinting so need to be rolled back or switched off anyway.
"Apple is holding the web back"
Nope, Apple is taking care of it's customers and protecting them from Google's ad exploitation.
"I feel it may be a similar fate for Apple, and for similar reasons, unless they change their attitude towards the web"
On the contrary, if Apple allowed this web Wild West that Google is advocating, then the users would have incentive to switch. This move from Apple actually ensures that things run smoothly on Apple devices.
It is not about "power for web developers", it is web developers being lazy to self-educate and learn other stacks.
There is skill called "desktop development" and it does not entail Electron.
Luckily Apple is not gonna let that happen with the mobile apps and the PWA.
Nope, Apple is taking care of it's customers and protecting them from Google's ad exploitation.
"I feel it may be a similar fate for Apple, and for similar reasons, unless they change their attitude towards the web"
On the contrary, if Apple allowed this web Wild West that Google is advocating, then the users would have incentive to switch. This move from Apple actually ensures that things run smoothly on Apple devices.
It is not about "power for web developers", it is web developers being lazy to self-educate and learn other stacks.
There is skill called "desktop development" and it does not entail Electron.
Luckily Apple is not gonna let that happen with the mobile apps and the PWA.
But Apple's app store is full of junk too - it is a veritable wild west in its own right.
You have the likes of Tiktok on there, collecting way more data than a PWA ever could. Do Apple not care about that?
Feels like a bit of a double standard on privacy, explicitly aimed at stifling the web.
You have the likes of Tiktok on there, collecting way more data than a PWA ever could. Do Apple not care about that?
Feels like a bit of a double standard on privacy, explicitly aimed at stifling the web.
>Nope, Apple is taking care of it's customers and protecting them from Google's ad exploitation.
Apple is "protecting" its customers by restricting and patronising them like little children. Privacy by default is good, but many of their restrictions are clearly aimed at rent seeking.
Where customers really need protection, Apple is stabbing them in the back by aiding and abetting human rights abuses with their pointless side-loading ban and their willingness to let dictators run their own iCloud service.
Apple is "protecting" its customers by restricting and patronising them like little children. Privacy by default is good, but many of their restrictions are clearly aimed at rent seeking.
Where customers really need protection, Apple is stabbing them in the back by aiding and abetting human rights abuses with their pointless side-loading ban and their willingness to let dictators run their own iCloud service.
> I'm not saying Google is incredible (my opinion is quite the contrary actually). However, I am saying Apple is holding the web back, in a fairly annoying way, for developers.
Right. Because Google, who dominates the entire web standards spectrum, is known for creating well thought-out, well-designed APIs that take into consideration concerns and criticism, and thinking long-term of the web as a whole.
Oh wait, they don't. Up to and including the point where both Mozilla and Safari are saying they won't implement certain functionality because of glaring holes in the design, and Chrome not only shipping the features, but making them GA.
Oh, and yes. Most of the "Safari is holding back web developers" talk is bullshit, of course. It actually should read "Chrome releases APIs at neck breaking speed with zero concerns for the future of the web." See web API counts in major browsers: https://web-confluence.appspot.com/#!/confluence
Right. Because Google, who dominates the entire web standards spectrum, is known for creating well thought-out, well-designed APIs that take into consideration concerns and criticism, and thinking long-term of the web as a whole.
Oh wait, they don't. Up to and including the point where both Mozilla and Safari are saying they won't implement certain functionality because of glaring holes in the design, and Chrome not only shipping the features, but making them GA.
Oh, and yes. Most of the "Safari is holding back web developers" talk is bullshit, of course. It actually should read "Chrome releases APIs at neck breaking speed with zero concerns for the future of the web." See web API counts in major browsers: https://web-confluence.appspot.com/#!/confluence
> Up to and including the point where both Mozilla and Safari are saying they won't implement certain functionality because of glaring holes in the design, and Chrome not only shipping the features, but making them GA.
I feel this is being dismissed by many people, but there's a lot of truth in this statement. Here's an example of this at play:
https://twitter.com/Rich_Harris/status/1220412711768666114
Chrome devrels and cheerleaders pile on Safari and Firefox all the time for not adhering to Chrome's agenda and frame it as "holding the web back." But the true thing that holds the web back is a browser monoculture.
I feel this is being dismissed by many people, but there's a lot of truth in this statement. Here's an example of this at play:
https://twitter.com/Rich_Harris/status/1220412711768666114
Chrome devrels and cheerleaders pile on Safari and Firefox all the time for not adhering to Chrome's agenda and frame it as "holding the web back." But the true thing that holds the web back is a browser monoculture.
Why, then, did it take safari so long to implement ServiceWorkers? I believe they were the last of major browsers to implement it. And they landed the feature more than 2 years after Firefox!
Also, why was Safari's IndexedDB feature released nearly 4 years after the other major browsers? And when released it, why was it full of bugs that simple test cases would have caught?
I don't want to fuel conspiracies, but the pattern is fairly obvious. Apple appears to resist progress in Web APIs.
Also, why was Safari's IndexedDB feature released nearly 4 years after the other major browsers? And when released it, why was it full of bugs that simple test cases would have caught?
I don't want to fuel conspiracies, but the pattern is fairly obvious. Apple appears to resist progress in Web APIs.
> Why, then, did it take safari so long to implement ServiceWorkers?
> Also, why was Safari's IndexedDB feature released
Priorities. Safari's team isn't as big as Chrome's.
> but the pattern is fairly obvious.
The only obvious pattern is the link I provided. And things like this:
- Chrome releasing APIs even when other vendors are against: https://twitter.com/Rich_Harris/status/1220412711768666114
- Chrome sabotaging competitors with shady practices: http://archive.is/tgIH9
and there are many many many more examples of this behaviour.
Priorities. Safari's team isn't as big as Chrome's.
> but the pattern is fairly obvious.
The only obvious pattern is the link I provided. And things like this:
- Chrome releasing APIs even when other vendors are against: https://twitter.com/Rich_Harris/status/1220412711768666114
- Chrome sabotaging competitors with shady practices: http://archive.is/tgIH9
and there are many many many more examples of this behaviour.
What about Firefox? Is Safari's team smaller than Firefox's as well?
Looking at this page: https://webkit.org/team/ and comparing it to https://wiki.mozilla.org/Firefox/Team/whois would suggest otherwise.
Do you have numbers from elsewhere to back up that claim?
Btw, I'm not saying Google are right to power through with poorly designed APIs either, but when there is a standard in place, why Safari takes sooo long to implement it is perplexing (or perhaps just a rather obvious strategy).
Looking at this page: https://webkit.org/team/ and comparing it to https://wiki.mozilla.org/Firefox/Team/whois would suggest otherwise.
Do you have numbers from elsewhere to back up that claim?
Btw, I'm not saying Google are right to power through with poorly designed APIs either, but when there is a standard in place, why Safari takes sooo long to implement it is perplexing (or perhaps just a rather obvious strategy).
> Is Safari's team smaller than Firefox's as well?
Unknown
> but when there is a standard in place, why Safari takes sooo long to implement it is perplexing
Some standards are so bad, even Chrome ends up deprecating them (see Custom Elements v0).
Or they just go out of favor (see HTML Imports).
Or they are so poorly specified that even years after "becoming a standard" they have things like "this section is not specified yet" in their texts. And the status of these "standards" is often not above "Candidate Recommendation" (that is it is gathering implementation experience, and yes, that refers to Service Workers).
BTW Service Workers were moved to Candidate Recommendation about half a year ago: https://github.com/w3c/ServiceWorker/issues/1460 ("Double check everyone is happy with v1 going to CR.")
So yeah, I don't know what to say. Safari isn't chasing every API under the sun? Good for them. Web Devs assuming that whatever's in Chrome is the be all end all standards on the web? Bad for the web and for the devs. Apple possibly not prioritising Safari? Bad for the web as well.
Unknown
> but when there is a standard in place, why Safari takes sooo long to implement it is perplexing
Some standards are so bad, even Chrome ends up deprecating them (see Custom Elements v0).
Or they just go out of favor (see HTML Imports).
Or they are so poorly specified that even years after "becoming a standard" they have things like "this section is not specified yet" in their texts. And the status of these "standards" is often not above "Candidate Recommendation" (that is it is gathering implementation experience, and yes, that refers to Service Workers).
BTW Service Workers were moved to Candidate Recommendation about half a year ago: https://github.com/w3c/ServiceWorker/issues/1460 ("Double check everyone is happy with v1 going to CR.")
So yeah, I don't know what to say. Safari isn't chasing every API under the sun? Good for them. Web Devs assuming that whatever's in Chrome is the be all end all standards on the web? Bad for the web and for the devs. Apple possibly not prioritising Safari? Bad for the web as well.
Developer experience needs to be good enough. Beyond that it’s in the platform owners interest to keep them on a tight leash.
The android ecosystem demonstrates that freedom isn’t necessarily creating a materially better ecosystem.
Blackberry was a different problem — they saw themselves as a messaging platform that did some other stuff.
The android ecosystem demonstrates that freedom isn’t necessarily creating a materially better ecosystem.
Blackberry was a different problem — they saw themselves as a messaging platform that did some other stuff.
Where did privacy come in this discussion?
If you are going to be fear-mongering based on vague assertions and appeals to business models, it would be wise to mention the 30% fee on all digital transactions that Apple extorts from all its apps. It is very clear that Apple doesn't want to lose that control (and revenue) to the Web, which despite the attempts of all corporations (including at times Google), still manages to be a little more open than our corporate overlords would like.
If you are going to be fear-mongering based on vague assertions and appeals to business models, it would be wise to mention the 30% fee on all digital transactions that Apple extorts from all its apps. It is very clear that Apple doesn't want to lose that control (and revenue) to the Web, which despite the attempts of all corporations (including at times Google), still manages to be a little more open than our corporate overlords would like.
Some people are happy to buy the Apple speil re privacy to knock web apps, all while using apps like Tiktok that'll probably violate their privacy much more than a PWA ever could.
The privacy argument is without basis, imo. Google is terrible on privacy too, and somewhat evil, and its browser is terrible at managing memory (I say this to prove I'm not a Google fanboy!) but at least it's not stifling innovation on the web.
The privacy argument is without basis, imo. Google is terrible on privacy too, and somewhat evil, and its browser is terrible at managing memory (I say this to prove I'm not a Google fanboy!) but at least it's not stifling innovation on the web.
There are people who don't want Google's "innovations" as they turn browsers into monstrosities that nobody except Google can maintain, and already have turned the web into the pile of shit of content marketing (with like 500 trackers on every site), service lock-in, cesspool of polarizing clickbait and propaganda, hopeless web app crap, and place where content creators get screwed that it is today. Saying this as someone with a very heavy time investment into web tech. Compare this with the useful web we used to have 10 years ago. Apple is no saint, but there's a difference between resistance to social-engineer open standards into a monopolistic enslavement machine and race to the bottom vs "stifling innovation".
> If we are to believe Apple cares about its users, then it makes perfect sense why they don't allow slower, less power efficient, less secure and less private web engines available on iOS.
Caring would mean giving people a choice. The real reason is they're pivoting into services and other forms of recurring revenue. They don't want people building platform-independent apps that don't need Apple approval and can bill outside of their 30% cut.
Caring would mean giving people a choice. The real reason is they're pivoting into services and other forms of recurring revenue. They don't want people building platform-independent apps that don't need Apple approval and can bill outside of their 30% cut.
> [...] why they don't allow slower, less power efficient, less secure and less private web engines available on iOS
Do you have a source that shows how chromium/edge/firefox/etc are inferior to safari in this regard?
Do you have a source that shows how chromium/edge/firefox/etc are inferior to safari in this regard?
For pure speed of the web + Javascript engines: "Introducing the JetStream 2 Benchmark Suite": https://webkit.org/blog/8685/introducing-the-jetstream-2-ben...
Anyone with a MacBook or MacBook Pro can attest to the fact their battery last significantly longer using Safari vs Firefox or Chrome. Apple has numbers on the Safari page: https://www.apple.com/safari/
You can run EFF’s Panopticlick test for what browsers block (or don't block) regarding fingerprinting. Safari blocks or disguises several features that are used for fingerprinting; Chrome blocks nothing: https://panopticlick.eff.org/
Anyone with a MacBook or MacBook Pro can attest to the fact their battery last significantly longer using Safari vs Firefox or Chrome. Apple has numbers on the Safari page: https://www.apple.com/safari/
You can run EFF’s Panopticlick test for what browsers block (or don't block) regarding fingerprinting. Safari blocks or disguises several features that are used for fingerprinting; Chrome blocks nothing: https://panopticlick.eff.org/
Mozilla's arewefastyet.com used to show daily benchmark results for all major browser engines. Sadly, it ceased to include Safari after they scrapped the system in favor of a new one.
https://github.com/mozilla/arewefastyet
https://github.com/mozilla/arewefastyet
>If we are to believe Apple cares about its users, then it makes perfect sense why they don't allow slower, less power efficient, less secure and less private web engines available on iOS.
Woah![1]
> "But shouldn't this be up to the user?" some will say ask. Yes, but to a point. There are already so many ways on the web to shoot yourself in the foot.
That sounds exactly like what a dictator would say when asked why the citizens are not allowed to vote.
[1]https://googleprojectzero.blogspot.com/2018/10/365-days-late...
Woah![1]
> "But shouldn't this be up to the user?" some will say ask. Yes, but to a point. There are already so many ways on the web to shoot yourself in the foot.
That sounds exactly like what a dictator would say when asked why the citizens are not allowed to vote.
[1]https://googleprojectzero.blogspot.com/2018/10/365-days-late...
> Why should anyone trust Google, since they make virtually all of their revenue from ad tech, which means tracking users across the web, even when they don't want to be. Advertisers are Google's customers, not the users of their browsers or operating systems.
We don't need this whataboutism to evaluate Apple. You're making the argument for PureOS or Debian, not iOS.
> If we are to believe Apple cares about its users, then it makes perfect sense why they don't allow slower, less power efficient, less secure and less private web engines available on iOS.
No it doesn't. They could make a better browser and, if it was actually better in every way, nobody would have any reason to use anything else. The fact that people would given the choice implies that something about choosing differently makes them better off enough to switch from the default.
> Apple is making it clear that if you want a platform where there are no safeguards, then this isn't the platform for you.
Safeguards mean warning someone adequately when they're about to do something suspect. Outright prohibiting the user from making an informed choice isn't a safeguard, it's a cage.
> People have been saying this for many years and now they're valued at over $1.5 trillion
Exxon was at one point the most valuable company on the exchange as well. What does that tell you about the ethics of how they got there, or what their future prospects look like?
We don't need this whataboutism to evaluate Apple. You're making the argument for PureOS or Debian, not iOS.
> If we are to believe Apple cares about its users, then it makes perfect sense why they don't allow slower, less power efficient, less secure and less private web engines available on iOS.
No it doesn't. They could make a better browser and, if it was actually better in every way, nobody would have any reason to use anything else. The fact that people would given the choice implies that something about choosing differently makes them better off enough to switch from the default.
> Apple is making it clear that if you want a platform where there are no safeguards, then this isn't the platform for you.
Safeguards mean warning someone adequately when they're about to do something suspect. Outright prohibiting the user from making an informed choice isn't a safeguard, it's a cage.
> People have been saying this for many years and now they're valued at over $1.5 trillion
Exxon was at one point the most valuable company on the exchange as well. What does that tell you about the ethics of how they got there, or what their future prospects look like?
I wish that Apple had better support for PWAs and allowed alternative rendering engines. The issue is that they are the only major player in mobile that cares about user privacy, and this allows them to maintain their monopoly for many users.
If the option is Android + first-class support for PWAs vs. Apple with limited support for PWAs, I’ll go for the latter every time.
If the option is Android + first-class support for PWAs vs. Apple with limited support for PWAs, I’ll go for the latter every time.
Microsoft has also heavily invested in the web ecosystem via VSCode, TypeScript, and NPM. Not to mention that Office is now chiefly a web app. My guess is that, among other things, they see it as a way to cultivate fields adjacent to Azure and attract customers to it.
New leadership definitely helps. Satya seems to want to move past the old way of doing things at Microsoft as aggressively as possible.
PWAs would be very off brand for iOS. It would allow all kinds of spammy low-quality apps to masquerade as iOS apps without any vetting from Apple.
Part of Apple's success is their extreme stubbornness. They decide something and make zero compromises. The consumer tech industry is forced to fall in line with whatever they want; they have final veto power over all new consumer tech basically.
Part of Apple's success is their extreme stubbornness. They decide something and make zero compromises. The consumer tech industry is forced to fall in line with whatever they want; they have final veto power over all new consumer tech basically.
You describe the iOS app store as some kind of zen garden of curated software, when it's full off the same kind of spammy apps that pollute other app stores. When the app inventory numbers in the million plus, it is impossible for every one to be reviewed for quality, or to be distinct from others already in the store.
The purpose of the App Store was to ensure that Apple got a cut of every dollar flowing through the store. Gatekeeping quality requires more than blocking developers from uploading fart apps.
The purpose of the App Store was to ensure that Apple got a cut of every dollar flowing through the store. Gatekeeping quality requires more than blocking developers from uploading fart apps.
Yea, some people have rose-tinted glasses when it comes to Apple.
I downloaded a simple HIIT (high-intensity interval training) timer app the other day. It's just a glorified stop timer that automatically pauses at intervals so you can do exercise-rest cycles.
I settled for the second or third most popular alternative since it was the first one that didn't have a HIIT-timer-as-a-service business model (WTF... no, I don't want to create an account for a timer app).
Still a disgusting experience. Before you start an exercise there's an obnoxious 10-second video ad playing at full blast. The interface is atrocious, too.
The app was free, so I can't complain on that front, I guess. I would pay $3-$6 flat for something like this, but herein lies the problem: I can't even find such an alternative. The results in the app store search were filled with garbage (SaaS as I mentioned, irrelevant crap, bloated "fitness assistant" apps, etc.)
I could definitely conceive this app being built as a PWA and being 100x better than many of those. For this use case I couldn't care less about PWA vs. native, both could work if done well; the point is that I really don't see what Apple's supposedly strict standards have done to protect my user experience from greedy, incompetent or careless designers and developers.
I downloaded a simple HIIT (high-intensity interval training) timer app the other day. It's just a glorified stop timer that automatically pauses at intervals so you can do exercise-rest cycles.
I settled for the second or third most popular alternative since it was the first one that didn't have a HIIT-timer-as-a-service business model (WTF... no, I don't want to create an account for a timer app).
Still a disgusting experience. Before you start an exercise there's an obnoxious 10-second video ad playing at full blast. The interface is atrocious, too.
The app was free, so I can't complain on that front, I guess. I would pay $3-$6 flat for something like this, but herein lies the problem: I can't even find such an alternative. The results in the app store search were filled with garbage (SaaS as I mentioned, irrelevant crap, bloated "fitness assistant" apps, etc.)
I could definitely conceive this app being built as a PWA and being 100x better than many of those. For this use case I couldn't care less about PWA vs. native, both could work if done well; the point is that I really don't see what Apple's supposedly strict standards have done to protect my user experience from greedy, incompetent or careless designers and developers.
> You describe the iOS app store as some kind of zen garden of curated software, when it's full off the same kind of spammy apps that pollute other app stores
Yeah, it's disgusting.
> The purpose of the App Store was to ensure that Apple got a cut of every dollar flowing through the store
I think there were competing internal forces: a desire to milk the iPhone's success, vs something akin to an Apple retail store experience. Sadly they gave us the worst of both worlds: they freely admit shit, yet pick fights with good stuff, like Basecamp Hey mail.
It makes no sense why Apple would choose to defend this hill. Either make it a Zen garden or turn it to a web-style free-for-all.
Yeah, it's disgusting.
> The purpose of the App Store was to ensure that Apple got a cut of every dollar flowing through the store
I think there were competing internal forces: a desire to milk the iPhone's success, vs something akin to an Apple retail store experience. Sadly they gave us the worst of both worlds: they freely admit shit, yet pick fights with good stuff, like Basecamp Hey mail.
It makes no sense why Apple would choose to defend this hill. Either make it a Zen garden or turn it to a web-style free-for-all.
The stubbornness of iOS is a large part of why PWAs haven't been broadly adopted.
At some point their hardline stance will backfire.
At some point their hardline stance will backfire.
Yeah yeah, PWAs will win. Any day day now.
They have beeb winning for ten years already.
The very first third party apps on iPhone were PWAs.
iPhone was the place where canvas and CSS animations, etc. first appeared. Yet when SDK appeared developers and users preferred native. With a reason.
By the way, the Bing Covid PWA has been published to the Microsoft Store using Pwabuilder.com ;)
I really wish that firefox and ubuntu would hop on board with this. It seems like they both should be at the forefront of this, but for some reason it's still impossible to make a PWA show up in my app list on ubuntu without installing chrome.
Firefox on android does a great job of notifying and offering to install PWAs, but on desktop seems to pretend they don't exist. The bug report for adding any PWA support on desktop has been languishing for years. And as far as i can tell, the ubuntu software center team doesn't believe that PWAs exist at all.
it seems crazy to me that there's no functionality built into ubuntu that allows me to add youtube to the app list.
Firefox on android does a great job of notifying and offering to install PWAs, but on desktop seems to pretend they don't exist. The bug report for adding any PWA support on desktop has been languishing for years. And as far as i can tell, the ubuntu software center team doesn't believe that PWAs exist at all.
it seems crazy to me that there's no functionality built into ubuntu that allows me to add youtube to the app list.
Whatever happened to the Mozilla that made FirefoxOS. Just to soon I guess.
FirefoxOS lives on in KaiOS. But that's probably not very open source
I know what happened to FirefoxOS. But the Mozilla that was willing to invest in a web app first mobile OS and all the web capabilities needed to make that great seems to be completely gone.
Now they seem to have given up on the promise of the web as an app delivery platform and have aligned with Apple on a pro-privacy stance that seems based more on posturing than safely providing capabilities.
Now they seem to have given up on the promise of the web as an app delivery platform and have aligned with Apple on a pro-privacy stance that seems based more on posturing than safely providing capabilities.
Yes, would be cool.
Firefox is currently unusable on mobile :/
Firefox is currently unusable on mobile :/
I'm going to guess you're on iOS where you don't actually have Firefox (or any other actual browsers besides Safari). Firefox on iOS (like all iOS browsers) is required by App store rules to basically just skin Safari.
On Android, Firefox is the MOST usable browser.
On Android, Firefox is the MOST usable browser.
Surfing on Firefox Android ATM, and it has the same issues it has on the desktop of sites glitching out - just even harder to work arround on mobile.
I'm car shopping and downloading specs from multiple dealers straight out doesn't work - the downloaded PDF won't open, works like a charm in Chrome.
Stuff like this is why I suspect most non tech people would revert to Chrome pretty fast.
I'm car shopping and downloading specs from multiple dealers straight out doesn't work - the downloaded PDF won't open, works like a charm in Chrome.
Stuff like this is why I suspect most non tech people would revert to Chrome pretty fast.
I've been using Firefox for years and never run into any consistent pattern of things not working, except in cases where applications intentionally do not support Firefox and push me over to Chrome. Those I blame less on Firefox than on companies wanting to eliminate a customer support variable.
I’m typing this in Firefox on iOS and it works great for me, so perhaps the comment was slightly out-of-date? Also just put Firefox Developer Edition on my new MacBook and it feels much smoother than Firefox from a year ago.
Firefox on iOS is not actually Firefox.
Then why doesn't anyone use it? Honest question - Mobile Firefox stands at less than half a percentage point marketshare.
Just speculation on my part but... On Android, the default (Chrome) is good enough that most people won't think of trying something else, and on iOS Safari is really your only choice anyway.
Play Store licensing requires Chrome to be installed
It's just not as responsive as Chrome :/
I find Firefox Preview (with ublock origin enabled) to be the most usable of all the mobile browsers i've tried.
Chrome has a few nice things going for it, but i'd rather have ublock.
Chrome has a few nice things going for it, but i'd rather have ublock.
I can somewhat understand why they decided to do the total rewrite, but to my mind it still suffers from all the things described in Spolsky's "Things-You-Should-Never-Do": A standstill on the old version for a very long time (actually that already preceeded the rewrite somwhat, though the latter certainly didn't help in that regard), lots of missing features in the new version (each of which might – mostly – only be a small feature when viewed individually, but taken together it's still a noticeable bit that's currently missing), and of course a number of bugs introduced through the rewrite that need to be ironed out once again (occasionally quite literally "once again").
I liked FFP's main UI, but that was it.
Major websites wouldn't work properly (Twitter) and sharing images directly from a website (memes are my bread and butter) also didn't work.
I use Chrome with NextDNS on Android.
Major websites wouldn't work properly (Twitter) and sharing images directly from a website (memes are my bread and butter) also didn't work.
I use Chrome with NextDNS on Android.
I have no issues with those things on preview now. It has been a tiny bit unstable but it's getting better
For me, uBlock origin is the only thing that makes browsing the web even remotely okay on mobile. Its ability to block large images is a complete game changer for me.
Maybe it's because I've got an "old" phone (4 years ish), but Chrome's insisting that I must download everything a website throws at my made it extremely difficult to use comfortably. As soon as I found out Firefox had extensions on mobile, I switched both my desktop and mobile browsers, and it's been great.
Maybe it's because I've got an "old" phone (4 years ish), but Chrome's insisting that I must download everything a website throws at my made it extremely difficult to use comfortably. As soon as I found out Firefox had extensions on mobile, I switched both my desktop and mobile browsers, and it's been great.
I am very excited about the idea of both of these monsters actually getting behind PWA. One can only wonder about their motivations (i.e. anti-trust heating up), but I will take whatever I can get at this point.
To me, full support for PWA across all vendors' app stores would represent a revolution in the ability for hobbyists and small development shops to publish incredible applications.
Has HN not been published as a PWA to the various app stores yet? This seems like an obvious use case and could serve as a great example for other applications.
To me, full support for PWA across all vendors' app stores would represent a revolution in the ability for hobbyists and small development shops to publish incredible applications.
Has HN not been published as a PWA to the various app stores yet? This seems like an obvious use case and could serve as a great example for other applications.
PWA = Progressive Web Apps
A progressive web application is a type of application software delivered through the web, built using common web technologies including HTML, CSS and JavaScript.
A progressive web application is a type of application software delivered through the web, built using common web technologies including HTML, CSS and JavaScript.
So it’s a new name for a website?
Yes and no. That's a website that need to check some requirements to be called PWA.
- Fast (cache with service worker)
- Reponsive (no explanation needed)
- Offline page (so if the user lost connection or the web site is cached and he visite when he's no connection the app should work or at least display a custom offline page)
- Engaging (fancy word, to say it's need to behave like an app + push notifications)
- Installable (if the browser is compatible and you visite the website more than once it'll ask you if you want to install the app. This will create a shortcut and when you click on it it'll open like an app (no address bar))
But Apple is very late and don't support all of this.
- Fast (cache with service worker)
- Reponsive (no explanation needed)
- Offline page (so if the user lost connection or the web site is cached and he visite when he's no connection the app should work or at least display a custom offline page)
- Engaging (fancy word, to say it's need to behave like an app + push notifications)
- Installable (if the browser is compatible and you visite the website more than once it'll ask you if you want to install the app. This will create a shortcut and when you click on it it'll open like an app (no address bar))
But Apple is very late and don't support all of this.
Admittedly it might be my fault for living under a rock, but I don't know what PWA stands for. The fact that the linked article uses the acronym without ever writing out its long form even once rubs me the wrong way. For those like me who are in the dark: https://en.wikipedia.org/wiki/Progressive_web_application
PWA are applications which use certain features: offline mode, service workers, notification API and other browser APIs. They utilise many browser features and behave more like native applications than web, except running in a browser.
Really vague concept without strict definition.
Really vague concept without strict definition.
It stands for Poor-experience Web Applications. It’s basically website + more JavaScript to get some features somewhat working without network. It’s marketed as the next generation tech for mobile web application but the truth is that without access to the underlying API it’s hard to even get close to native capabilities. And as the web is already super bloated I don’t think it would be a good idea to add more.
Finally, someone who puts it, a website must be a website, an app must be an app. I don't understand why people go crazy for an abomination of dead service workers for something that runs on APIs almost all the time.
I strongly disagree. You have access to a lot of API and even more thanks to project Fugu. We have Web Assembly (WASM), WebGL 2 (soon WebGPU), etc. Check out this article: https://www.davrous.com/2019/10/18/myth-busting-pwas-the-new...
I remember when the microsoft app store on windows 8 were a bunch of websites wrapped into an app. It really lowered the quality of apps and the overall appeal of the windows app store.
That being said, how will PWAs get around the apple and google requirements that apps downloadable from their stores where they mention apps can't just be a website wrapped into an app?
That being said, how will PWAs get around the apple and google requirements that apps downloadable from their stores where they mention apps can't just be a website wrapped into an app?
> "It really lowered the quality of apps and the overall appeal of the windows app store...how will PWAs get around the apple and google requirements that apps downloadable from their stores where they mention apps can't just be a website wrapped into an app"
Fair question. Google is implementing a new quality bar for PWAs in their store. See this post[0] for details.
Microsoft also is doing work in this area. We're not ready to share details, but will likely in the coming months.
With PWABuilder, our goal is to help devs build quality PWAs: ones with rich offline experiences, measurably great performance, and apps that are functionally rich. This implies something more than e.g. your resume packaged as a PWA. Towards that end, PWABuilder analyzes your PWA and gives you feedback on capabilities: encourages use of our rich web components[1], helps you build a great offline experience[2], and more. Whether your app is functionally useful (i.e. not just a brochure) is a quality bar left to app stores themselves.
[0]: https://twitter.com/ChromiumDev/status/1276223634550353920
[1]: https://components.pwabuilder.com
[2]: https://www.pwabuilder.com/serviceworker
Fair question. Google is implementing a new quality bar for PWAs in their store. See this post[0] for details.
Microsoft also is doing work in this area. We're not ready to share details, but will likely in the coming months.
With PWABuilder, our goal is to help devs build quality PWAs: ones with rich offline experiences, measurably great performance, and apps that are functionally rich. This implies something more than e.g. your resume packaged as a PWA. Towards that end, PWABuilder analyzes your PWA and gives you feedback on capabilities: encourages use of our rich web components[1], helps you build a great offline experience[2], and more. Whether your app is functionally useful (i.e. not just a brochure) is a quality bar left to app stores themselves.
[0]: https://twitter.com/ChromiumDev/status/1276223634550353920
[1]: https://components.pwabuilder.com
[2]: https://www.pwabuilder.com/serviceworker
That clearly isn't the case for Google, as you can package PWAs for the store.
https://developers.google.com/web/android/trusted-web-activi...
https://developers.google.com/web/android/trusted-web-activi...
The main problem I see in PWAs these days is that they cannot permanently store data on the device. As soon as the user deletes their "browser data", all the data of the PWAs on the device is lost too.
If PWAs would get their own permanent storage like other apps, it would be a huge step forward.
If PWAs would get their own permanent storage like other apps, it would be a huge step forward.
PWAs are designed with the web/cloud in mind. The permanent data should be hosted in the cloud.
One of the issues is that storage in a PWA is done via localStorage or IndexedDB... both of which aren't really available outside of the browser.
Also, part of the benefit of a PWA is being able to be in mobile devices and 'storage' there is different than on the desktop.
One of the issues is that storage in a PWA is done via localStorage or IndexedDB... both of which aren't really available outside of the browser.
Also, part of the benefit of a PWA is being able to be in mobile devices and 'storage' there is different than on the desktop.
Certainly it's true PWAs are subject to the user's desires about browser data. I think that's a good thing for users.
PWAs usually store client-side data as a kind of cache: cookies, local storage, service worker cache. Caches are not meant to be permanent.
There may be room for improvement here, however. One might imagine that clearing browser data shouldn't clear data for installed PWAs. That's an argument worth further evaluation.
PWAs usually store client-side data as a kind of cache: cookies, local storage, service worker cache. Caches are not meant to be permanent.
There may be room for improvement here, however. One might imagine that clearing browser data shouldn't clear data for installed PWAs. That's an argument worth further evaluation.
It's only marginally subject to the user's desires. I wrote a fairly popular PWA and the most common questions users have are...
"Why did all my data get deleted? How can I get it back?"
and
"Why is it saying the browser won't let me store more data?"
The user's desires are pretty clear in both cases, but it's very unclear how the user can get what they want.
"Why did all my data get deleted? How can I get it back?"
and
"Why is it saying the browser won't let me store more data?"
The user's desires are pretty clear in both cases, but it's very unclear how the user can get what they want.
Can you elaborate why it could be a good thing for users?
Not being able to reliably store data on the device means that PWAs have to send the users data over the internet and store it on an external server. I would think users rather do not like that.
I am only talking about installed PWAs here. Of course not every website should be able to avoid having its cookies deleted.
Not being able to reliably store data on the device means that PWAs have to send the users data over the internet and store it on an external server. I would think users rather do not like that.
I am only talking about installed PWAs here. Of course not every website should be able to avoid having its cookies deleted.
"Good for users" was in the context of PWAs, not installed PWAs. Clearly the user's expectation is that clearing browsing data will clear data for web apps they navigate to in the browser.
Installed PWAs is another question. I suspect users will be surprised if they clear their browsing data only to discover they have to login again to Twitter, for example.
I may raise this question to the Edge Chromium team. I'm certain it's been raised before, but with Microsoft making PWAs first-class on Windows[0], this becomes a more prominent issue.
[0]: https://www.windowscentral.com/heres-how-microsoft-making-ed...
Installed PWAs is another question. I suspect users will be surprised if they clear their browsing data only to discover they have to login again to Twitter, for example.
I may raise this question to the Edge Chromium team. I'm certain it's been raised before, but with Microsoft making PWAs first-class on Windows[0], this becomes a more prominent issue.
[0]: https://www.windowscentral.com/heres-how-microsoft-making-ed...
Keeping the user logged in is not the issue. A PWA can inject a unique ID into the installation in various ways.
The problem is the data. Imagine a text editor where all your text documents are gone after you cleared the data of a different app, the browser.
I wrote a fitness app as a PWA some time ago and its pretty annoying to download all the instruction videos again every time you clear your "browser data". Plus all infos about which exercises you did and when is gone for good of course.
The problem is the data. Imagine a text editor where all your text documents are gone after you cleared the data of a different app, the browser.
I wrote a fitness app as a PWA some time ago and its pretty annoying to download all the instruction videos again every time you clear your "browser data". Plus all infos about which exercises you did and when is gone for good of course.
> "Imagine a text editor where all your text documents are gone after you cleared the browser data"
One way to address that issue is the native file system access APIs[0] coming soon, available today in Chrome Canary and Edge Canary. There, you'd be able to save your documents to the user's file system, just like a native app would. Those files will be exempt from any browser data clearing.
> all infos about which exercises you did and when is gone for good of course.
Might be good to store that data on the server. I realize not all PWAs have a proper backend server, but that sounds like a good candidate.
[0]: https://bugs.chromium.org/p/chromium/issues/detail?id=853326
One way to address that issue is the native file system access APIs[0] coming soon, available today in Chrome Canary and Edge Canary. There, you'd be able to save your documents to the user's file system, just like a native app would. Those files will be exempt from any browser data clearing.
> all infos about which exercises you did and when is gone for good of course.
Might be good to store that data on the server. I realize not all PWAs have a proper backend server, but that sounds like a good candidate.
[0]: https://bugs.chromium.org/p/chromium/issues/detail?id=853326
> Native File System API
Great, so there is light at the end of the tunnel!
> store that data on the server
Well, we talked about that already:
https://news.ycombinator.com/item?id=23793541
Great, so there is light at the end of the tunnel!
> store that data on the server
Well, we talked about that already:
https://news.ycombinator.com/item?id=23793541
> native file system access APIs[0]
Come on, stop giving people false hope, that API is like 3rd incarnation of the same thing by Google, always shot down by Mozilla and Apple. Even today if you restrict yourself to Chrome your PWA can use the older version of the same thing, but what's the point if that works only in Chrome?
Come on, stop giving people false hope, that API is like 3rd incarnation of the same thing by Google, always shot down by Mozilla and Apple. Even today if you restrict yourself to Chrome your PWA can use the older version of the same thing, but what's the point if that works only in Chrome?
Also, as mentioned elsewhere in this thread, you may also be interested in the Persistent Storage APIs: https://web.dev/persistent-storage/
From how I read it, this reduces the probability that the data gets deleted due to low disk space / garbage collection:
Persistent storage can help protect
critical data from eviction, and
educe the chance of data loss.
Persistent storage is not deleted by the browser,
even if storage is running low. It will only be
deleted if the user chooses to remove it via
their site settings.> There, you'd be able to save your documents to the user's file system, just like a native app would
What could possibly go wrong with that?
What could possibly go wrong with that?
PWA is useless for any non-toy desktop-replacement apps in its current state because of what you mentioned.
>Certainly it's true PWAs are subject to the user's desires about browser data. I think that's a good thing for users.
i mostly agree, but the user experience isn't there yet. browsers make it easy to delete all data, but don't have any workflows that encourage deleting the data from only a single app. at this point, it seems less about empowering users to have control over their own data and more like browsers just don't care about PWA data.
i mostly agree, but the user experience isn't there yet. browsers make it easy to delete all data, but don't have any workflows that encourage deleting the data from only a single app. at this point, it seems less about empowering users to have control over their own data and more like browsers just don't care about PWA data.
They can thanks to the Native File System API coming with Project Fugu: https://web.dev/native-file-system/. Available via origin trial for now but it should be soon released more broadly.
Have any other browser vendors expressed any interest in this?
I see from the link that Chrome is already doing an "origin trial" even if the spec itself isn't complete. So, why would it be "released more broadly". Or is it the Constructible Stylesheets again? When both Safari and Mozilla said "no", but Chrome released them anyway?
I see from the link that Chrome is already doing an "origin trial" even if the spec itself isn't complete. So, why would it be "released more broadly". Or is it the Constructible Stylesheets again? When both Safari and Mozilla said "no", but Chrome released them anyway?
I am typing this from Firefox, but the reality is that other vendors nowaydays mostly means Safari, everyone else is using Chrome engine and Firefox numbers diminish every year.
The same crowd that now complains about Google, was worshipping Chrome, talking about how its its developer tools are, the multiprocess architecture, handling hundreds of open tabs (still to understand this one),.....
So if the Web is turning into ChromeOS, they only have themselves to thank for.
The same crowd that now complains about Google, was worshipping Chrome, talking about how its its developer tools are, the multiprocess architecture, handling hundreds of open tabs (still to understand this one),.....
So if the Web is turning into ChromeOS, they only have themselves to thank for.
You can request persistent storage that isn't cleared.
Good point! I had forgotten about this.
kinlan is referring to this web API[0], which allows a PWA to store data persistently.
[0]: https://web.dev/persistent-storage/
kinlan is referring to this web API[0], which allows a PWA to store data persistently.
[0]: https://web.dev/persistent-storage/
[deleted]
So make them app_db side user config data, not local browser database config data.
For the PWAs I'd like to deploy, all I really need is 256 bits of entropy to persist on each client. I am entirely done with the ideology where I offload arbitrary storage and compute concerns to client devices. Keeping it all on the server is so much better in almost every way.
With PWAs, you have to write apps in HTML, CSS, and JS, which seems worse than natively compiled languages like Swift, Kotlin, Flutter, etc. This, I feel, is a fundamental problem.
Perhaps the solution instead is that we need a way to distribute natively compilable apps via other means, maybe through a website but also through other app stores not subject to the Google / Apple duopoly; so basically PWA level access and downloadability, but not made with web technologies.
Perhaps the solution instead is that we need a way to distribute natively compilable apps via other means, maybe through a website but also through other app stores not subject to the Google / Apple duopoly; so basically PWA level access and downloadability, but not made with web technologies.
> With PWAs, you have to write apps in HTML, CSS, and JS, which seems worse than natively compiled languages like Swift, Kotlin, Flutter, etc. This, I feel, is a fundamental problem.
Flutter supports compiling to PWAs
https://flutter.dev/web
Flutter supports compiling to PWAs
https://flutter.dev/web
It does, but Flutter web performance is worse than when compiled to apps.
There are lots of ways to do this, to have third-party "app stores" or different binary formats for apps (e.g. WASM, JVM/CLR bytecode).
All that would need to happen is Apple to allow sideloading apps. Then the only limit would be developer creativity.
All that would need to happen is Apple to allow sideloading apps. Then the only limit would be developer creativity.
PWAs can't use WebAssembly?
Perhaps, but WASM isn't ready yet.
Looks ready to me.
https://platform.uno/
https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
https://www.qt.io/qt-examples-for-webassembly
https://fsbolero.io/
https://tinygo.org/webassembly/webassembly/
https://leaningtech.com/pages/cheerp.html
https://leaningtech.com/pages/cheerpj.html
https://leaningtech.com/pages/cheerpx.html
https://platform.uno/
https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
https://www.qt.io/qt-examples-for-webassembly
https://fsbolero.io/
https://tinygo.org/webassembly/webassembly/
https://leaningtech.com/pages/cheerp.html
https://leaningtech.com/pages/cheerpj.html
https://leaningtech.com/pages/cheerpx.html
Off topic; I would like to know your news sources.
Reading conference papers, podcasts and watching talks, even from tech I don't use instead of boring TV shows.
Then just collect the references from them. :)
Then just collect the references from them. :)
Tongue in cheek reference to WebAssembly?
I actually was thinking more in line with how you can download Android APKs and install them directly. More like F-Droid, especially for a platform like Apple that doesn't allow third party app stores.
What's the sense in publishing your PWA in the Play Store? Chrome already prompts the user if they'd like to install a PWA shortcut when you visit the site. I ask because it costs $25 and while I have a lot of time on my hands I'm a cheap ass.
Discoverability. Users browsing Play Store might see your app in related apps list or in search results. And you will get a way to gather user feedback without hosting and moderating forum or discussion board. Also, we are still at the point when you tell user to download an app, one usually goes to Play/App Store, not searches the web.
> Discoverability. Users browsing Play Store might see your app in related apps list or in search results.
Since when anything in Play Store (or Apple's App Store, for that matter) was discoverable? I can't find anything even remotely relevant to anything i want using these stores, i always have to use 3rd party sites (or just google something like "<something i want> for android", sometimes even adding a site:reddit.com at the side if there are too many results, just to see what others are suggesting) and then if there isn't a Play Store link, i have to write the app's name exactly in the store's search, otherwise it will never appear on the results.
Discoverability has been a joke on these stores ever since they got more than about 1000 apps - and they still are designed as if they only have about 1000 apps.
Since when anything in Play Store (or Apple's App Store, for that matter) was discoverable? I can't find anything even remotely relevant to anything i want using these stores, i always have to use 3rd party sites (or just google something like "<something i want> for android", sometimes even adding a site:reddit.com at the side if there are too many results, just to see what others are suggesting) and then if there isn't a Play Store link, i have to write the app's name exactly in the store's search, otherwise it will never appear on the results.
Discoverability has been a joke on these stores ever since they got more than about 1000 apps - and they still are designed as if they only have about 1000 apps.
Also Businesses which has no use for an app, can claim 'We have an app' as many like to do and now they can convert their website to a publishable app more easily.
> "What's the sense in publishing your PWA in the Store?
We've trained a generation of users to look for apps in app stores. I blogged about this here[0], but having your PWA in app stores means more users for your app.
[0]: https://debuggerdotbreak.judahgabriel.com/2018/04/13/i-built...
We've trained a generation of users to look for apps in app stores. I blogged about this here[0], but having your PWA in app stores means more users for your app.
[0]: https://debuggerdotbreak.judahgabriel.com/2018/04/13/i-built...
I actually had just read this blog post prior to posting my comment. There's a lot of good insight on HOW to publish but I didn't see any compelling evidence on WHY to publish (specific traffic numbers, etc).
Check out the "Why" header and several paragraphs. I talk about reasons why I published my own PWA in app stores: some technical, but the big one being that's where the users are.
User behavior... We have a mobile PWA and literally all our users are like "I went to the Android app store and you don't have a mobile app so you suck" ... but the app already works in the browser.
Discoverability is an issue too. If your users search for your app keyword there then you're more easily found
Discoverability is an issue too. If your users search for your app keyword there then you're more easily found
You can get access to native APIs that way, without the typical hybrid approach.
Awesome! I hope this will put some pressure on Apple to add support for critical PWA features (e.g. push notifications) to iOS.
+100
Firefox needs to catch up on PWA support for desktop, Safari too.
It's catching up slowly. I can save a website and open it in its own window (at least on Firefox Beta).
What's missing is the ability to integrate it with my OS app launcher, though I can get around that by adding my own launcher. Something like:
What's missing is the ability to integrate it with my OS app launcher, though I can get around that by adding my own launcher. Something like:
firefox --ssb="https://news.ycombinator.com"Yes. For Firefox desktop, here's the open case[0].
I and many others would love to see Firefox supporting installable PWAs. :-)
[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1407202
I and many others would love to see Firefox supporting installable PWAs. :-)
[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1407202
You seem to be heavily involved in the PWABuilder website. Can you explain why the PWA needs to register a pushManager? I'd like to publish my app without setting up push notifications.
You don't need to register a push manager; only if you want to send push notifications.
If you're referring to the PWABuilder analysis page, yeah, we hear your feedback. We're going to be revamping that page in the coming months. We'll deal with push notification score when we do that.
If you're referring to the PWABuilder analysis page, yeah, we hear your feedback. We're going to be revamping that page in the coming months. We'll deal with push notification score when we do that.
I was disappointed to learn that https://pwabuilder.com can't process the PWAs that are produced by our app builder Calcapp, erroneously claiming that our PWAs have no manifest.
I dug into pwabuilder-lib and found the culprit: our manifest URLs use search parameters, which are silently stripped by pwabuilder-lib. Here's the GitHub issue I filed, including a proposed fix:
https://github.com/pwa-builder/PWABuilder/issues/949
Obviously, this wouldn't have been possible if PWABuilder hadn't been open source, so kudos for that.
I dug into pwabuilder-lib and found the culprit: our manifest URLs use search parameters, which are silently stripped by pwabuilder-lib. Here's the GitHub issue I filed, including a proposed fix:
https://github.com/pwa-builder/PWABuilder/issues/949
Obviously, this wouldn't have been possible if PWABuilder hadn't been open source, so kudos for that.
Pwa's are not a replacement for electron, and can't be. Either you sandbox for security, or you don't.
Pwas are for apps wherein their functionality is entirely web based, and people just want an icon for it.
Pwas are for apps wherein their functionality is entirely web based, and people just want an icon for it.
Hey! I see a lot of confusions on PWA on what they can or can't do in the comments. I've written an article trying to address that in a fun way: https://www.davrous.com/2019/10/18/myth-busting-pwas-the-new... by busting 9 common myths on Progressive Web Apps. For instance, they can use WASM which is production ready for years in all browsers!
My eli5 is, a PWA is just a web app that:
* is installed
* may run offline
* may use extra system resources
* is installed
* may run offline
* may use extra system resources
One issue with add to shelf / add to desktop is that it will be just another modal like Notifications that users has to click cancel. All Apple has to do is to show a little cloud if the web app has a webmanifest, the functionality is already there
I have a feeling that Microsoft is going to launch an "Edgebook" competitor to Chromebook in the the future using Windows 10X. This obviously is good for the ecosystem all around, for tablets, phones, desktop, etc.
Obviously good to have competition for Chrombebooks.
Now imagine how good it would be if there were competition on the desktop market.
Now imagine how good it would be if there were competition on the desktop market.
Isn't this Windows RT?
Windows RT is long gone, I guess you mean Windows on ARM.
https://www.microsoft.com/en-us/p/surface-pro-x/8vdnrp2m6hhc...
https://www.samsung.com/us/computing/windows-laptops/galaxy-...
https://www.microsoft.com/en-us/p/surface-pro-x/8vdnrp2m6hhc...
https://www.samsung.com/us/computing/windows-laptops/galaxy-...
This article used the term "PWA" 24 times without defining it once. I assume the WA part means Web App but it's the "P" for "portable" , "Pocket" or something else?
Progressive Web App: https://infrequently.org/2015/06/progressive-apps-escaping-t...
Progressive
Microsoft is now using Medium as their official blogging service?
Author here. Some teams use it, including ours (PWABuilder).
Off-topic, but... why?
Is it lower friction to start up your team's blog on Medium versus the unified blog platform larger Microsoft teams tend to use?
Is it lower friction to start up your team's blog on Medium versus the unified blog platform larger Microsoft teams tend to use?
PWABuilder is an open source project and builds cross platform web apps. We feel Medium is a better fit than the more corporate structured blogs. So far we've been pretty happy with Medium.
That said, we have been mulling building our own blogging platform using our own tools and web components for the sake of dogfooding.
That said, we have been mulling building our own blogging platform using our own tools and web components for the sake of dogfooding.
You might want to customize it a bit more to make it clear this is an offical blog. For a few seconds when reading this on mobile I was super confused if this was official or just someone outside MS writing about it.
Thanks for this feedback. We're thinking about hosting a blogging platform directly under pwabuilder.com. We've got a small team that was mainly focused on writing new features & code but we definitely need to better address our blogging approach.
Something like this I would expect to be be part of Edge Developer Blog, given https://developer.microsoft.com/en-us/windows/pwa/
Might I suggest looking into Hugo.
That is like a team at Microsoft using Gmail as their email provider.
What is the name of that blogging software Microsoft is providing in competition with Medium?
I don't think there's a public blogging software unless you count Sharepoint but I doubt that would scale well. Still Microsoft has a number of web products that could be used instead of Medium. A lot of the smaller Microsoft weblogs use Azure websites with Wordpress and the bigger ones are part of Micrsoft's in-house multisite.
Microsoft uses a .NET static site generator for company blogs similar to Hugo.
How?
PWAs are worthless for me until full networking access is provideded(i.e no CORS, set custom headers etc). Until then PWAs are just bookmarks of websites.
As the author seems to be here, the links in the "Add features to my PWA" section on pwabuilder website, don't seem to work for me.
Thanks for the heads up. We just changed the URLs to that yesterday. Fixing! In the meantime, you can access those components here[0].
[0]: https://components.pwabuilder.com/
[0]: https://components.pwabuilder.com/
I miss Chrome apps. What was wrong with them? Genuine question.
They were proprietary; only worked in chrome. Progressive webapps are built out of open standards, and will ideally eventually work everywhere.
Guess what browser implements all stuff from http://web.dev and has the biggest coverage for WebAssembly?
Open standards are meaningless when only one cares about them.
Open standards are meaningless when only one cares about them.
I wonder if they're doing this for the Surface Duo launch.
Fair question. Certainly Microsoft wants Duo to succeed. But PWABuilder been pushing for PWAs in App Stores for years -- we also support MacOS, Samsung Galaxy Store, Microsoft Store, and others. (We're talking with Apple now to enable PWAs in iOS app store as well.)
This collaboration with Google took place because Google revamped their "PWAs in the Store" story. It used to be a very basic story: a native app wrapping a web view that loads your PWA. Those worked, but didn't support some modern APIs (e.g. service worker, IIRC), didn't share cookies and login information with the browser, and other problems.
Google revamped the story here to a more first-class approach for PWAs in their Store. It's called "Trusted Web Activities."
And earlier this year, Google created Bubblewrap, a command line tool to generate a proper Trusted Web Activity for publishing in their Store. So we wanted to take advantage of that new and better approach. That's really our reason for collaboration here.
This collaboration with Google took place because Google revamped their "PWAs in the Store" story. It used to be a very basic story: a native app wrapping a web view that loads your PWA. Those worked, but didn't support some modern APIs (e.g. service worker, IIRC), didn't share cookies and login information with the browser, and other problems.
Google revamped the story here to a more first-class approach for PWAs in their Store. It's called "Trusted Web Activities."
And earlier this year, Google created Bubblewrap, a command line tool to generate a proper Trusted Web Activity for publishing in their Store. So we wanted to take advantage of that new and better approach. That's really our reason for collaboration here.
They already had this with Edge and Windows Store.
https://developer.microsoft.com/en-us/windows/pwa/
The best part was that this way WinRT APIs are directly exposed as browser APIs, no need for hybrid solutions.
This is just the next step using the Chrome based engine instead.
https://developer.microsoft.com/en-us/windows/pwa/
The best part was that this way WinRT APIs are directly exposed as browser APIs, no need for hybrid solutions.
This is just the next step using the Chrome based engine instead.
what's that other company? starts with an A?
PWA collaboration seems to be a step in the right direction, especially since Edge is using chromium and Microsoft seems to be building great PWA apps[1].
Although I'm not entirely sure about Google's end game with PWA[2], I hope these kind of collaboration motivates industries to build more PWA apps and put pressure on Apple to properly support PWA APIs in Safari; then may be, just may be one day we'll have fair grounds for new mobile operating systems to compete without this Playstore/Appstore duopoly.
[1]https://www.bing.com/covid/
[2]https://news.ycombinator.com/item?id=23574697