PWAs wont replace native iOS apps(app.campsite.co)
app.campsite.co
PWAs wont replace native iOS apps
https://app.campsite.co/campsite/p/notes/rengvq2txami
267 comments
Can't we just give up on the "Progressive" branding and just say we are making Web Apps? There are just so many things that make "PWA" a bad smell. I mean, have you ever asked a user if they need more spam spamifications in their life? (Yeah, your app does and 95% say "hell no") Personally I find it much easier to find web sites with Safari (until last week I would hit "1" and Safari would automatically show me my RSS reader, now I have a choice of that or my Fraxinus bookmark manager) than it is to find icons on my iPad (there are so many signs of carelessness on both the part of Apple and app makers; the other day I realized part of it is that iOS doesn't draw boundaries around icons so if the colors of an icon are similar to the colors on the background the edges of the icon become invisible which means the icon becomes invisible) I can type "n" in Safari and it fills in Hacker News, if there was a (cr)app to use HN it might have an H for an icon, or maybe a N or another Y and it would be orange: orange icons tend to disappear into the background on my iPad and for any given letter there is some app that uses it for an icon.
We should just have the story that we are making better and better web apps and Apple isn't keeping up with others.
We should just have the story that we are making better and better web apps and Apple isn't keeping up with others.
I'm also not fond of the PWA branding or the confusion around implementing one.
Yeah, your app does and 95% say "hell no"
Plus, “progressive web app” tells a (well informed) user “this website can use your camera and gyroscope and GPS and such”.
Plus plus, and I think this is the most important: it’s a fun community and a great resume term. It’s no fun to just be a “web developer”, you’ve gotta be a progressive, web3, 3D, local-first, no-js, all-js web developer ;)
I make apps with A-Frame that use the gyroscope and all that and I wouldn't call them "progressive". My goal is to give a "it just works" experience and labels don't help with that.
fyi if you pull down in the middle of any home screen a global search shows up. i just keep one screen of my most used apps then search for all the others
I started doing this after hitting the maximum number of pages. New apps didn’t have anywhere to go and I was forced to use search anyways. The App Library to the right is pretty nice and groups things by category so I don’t have to move icons between pages anymore which was very annoying.
I for one would much rather have native mobile apps that use platform-appropriate controls rather than web apps that use whatever some designer came up with. We’ve already lost this battle on computers because of electron, but iOS is nice precisely because there isn’t an easy way to just ship web technology “apps”.
Is it though?
A large portion of apps on the mobile app stores are already built using cross-platform technologies like React Native, Ionic or Flutter. In some instances it is very easy to tell, in other it's not. You can create quality experiences using cross-platform, you can create awful experiences using native tooling.
In many instances, I'd rather have the not totally native app that exists than the absolutely perfectly native app that does not exist.
As for PWAs, I am personally all for it. I have so many apps on my phone that don't need to be an app in the first place. Why not make a great PWA experience rather than a mediocre mobile app? In terms of capabilities, PWA are perfectly suitable for the majority of usecases.
A large portion of apps on the mobile app stores are already built using cross-platform technologies like React Native, Ionic or Flutter. In some instances it is very easy to tell, in other it's not. You can create quality experiences using cross-platform, you can create awful experiences using native tooling.
In many instances, I'd rather have the not totally native app that exists than the absolutely perfectly native app that does not exist.
As for PWAs, I am personally all for it. I have so many apps on my phone that don't need to be an app in the first place. Why not make a great PWA experience rather than a mediocre mobile app? In terms of capabilities, PWA are perfectly suitable for the majority of usecases.
I understand your point, but it somewhat says that making awesome native apps is not even an option anymore.
I use Things (a todo app) daily. It was #1 of Design in the AppStore maybe already 5 years ago. I think it's a perfect example for a beautifully made native app. I really feel how the native behaviour workes so much smoother.
I would love for creators to somehow strive more for beautifully made apps instead of the fast profit.
I use Things (a todo app) daily. It was #1 of Design in the AppStore maybe already 5 years ago. I think it's a perfect example for a beautifully made native app. I really feel how the native behaviour workes so much smoother.
I would love for creators to somehow strive more for beautifully made apps instead of the fast profit.
Things is a great example for PWAs, because it does not exist on Android, Linux or Windows. It could be though, if it would be a PWA.
It is not and it seems like the developer focused its resources on native software for Apple products.
It is not and it seems like the developer focused its resources on native software for Apple products.
It could, yes. But the user experience and the amazing level of usability will degrade, and I would move to another product.
And we've come full circle!
> But as a web dev community we need to stand firm and build PWAs regardless. If we treat pwas on iOS like we did Internet explorer (i.e. giving it special attention and hack solutions as opposed to just not developing for it) we will lose the fight.
> But as a web dev community we need to stand firm and build PWAs regardless. If we treat pwas on iOS like we did Internet explorer (i.e. giving it special attention and hack solutions as opposed to just not developing for it) we will lose the fight.
Comeon, it’s a todo app, being native provides marginal benefits over its functionality.
Except that it feels smoother (the UI, animations, UX) instead of a web app, and is amazingly fast/reactive?
No one wants to invest time and effort to develop for a platform that has a horrible review process. You have to invest multiple people's months worth of work without knowing if that particular snapshot of your app will offend the reviwer.
The lack of native apps is the App Store reviews process fault.
The lack of native apps is the App Store reviews process fault.
And the only reason for that review is that Apple won’t let any software run on the platform. If Apple is the gatekeeper, any bad software that makes it through is their fault. They would never be able to keep up with it all or give private APIs a fair analysis, so they gatekeeper approvals and simply block anything they can’t vaguely autoanalyze.
The App Store revenue is a poison pill that will eventually start killing them. It’s already holding back their platforms, and the law can’t not bring down the hammer forever. The iPhone, iPad, Watch, and the Vision Pro would be truly remarkable platforms without the arbitrary, puritan rules.
The App Store revenue is a poison pill that will eventually start killing them. It’s already holding back their platforms, and the law can’t not bring down the hammer forever. The iPhone, iPad, Watch, and the Vision Pro would be truly remarkable platforms without the arbitrary, puritan rules.
[deleted]
One good thing about PWAs is that they run inside a browser. So if that's a good browser like firefox, you can use addons to limit tracking. Or force dark mode even for apps that don't bother implementing it (eg the Amazon shopping app) with dark reader.
This is exactly what I dislike about PWAs: the move to sandboxing everything in the browser is a big step back because the browser silos everything in a non-composable way.
Exactly. Pwa is cheap
The fact that an app is in the store doesn't mean that uses platform appropriate controls. In fact a lot of applications nowadays are just web app packaged with tools like Ionic, or cross platform applications built with React Native or Flutter that doesn't use "platform-appropriate controls".
If most applications are embedding a web browser, or at least part of a web browser (in case of RN), why not just have applications that... run in a browser? No need to install them, no need to update them, I can just open an URL and they work.
If most applications are embedding a web browser, or at least part of a web browser (in case of RN), why not just have applications that... run in a browser? No need to install them, no need to update them, I can just open an URL and they work.
> No need to install them, no need to update them, I can just open an URL and they work.
The App Store is a useful distribution mechanism. For better or worse more people seem to be willing to buy an app, search in the App Store, etc.
There have been threads on HN about a discoverability problem for on the web, not that it doesn’t exist for apps too.
I made a one time use website and my only feedback from normal people was that it should be an app…
The App Store is a useful distribution mechanism. For better or worse more people seem to be willing to buy an app, search in the App Store, etc.
There have been threads on HN about a discoverability problem for on the web, not that it doesn’t exist for apps too.
I made a one time use website and my only feedback from normal people was that it should be an app…
React Native renders down to native iOS component classes, though: there are definitely too many generic UIViews for my taste, but it’s pretty different from electron that just constructs UIs from divs like a web app.
You don't have to override the native styles of UI controls with CSS. If you don't add any CSS, they will look just like in native apps. It's a choice, just like you could implement your completely custom controls in native apps if you wanted to.
Sort of: it’s possible for a browser to render the controls with native components. Designers of web applications tend to think their aesthetic preferences are more important than the preferences of their users; and, browsers have not always used real native controls: Google Chrome just shipped its own controls for form inputs, for example. Historically, various parts of the Cocoa text input system also worked incorrectly in Firefox and Chrome.
Were you not around during the big iOS custom controls era? It’s less pronounced now but it’s not like every native app ever has avoided custom controls.
It is not fundamentally wrong to do custom stuff. I prefer native apps as well but this sound bite needs to go away.
It is not fundamentally wrong to do custom stuff. I prefer native apps as well but this sound bite needs to go away.
> for the best experience, use <other broswer>
In this case you’d need “use <other operating system>”. There’s no alternatives to Safari for PWAs on iOS.
In this case you’d need “use <other operating system>”. There’s no alternatives to Safari for PWAs on iOS.
This is unfortunately correct. Chrome on iOS uses Safari's Webkit, which is horribly broken on <insert here> things.
That just changed in the EU:
https://developer.apple.com/support/alternative-browser-engi...
As did the ability to install PWAs. It appears to be gone in the EU in the latest builds of iOS.
If I see a “best viewed in” badge I’m very likely to go find an alternative, regardless of the platform or browser I’m using. Those badges would best remain a vestige of the IE-Netscape era.
I'm a web developer and native app developer but I'm also a user. If I want to use a service and they have a message saying "for the best experience, use <other os>" I will never use that service again. There are no apps or services that would cause me to switch. So you can take that stance but you are just hurting your app because you as a developer don't want to learn native apps.
This business model can only be broken via regulations from another country. The European Union is on it right now, and their plans give a little bit of hope.
Apple/Google will never voluntarily give up their stores. And it's also not reasonable to think that the US will regulate it. Those stores bring a lot of money from all around the world into the US. It would be crazy from an US perspective to stop them doing this. Those profits can be taxed without taking away any money from their citizens. So basically free tax money.
Apple/Google will never voluntarily give up their stores. And it's also not reasonable to think that the US will regulate it. Those stores bring a lot of money from all around the world into the US. It would be crazy from an US perspective to stop them doing this. Those profits can be taxed without taking away any money from their citizens. So basically free tax money.
Depends on what outcome you want. If you're developing in a commercial outlet to make money you should do it iOS and MacOS first, because those users are more willing to pay for software and services.
> "for the best experience, use <other browser>"
You just lost a customer.
> "for the best experience, use <other browser>"
You just lost a customer.
Google alongside Microsoft, are the two main companies behind PWAs.
And yet do they really use it for the advantages? Office and docs still don’t work offline as PWAs.
For example, packing them as apps on the respective stores.
https://developer.chrome.com/docs/android/trusted-web-activi...
https://developer.android.com/reference/androidx/browser/tru...
https://learn.microsoft.com/en-us/microsoft-edge/progressive...
Just because you don't get Office as PWA, doesn't mean they aren't serious about them.
https://developer.chrome.com/docs/android/trusted-web-activi...
https://developer.android.com/reference/androidx/browser/tru...
https://learn.microsoft.com/en-us/microsoft-edge/progressive...
Just because you don't get Office as PWA, doesn't mean they aren't serious about them.
I agree with the sentiment, but building for IE was not just an interesting and hacky technical challenge, IE was basically the platform.
“Am I wrong? No, it is the users who are wrong.”
I love developing PWAs because I can quickly and easily make an app for myself and my family that works without having to provision their devices or pay a dev license to Apple. I also use it at work for internal apps. It’s great for all those things.
It’s very obvious to me that I’m a second priority for Apple. Dark mode breaking in iOS 17 and still broken 5 months later. Updating the app is tricky, and making users update is even trickier. Haven’t even bothered to try push notifications.
One pro though is that when my brother wanted to use a PWA I had developed it worked flawlessly on his Android phone. Cross platform support is a big pro in my opinion.
Maybe Apple will fix dark mode with iOS 18, let’s hope they also fix it when using guided access (which was buggy in iOS 16).
It’s very obvious to me that I’m a second priority for Apple. Dark mode breaking in iOS 17 and still broken 5 months later. Updating the app is tricky, and making users update is even trickier. Haven’t even bothered to try push notifications.
One pro though is that when my brother wanted to use a PWA I had developed it worked flawlessly on his Android phone. Cross platform support is a big pro in my opinion.
Maybe Apple will fix dark mode with iOS 18, let’s hope they also fix it when using guided access (which was buggy in iOS 16).
Looks like Apple is going to fix dark mode in iOS 18 by dropping support for PWAs altogether in my part of the world.
https://www.macrumors.com/2024/02/08/ios-17-4-nerfs-web-apps...
https://www.macrumors.com/2024/02/08/ios-17-4-nerfs-web-apps...
That is really terrible. I don't like the closed nature of Apple's practices anyway, but the way in which they are stifling PWAs is truly abhorrent.
I do feel they'll lose this battle eventually, even if it takes a few years. Cross platform apps without a required compile step or walled garden are almost certainly the end state I expect we'll reach within the next decade (probably sooner).
I do feel they'll lose this battle eventually, even if it takes a few years. Cross platform apps without a required compile step or walled garden are almost certainly the end state I expect we'll reach within the next decade (probably sooner).
Keep speaking up, and making this issue clear for others.
Looks like Apple is just going to blame the EU. They are officially pulling PWA support on iOS in Europe.
So fuck me I guess :(
https://9to5mac.com/2024/02/15/ios-17-4-web-apps-european-un...
So fuck me I guess :(
https://9to5mac.com/2024/02/15/ios-17-4-web-apps-european-un...
You seem to be conflating "PWA" with the Safari + Home Screen integration that allowed users to add a web[site|app] (PWA or not) to the iOS Home Screen. Apple had to remove this to comply with the DMA.
It's now the responsibility of alternative browser engine vendors to integrate with Shortcuts so that you can add PWAs and other web[sites|apps] to the Home Screen using your browser engine of choice. The additional benefit of this is that different PWAs can use different browser engines.
It's now the responsibility of alternative browser engine vendors to integrate with Shortcuts so that you can add PWAs and other web[sites|apps] to the Home Screen using your browser engine of choice. The additional benefit of this is that different PWAs can use different browser engines.
> Apple had to remove this to comply with the DMA.
This has yet to be made clear to me.
Could you attempt to convince us?
This has yet to be made clear to me.
Could you attempt to convince us?
The DMA requires that Apple not favor Safari. A direct integration between Safari and Home Screen favors Safari, and so is not allowed under the DMA.
So...they're tearing out all OS features that favor Safari?
or just the features they're motivated not to offer a path to using for other publishers?
(Like, webapp support)
or just the features they're motivated not to offer a path to using for other publishers?
(Like, webapp support)
Pretty much.
You emphasized “all” to imply there are so many, but honestly I can’t think of much beyond what they’re already mitigating to comply with the DMA.
You’ll get a browser selection screen now, other engines will be allowed, default browser choice gets further expanded in terms of implementation so it essentially ensures you never have to touch Safari.
The only thing that is being torn out is PWA installation on Home Screen because it would be yet another significant architectural change that comes with some significant engineering effort during a time of crunch, when the install rate of PWAs is abysmal as it is, even on other OSs.
Seems fair to me.
You emphasized “all” to imply there are so many, but honestly I can’t think of much beyond what they’re already mitigating to comply with the DMA.
You’ll get a browser selection screen now, other engines will be allowed, default browser choice gets further expanded in terms of implementation so it essentially ensures you never have to touch Safari.
The only thing that is being torn out is PWA installation on Home Screen because it would be yet another significant architectural change that comes with some significant engineering effort during a time of crunch, when the install rate of PWAs is abysmal as it is, even on other OSs.
Seems fair to me.
Siri won't learn from Safari activity, anymore?
and a dozen other similar questions...
and a dozen other similar questions...
> Siri won't learn from Safari activity, anymore?
Can you clarify what you mean by this?
If Siri would be the one benefiting (which is what you seem to be saying?) then it wouldn’t give Safari an unfair advantage.
No virtual assistants have been designated as gatekeepers under the DMA so preferential treatment of Siri would still be allowed.
That said, to my knowledge Siri doesn’t “learn” from Safari in the sense that it improves or trains on Safari user data.
Instead Safari, and all other apps, including third party apps, can provide information to Siri to be shown during search as well as providing shortcuts so the app can be controlled via Siri. Users have control over this to a degree so they can exclude information from certain apps.
Alternative voice assistants offer similar APIs to receive information and support voice commands for third party services.
> and a dozen other similar questions...
I’m all ears.
Can you clarify what you mean by this?
If Siri would be the one benefiting (which is what you seem to be saying?) then it wouldn’t give Safari an unfair advantage.
No virtual assistants have been designated as gatekeepers under the DMA so preferential treatment of Siri would still be allowed.
That said, to my knowledge Siri doesn’t “learn” from Safari in the sense that it improves or trains on Safari user data.
Instead Safari, and all other apps, including third party apps, can provide information to Siri to be shown during search as well as providing shortcuts so the app can be controlled via Siri. Users have control over this to a degree so they can exclude information from certain apps.
Alternative voice assistants offer similar APIs to receive information and support voice commands for third party services.
> and a dozen other similar questions...
I’m all ears.
From Apples own documentation I get the feeling that someone discovered that there was no easy way to allow their PWA support to work with other browser engines. Due to a lack of priority, running out of time and general malicious compliance they just nuked PWAs instead of fixing them.
I wonder if the DMA contains some sort of requirement that features not be removed. To force Apple to make PWAs interoperable with other browser engines instead of just nuking them.
I wonder if the DMA contains some sort of requirement that features not be removed. To force Apple to make PWAs interoperable with other browser engines instead of just nuking them.
What are you talking about?
With iOS 17.4 in the EU, you can no longer make a web app (PWA) that uses a full screen window with no browser ui controls. No longer use local storage for the web app's data, and no longer send push notifications and show badges on the home screen icon for web apps.
Third party browsers can't add this functionality back. How do you expect them to make push notifications work with PWAs?
With iOS 17.4 in the EU, you can no longer make a web app (PWA) that uses a full screen window with no browser ui controls. No longer use local storage for the web app's data, and no longer send push notifications and show badges on the home screen icon for web apps.
Third party browsers can't add this functionality back. How do you expect them to make push notifications work with PWAs?
> With iOS 17.4 in the EU, you can no longer make a web app (PWA) that uses a full screen window with no browser ui controls.
Are you sure? Go to https://sindresorhus.com/screenfull/, tap "Request", and you should see a full-screen website. Any [website|webapp|PWA] can do this with Safari. (Screenshot: https://imgur.com/a/CTWFPol) Third-party browsers using their own browser engines can do whatever they like.
> How do you expect them to make push notifications work with PWAs?
Third-party browsers using their own browser engine will have to create their own support for web notifications, just as Apple does for Safari. Presumably, they'll leverage the same infrastructure they use on non-iOS platforms.
Are you sure? Go to https://sindresorhus.com/screenfull/, tap "Request", and you should see a full-screen website. Any [website|webapp|PWA] can do this with Safari. (Screenshot: https://imgur.com/a/CTWFPol) Third-party browsers using their own browser engines can do whatever they like.
> How do you expect them to make push notifications work with PWAs?
Third-party browsers using their own browser engine will have to create their own support for web notifications, just as Apple does for Safari. Presumably, they'll leverage the same infrastructure they use on non-iOS platforms.
That's good. The Fullscreen API isn't exactly the same as a PWA, but it might go a long way to make my PWAs feel a bit more native again.
I see that the support for the Fullscreen API isn't available in iOS 17.3 but will be available once 17.4 lands.
"Added support for the Fullscreen API on iOS. (118083593)"
https://developer.apple.com/documentation/safari-release-not...
I see that the support for the Fullscreen API isn't available in iOS 17.3 but will be available once 17.4 lands.
"Added support for the Fullscreen API on iOS. (118083593)"
https://developer.apple.com/documentation/safari-release-not...
That’s interesting.
I use that with a site I make that I want to look and feel more like an app and so I use the PWA fullscreen stuff now.
I have no need for all the browser url bar and buttons and it just wastes precious screen space for my application.
I use that with a site I make that I want to look and feel more like an app and so I use the PWA fullscreen stuff now.
I have no need for all the browser url bar and buttons and it just wastes precious screen space for my application.
I’m not in the EU so I can’t test it.
But those that are are all claiming that all their PWAs are no longer full screen, lost all their local storage, and push notifications stopped working.
But those that are are all claiming that all their PWAs are no longer full screen, lost all their local storage, and push notifications stopped working.
Using shortcuts might be a solution in the future. Would be much better if Apple updated their PWA support so that users could select a browser engine instead.
It’s just a beta, though, right now… We don’t know if this is getting released or not yet.
> I can quickly and easily make an app for myself and my family that works without having to provision their devices or pay a dev license to Apple. I also use it at work for internal apps.
This is exactly why they don't want it. Some will say it's because those are Apple's users and Apple wants to ensure a great user experience and doesn't want unapproved things running on their devices, and others will say it's because it skips Apple's 30% take and their gatekeeping process. My opinion is that both are true, and conveniently both are achieved the same way: by making PWAs enough of an annoyance to both developers and users that they will voluntarily steer away from them. Classic game theory
This is exactly why they don't want it. Some will say it's because those are Apple's users and Apple wants to ensure a great user experience and doesn't want unapproved things running on their devices, and others will say it's because it skips Apple's 30% take and their gatekeeping process. My opinion is that both are true, and conveniently both are achieved the same way: by making PWAs enough of an annoyance to both developers and users that they will voluntarily steer away from them. Classic game theory
They would probably ban browsers altogether from iOS, if they could get away with it. Fortunately we are not there yet.
I often say that the only reason email is in the form it is today is because it happened before corporate interests took over communication.
If it had been invented today you could only iMessage other iDevice holders. Maybe you would also have had another for-profit middleware company just to deliver messages between Apple and Android devices. Something like a telephone exchange.
If it had been invented today you could only iMessage other iDevice holders. Maybe you would also have had another for-profit middleware company just to deliver messages between Apple and Android devices. Something like a telephone exchange.
In one of the movies about Steve Jobs, he actually does want to make email proprietary and to only be able to send and receive emails on Macs. There was also talk (involving Bill Gates IIRC) about having an electronic stamp (basically a charge for email).
I very much agree, if it were invented today there's no way it would be an open standard. It almost wasn't even back then.
I very much agree, if it were invented today there's no way it would be an open standard. It almost wasn't even back then.
> doesn't want unapproved things running on their devices
> ban web browsers
and this is the point.
Stop playing games.
Allow users to access and easily use the open web with the internet device they bought from you.
Full stop.
> ban web browsers
and this is the point.
Stop playing games.
Allow users to access and easily use the open web with the internet device they bought from you.
Full stop.
And what do you say to those who point out that Apple has invested significantly in supporting PWAs the last 4 years or so?
To the point that PWA support matches, and in some cases surpasses, Firefox with more on the way as we speak?
Doesn’t that run counter to this theory that Apple is purposefully making PWAs unviable to the benefit of their App Store? Why take away the biggest hurdles that PWAs had on iOS if that was the goal?
To the point that PWA support matches, and in some cases surpasses, Firefox with more on the way as we speak?
Doesn’t that run counter to this theory that Apple is purposefully making PWAs unviable to the benefit of their App Store? Why take away the biggest hurdles that PWAs had on iOS if that was the goal?
In my opinion, it is always the same "cross-platform" discussion. If you hire an iOS/Android mobile dev to write a native iOS/Android app, it means that you hire someone specialized in apps for mobiles. The whole point of a cross-platform framework is the hope that it won't need the specialization: "any web dev can now write a mobile app".
But every cross-platform framework has the same problem: platforms are different, and require work specific to them. As a result, cross-platform is "write once, debug everywhere".
If you don't know better, cross-platform frameworks systematically seem to "get to the same result faster". So many companies go for cross-platform frameworks. But in reality, the different platforms are so different that the only way to make a truly great app is to go native everywhere.
Not that there is not a place for PWAs: "cheaper but not as good" is clearly the trend everywhere. But I don't see PWAs replace "great native apps" anytime soon. If PWAs win, it will just mean that the users got worse apps because the companies spent less money on them.
But every cross-platform framework has the same problem: platforms are different, and require work specific to them. As a result, cross-platform is "write once, debug everywhere".
If you don't know better, cross-platform frameworks systematically seem to "get to the same result faster". So many companies go for cross-platform frameworks. But in reality, the different platforms are so different that the only way to make a truly great app is to go native everywhere.
Not that there is not a place for PWAs: "cheaper but not as good" is clearly the trend everywhere. But I don't see PWAs replace "great native apps" anytime soon. If PWAs win, it will just mean that the users got worse apps because the companies spent less money on them.
> If PWAs win, it will just mean that the users got worse apps
If PWAs win, it will be because native apps failed. Android and MacOS both have an enormous community of open source native apps that are more private, functional and accountable than their commercial alternatives. So far, Apple hasn't opened the floodgate for that on iOS. As a result, the interest in sideloading things has been relegated to the most-open part of the OS; the browser. It's not surprising at all.
Apple could be enabling a Cambrian explosion of open iPhone apps and killing the case for dinky webapps overnight. Their motivation not to is rooted in a company-wide strategy to make more service revenue.
If PWAs win, it will be because native apps failed. Android and MacOS both have an enormous community of open source native apps that are more private, functional and accountable than their commercial alternatives. So far, Apple hasn't opened the floodgate for that on iOS. As a result, the interest in sideloading things has been relegated to the most-open part of the OS; the browser. It's not surprising at all.
Apple could be enabling a Cambrian explosion of open iPhone apps and killing the case for dinky webapps overnight. Their motivation not to is rooted in a company-wide strategy to make more service revenue.
> If PWAs win, it will be because native apps failed.
Or because the vast majority of people who "write code that runs on mobile phones" know web technologies and not the mobile ones. Web programming is simply more accessible.
The thing is, "more" is not always "better".
Or because the vast majority of people who "write code that runs on mobile phones" know web technologies and not the mobile ones. Web programming is simply more accessible.
The thing is, "more" is not always "better".
None of that really disagrees with what I said. Apple failed to lower the on-ramp for native development to the people that wanted it. Now we're seeing desperate porting attempts to the browser, and Apple's desperate attempt at plugging the gap.
> The thing is, "more" is not always "better".
In the free market, competition is king. "Better" is decided by pitting it against "more".
> The thing is, "more" is not always "better".
In the free market, competition is king. "Better" is decided by pitting it against "more".
I wasn't saying I disagree :-).
> Apple failed to lower the on-ramp for native development to the people that wanted it.
And they don't have to, IMHO. It's not that hard to learn how to do native iOS dev, and Apple is making a ton of money from those who do. Apple not wanting to go out of their way to lower the bar to a point that they don't find profitable is their choice.
> In the free market, competition is king.
I am not sure I am seeing "free market" and "competition" with PWAs, where people lobby to get laws to help them pass their ideas. The free market alternative would be for PWAs to get so good on Android that Apple decides to embrace them.
> Apple failed to lower the on-ramp for native development to the people that wanted it.
And they don't have to, IMHO. It's not that hard to learn how to do native iOS dev, and Apple is making a ton of money from those who do. Apple not wanting to go out of their way to lower the bar to a point that they don't find profitable is their choice.
> In the free market, competition is king.
I am not sure I am seeing "free market" and "competition" with PWAs, where people lobby to get laws to help them pass their ideas. The free market alternative would be for PWAs to get so good on Android that Apple decides to embrace them.
> It's not that hard to learn how to do native iOS dev
Brb gotta go get a whole new computer
Brb gotta go get a whole new computer
Well if you develop an Android PWA without having a single Android device to test it on, then maybe you should not develop an Android app at all. Same applies for iOS.
1. Android emulators exist.
2. It's not crazy to require a ___ device to develop ___ apps. But are you honestly claiming you can develop iPhone apps with an iPhone?
2. It's not crazy to require a ___ device to develop ___ apps. But are you honestly claiming you can develop iPhone apps with an iPhone?
If you don't want to develop for iOS, then don't. I don't see why it should be written in the law that Apple has to make it appealing to you.
Oh, thanks :D
[deleted]
You can use free Android Studio with free emulators with macOS or Windows (maybe even Linux?)
Cannot say the same about iOS emulators.
Cannot say the same about iOS emulators.
Android emulators for development are:
1) mostly free
2) ...even somewhat available on iPads!
Is it even necessary?
Safari seems to be the only odd one out that can't even properly implement CSS, out of the top 5 modern browsers.
I'm super glad all of these ridiculous "arguments" are being put on display.
1) mostly free
2) ...even somewhat available on iPads!
Is it even necessary?
Safari seems to be the only odd one out that can't even properly implement CSS, out of the top 5 modern browsers.
I'm super glad all of these ridiculous "arguments" are being put on display.
Can I run an Android emulator on my musl-based system? Can I even run Android-Studio on OpenBSD? What about Plan9? Should I complain to Google because they don't support all the platforms under the sun?
If I want to develop with Qualcomm boards, I need to sign all sorts of NDAs, and they don't even have emulators for development. Do you think that should be illegal?
I wish we tried to honestly make the difference between what is an inconvenience ("I don't want to need a macOS system to deploy on iOS") and what is abuse ("Apple removed my app from their Store because it was competing with theirs").
If I want to develop with Qualcomm boards, I need to sign all sorts of NDAs, and they don't even have emulators for development. Do you think that should be illegal?
I wish we tried to honestly make the difference between what is an inconvenience ("I don't want to need a macOS system to deploy on iOS") and what is abuse ("Apple removed my app from their Store because it was competing with theirs").
Asking Apple to properly support CSS is crying abuse?
What comment did you read?
Could you reply to mine, if you're replying to me?
Specifically my reply in the context of the OP (is emulation necessary, when your web view of your OS just...does what it's supposed to?)
What comment did you read?
Could you reply to mine, if you're replying to me?
Specifically my reply in the context of the OP (is emulation necessary, when your web view of your OS just...does what it's supposed to?)
Safari supports CSS just fine, other than bleeding edge stuff where they lag a bit.
Maybe we agree to disagree.
https://s-hens.github.io/ios-webkit-quirks/
Feels mildly off-topic anyway.
https://s-hens.github.io/ios-webkit-quirks/
Feels mildly off-topic anyway.
> If PWAs win
That's like saying if Linux on the desktop wins in 2024.
PWAs have been around for about a decade now. The excuses have run out.
That's like saying if Linux on the desktop wins in 2024.
PWAs have been around for about a decade now. The excuses have run out.
I think Apple's failure to provide sufficient capabilities for PWAs is a valid excuse here.
If PWAs are limited competitively on the platform with the highest ROI for developers … that's a problem.
If PWAs are limited competitively on the platform with the highest ROI for developers … that's a problem.
I think it is debatable. Can I make an iOS app in pure Python, and should Apple make it possible? I think Apple has the right to decide what kind of API they provide to their users. Just like nobody is forcing Tesla to allow running Windows "because some developers would like to run Windows apps in their Tesla".
I can see a problem with the monopoly on the App Store given the dominant position of Apple. But if Apple decided tomorrow to remove the screen from all their phones and have audio control only, I think it would be their choice.
I can see a problem with the monopoly on the App Store given the dominant position of Apple. But if Apple decided tomorrow to remove the screen from all their phones and have audio control only, I think it would be their choice.
Why do they have a right to decide what kind of API users can use? I know that's not exactly how you worded it, but on other computing platforms like Windows, Microsoft provides APIs but doesn't prevent developers putting in other APIs. You should be able to write an iOS app in pure Python, but maybe with reliance that someone else provides the bindings so that you can display the graphics. iOS and Android locking out whole possible ecosystems with "only we can decide what code is allowed to run" really sucks.
> Why do they have a right to decide what kind of API users can use?
Because they make a product that they sell. If you make a speaker, you can decide if it has Bluetooth, WiFi or nothing. If you want a speaker that has Bluetooth, you need to buy a speaker that has Bluetooth. Not buy one that doesn't and go ask the EU to force the manufacturer to add Bluetooth.
> iOS and Android locking out whole possible ecosystems with "only we can decide what code is allowed to run" really sucks.
That's a perfectly valid opinion. Others will say that not having root access and having a checked App Store increases the security (and that is true). You can try a Linux phone, if you want freedom.
Because they make a product that they sell. If you make a speaker, you can decide if it has Bluetooth, WiFi or nothing. If you want a speaker that has Bluetooth, you need to buy a speaker that has Bluetooth. Not buy one that doesn't and go ask the EU to force the manufacturer to add Bluetooth.
> iOS and Android locking out whole possible ecosystems with "only we can decide what code is allowed to run" really sucks.
That's a perfectly valid opinion. Others will say that not having root access and having a checked App Store increases the security (and that is true). You can try a Linux phone, if you want freedom.
That's not really the issue the OP is arguing though.
He's saying "PWAs have had 10 years to be good and dominant and they're not yet and that's on them."
I'm saying "Well, but, Apple."
Whether and how Apple should support PWAs is a separate conversation.
He's saying "PWAs have had 10 years to be good and dominant and they're not yet and that's on them."
I'm saying "Well, but, Apple."
Whether and how Apple should support PWAs is a separate conversation.
> Can I make an iOS app in pure Python
https://python.plainenglish.io/python-for-ios-the-ultimate-g...
Yes?
https://python.plainenglish.io/python-for-ios-the-ultimate-g...
Yes?
> Can I make an iOS app in pure Python, and should Apple make it possible?
Given that neither the browser or iOS runtime can interpret it, no? I think it's reasonable to expect people to write an iOS Python interpreter and expect to get that distributed though. And if the users deliberately install it, what's the problem?
> Just like nobody is forcing Tesla
Tesla has to certify vehicles as road-safe. Besides FCC compliance (which Android handles just fine), Apple doesn't really have many legal safety obligations to use as a defense. Unlike a Tesla, Apple can let users sideload iOS apps without threatening other users around them.
Given that neither the browser or iOS runtime can interpret it, no? I think it's reasonable to expect people to write an iOS Python interpreter and expect to get that distributed though. And if the users deliberately install it, what's the problem?
> Just like nobody is forcing Tesla
Tesla has to certify vehicles as road-safe. Besides FCC compliance (which Android handles just fine), Apple doesn't really have many legal safety obligations to use as a defense. Unlike a Tesla, Apple can let users sideload iOS apps without threatening other users around them.
Maybe I did not express myself well. My point was that Apple not embracing PWAs is their choice, I don't see the problem there.
I see a problem with the idea that "we did not convince Apple with our PWAs, that's probably because they are evil, so now we'll try to force them with the law".
I see a problem with the idea that "we did not convince Apple with our PWAs, that's probably because they are evil, so now we'll try to force them with the law".
Why do you see that as a problem? Apple is welcome to leave if they disagree with Europe's market terms. They didn't leave Russia when they made their demands though, and Lord knows they're deep enough in bed with China. Whipping up a fuss over sideloading and PWA guidelines is a red herring; Apple is just butthurt that regulators found their infinite service revenue loophole.
Apple has every right to self-determination, but sometimes that means deciding whether they agree with the law.
Apple has every right to self-determination, but sometimes that means deciding whether they agree with the law.
> Why do you see that as a problem? Apple is welcome to leave if they disagree with Europe's market terms.
The problem I see is that IMHO, the law should not force Apple to accept a new technology just because web devs don't want to learn Apple's technology (that provide at least the same features as PWAs).
> Whipping up a fuss over sideloading and PWA guidelines is a red herring; Apple is just butthurt that regulators found their infinite service revenue loophole.
That's the thing: you conflate the App Store with the PWAs, and that's where I disagree. Enabling side-loading of native iOS apps is completely orthogonal to enabling PWAs. For some reasons pro-PWAs hijacked the side-loading lobbying effort and are trying to leverage it for their own agenda.
The problem I see is that IMHO, the law should not force Apple to accept a new technology just because web devs don't want to learn Apple's technology (that provide at least the same features as PWAs).
> Whipping up a fuss over sideloading and PWA guidelines is a red herring; Apple is just butthurt that regulators found their infinite service revenue loophole.
That's the thing: you conflate the App Store with the PWAs, and that's where I disagree. Enabling side-loading of native iOS apps is completely orthogonal to enabling PWAs. For some reasons pro-PWAs hijacked the side-loading lobbying effort and are trying to leverage it for their own agenda.
Well, you're welcome to take issue with that I suppose. The way I see it, Apple has invited this for years; the only way in their ecosystem is through the App Store or the browser. If they make unreasonable demands out of their App Store, the exploitation of the browser will be next. It's been this way since Cydia, really.
Much as we'd rather deny it, the App Store and Safari are inextricably linked on iOS. There aren't alternatives allowed to either, and the purpose leads back to the same reason; control. It's really not hard to see how Apple's desire for stable service revenue is at-odds with the capabilities of their platform. The DMA and the DSA both give Apple the ultimatum; loosen up or ship out.
Much as we'd rather deny it, the App Store and Safari are inextricably linked on iOS. There aren't alternatives allowed to either, and the purpose leads back to the same reason; control. It's really not hard to see how Apple's desire for stable service revenue is at-odds with the capabilities of their platform. The DMA and the DSA both give Apple the ultimatum; loosen up or ship out.
> And if the users deliberately install it, what's the problem?
And is this a universal principle of yours?
For instance, would you say the same about malware—that anyone should have the right to develop it, and use whatever shady tactics they want to trick people into installing it—and if they do, that becomes their problem?
And is this a universal principle of yours?
For instance, would you say the same about malware—that anyone should have the right to develop it, and use whatever shady tactics they want to trick people into installing it—and if they do, that becomes their problem?
Users don't deliberately install malware, though. They do install Python runtimes; you can secure this the exact same way desktops have done for decades, by signing executable.
It's literally elementary stuff.
It's literally elementary stuff.
Users don't deliberately install malware that's called "Install This To Give All Your Money To Scammers."
They deliberately install an app that's called "Funny Videos Daily Ha Ha!", that also has a rootkit or whatever that gives all their money to scammers.
They deliberately install an app that's called "Funny Videos Daily Ha Ha!", that also has a rootkit or whatever that gives all their money to scammers.
There is always some API that is missing for PWAs to explode in popularity.
And then when you pin someone down it's never actually about APIs or capabilities.
It's about the ability to deploy apps to your phone whenever they like with full access to everything and nothing in their way.
And then when you pin someone down it's never actually about APIs or capabilities.
It's about the ability to deploy apps to your phone whenever they like with full access to everything and nothing in their way.
This I generally agree with.
Native apps will always gain capabilities before PWAs, and some capabilities will never be granted to PWAs for incredibly sane reasons.
However, for many apps, Push Notifications was the only real reason they couldn't be a PWA.
Native apps will always gain capabilities before PWAs, and some capabilities will never be granted to PWAs for incredibly sane reasons.
However, for many apps, Push Notifications was the only real reason they couldn't be a PWA.
I believe PWAs have a place in highly “templatable” things like restaurant pages and online shops. Those I can see adding to my home screen. Anything more complex than those is questionable.
Why do you need to 'install' a restaurant app/website?
That's the perfect usecase for like... a website.
That's the perfect usecase for like... a website.
For most uses, "install" = hold my auth and put a bookmark on my home screen.
In that regard, webapps work perfectly.
In that regard, webapps work perfectly.
For quick access without cluttering browser tabs and bookmarks.
You value real-estate on your home screen less than in your bookmarks?
It’s more that the number of sites I’d add to my home screen has a hard upper bound that’s not high, management is easy, and if I want one without it being on the home screen I can send it to the app library instead, where it’ll surface with a search.
Bookmarks on the other hand are unbounded and suck to manage (no browser has improved meaningfully in this realm in ~20 years for some reason) so the threshold for what gets bookmarked is higher.
Bookmarks on the other hand are unbounded and suck to manage (no browser has improved meaningfully in this realm in ~20 years for some reason) so the threshold for what gets bookmarked is higher.
I search for installed apps on my phone quite regularly. It's often faster than remembering where the hell it is in my folders on screen.
It's a spectrum.
Some things are important enough for a bookmark, others are important enough for home screen.
Some things are important enough for a bookmark, others are important enough for home screen.
It just feels a bit of an edgecase to imagine that a menu of a specific restaurant is important enough to occupy a spot in the top 20-25 of your digital real estate.
What about a movie theater?
Why would you need quick access to one restaurant’s menu?
If you go there infrequently, I don’t understand why you would clutter up any part of my phone - bookmarks or Home Screen - with its menu. If you go there frequently… you already know the menu?
If you go there infrequently, I don’t understand why you would clutter up any part of my phone - bookmarks or Home Screen - with its menu. If you go there frequently… you already know the menu?
> If you go there frequently… you already know the menu?
For most places, but there are a handful that have huge menus. Its name escapes me but for instance when I lived in SF there was a sandwich place I frequented that was one such shop and aside from a couple of favorites I could never remember everything they had.
Also, these sites tend to facilitate ordering ahead, ordering delivery etc too so it’s not just a static HTML file.
For most places, but there are a handful that have huge menus. Its name escapes me but for instance when I lived in SF there was a sandwich place I frequented that was one such shop and aside from a couple of favorites I could never remember everything they had.
Also, these sites tend to facilitate ordering ahead, ordering delivery etc too so it’s not just a static HTML file.
Also if they have online menus or ordering they usually have a QR code on the table or nearby. No need to bookmark or save anywhere.
PWAs will only replace native apps when the operating systems support them properly. Let's see how the European Union moves forward with the Digital Markets Act.
Let's see if a regulation like that can tame Apple, or if Apple keeps finding loop holes to not fully comply in the intended way (to liberate the European market from oligopolist gate keeping companies). If it works there might be a further revision that forces Apple to support PWAs. And on the long run I don't think they will limit those features just to the European market.
Once alternative browser engines and alternative app stores arrive, it might be possible to provide an app store that just wraps any known PWA into a native iOS app and runs them inside a Chromium browser. With full PWA support. Like the Microsoft store does. You can just register your PWA there and it will show up in the store, they even had the plan to scan the web for PWAs and put them in the store even if the author didn't register it. I don't know if they ever followed though with that plan.
One positive mention: I recently switched my PWAs on Windows to Edge, and it's the best PWA experience I've ever had on any platform. A good PWA feels 98% like a native application.
Let's see if a regulation like that can tame Apple, or if Apple keeps finding loop holes to not fully comply in the intended way (to liberate the European market from oligopolist gate keeping companies). If it works there might be a further revision that forces Apple to support PWAs. And on the long run I don't think they will limit those features just to the European market.
Once alternative browser engines and alternative app stores arrive, it might be possible to provide an app store that just wraps any known PWA into a native iOS app and runs them inside a Chromium browser. With full PWA support. Like the Microsoft store does. You can just register your PWA there and it will show up in the store, they even had the plan to scan the web for PWAs and put them in the store even if the author didn't register it. I don't know if they ever followed though with that plan.
One positive mention: I recently switched my PWAs on Windows to Edge, and it's the best PWA experience I've ever had on any platform. A good PWA feels 98% like a native application.
If your free app will get popular with new rules then your free app will cost a lot for a developer.
For example 2.5M installs/updates a year will cost you Total monthly fees $ 67,935
https://developer.apple.com/support/fee-calculator-for-apps-...
For example 2.5M installs/updates a year will cost you Total monthly fees $ 67,935
https://developer.apple.com/support/fee-calculator-for-apps-...
It looks like Apple found a loop hole. I don’t think this loop hole will stay open for long.
Edit: I really think that we will soon get an addendum to this law that will limit those fees. In a similar way mobile phone roaming fees got regulated.
Edit: I really think that we will soon get an addendum to this law that will limit those fees. In a similar way mobile phone roaming fees got regulated.
In response to your edit: I doubt it.
1. Remember, the EC feels that American tech companies are unfairly stifling competition from European tech companies. They’re not going to just wholesale ban monetization of intellectual property, which is what banning the core technology fee would do—that’s not a useful precedent if you’re trying to boost the euro tech scene.
2. It really feels like most of the arguments against Apple’s DMA compliance plan come from a place of “I hate Apple, what alternative reality can I imagine in which they make no money?” If Apple’s profits are regulated out of existence in Europe, they’re simply going to stop offering products for the European market. Problem solved, I guess?
But like another commenter wrote, be careful what you wish for. I don’t think that’s actually what devs want, mainly because today iOS is the self-selected, lucrative market for independent software. That’s where the customers are who will pay you for Apps. That’s why nobody cares that Google charges just as much as Apple.
1. Remember, the EC feels that American tech companies are unfairly stifling competition from European tech companies. They’re not going to just wholesale ban monetization of intellectual property, which is what banning the core technology fee would do—that’s not a useful precedent if you’re trying to boost the euro tech scene.
2. It really feels like most of the arguments against Apple’s DMA compliance plan come from a place of “I hate Apple, what alternative reality can I imagine in which they make no money?” If Apple’s profits are regulated out of existence in Europe, they’re simply going to stop offering products for the European market. Problem solved, I guess?
But like another commenter wrote, be careful what you wish for. I don’t think that’s actually what devs want, mainly because today iOS is the self-selected, lucrative market for independent software. That’s where the customers are who will pay you for Apps. That’s why nobody cares that Google charges just as much as Apple.
What the EC wants is more or less what you get with Windows, macOS or Android. Being able to install apps from any source and being able to buy apps from any app store/vendor without them being forced to pay commission/fees to Apple.
It doesn't have any connection to "monetization of intellectual property", just look at Windows, Android, macOS, and all other operating systems.
iOS can stay closed source, Apple can keep selling it to customers (on their iPhones), Apple might even stop providing SDKs at all and stop allowing third party apps on their phones. But they shouldn't be able to be a "gate keeper" and charge commission to third parties releasing apps/content on their platform. Because this is killing competition and free markets.
I understand there are implications for opening iOS to other app stores.
It doesn't have any connection to "monetization of intellectual property", just look at Windows, Android, macOS, and all other operating systems.
iOS can stay closed source, Apple can keep selling it to customers (on their iPhones), Apple might even stop providing SDKs at all and stop allowing third party apps on their phones. But they shouldn't be able to be a "gate keeper" and charge commission to third parties releasing apps/content on their platform. Because this is killing competition and free markets.
I understand there are implications for opening iOS to other app stores.
> What the EC wants is more or less what you get with Windows, macOS or Android.
That’s the what not the why. The why is that they want a tech industry in Europe that’s worthy of the term.
> It doesn't have any connection to "monetization of intellectual property", just look at Windows, Android, macOS, and all other operating systems.
Yes, look at them. And don’t stop there. Look at game consoles and the Epic store, for that matter. Companies license their intellectual property to other companies all the time. To use VSCode for commercial windows development, you must pay the Microsoft tax. You must pay to use Epic’s game engine commercially. So why can’t Apple charge to use their SDK too?
The point is that Europe isn’t going to have much of a tech industry if the EC sets the precedent that you can’t charge money for IP.
> But they shouldn't be able to be a "gate keeper" and charge commission to third parties releasing apps/content on their platform.
Ok, so now we’re back to “not allowed to charge for their IP”. Which is contrary to the goal of having a European tech industry.
But, are you even reading what you’re writing? You’d be ok with Apple just completely shutting out 3rd party apps, but you’re not ok with them allowing 3rd parties to license certain tech?
That’s the what not the why. The why is that they want a tech industry in Europe that’s worthy of the term.
> It doesn't have any connection to "monetization of intellectual property", just look at Windows, Android, macOS, and all other operating systems.
Yes, look at them. And don’t stop there. Look at game consoles and the Epic store, for that matter. Companies license their intellectual property to other companies all the time. To use VSCode for commercial windows development, you must pay the Microsoft tax. You must pay to use Epic’s game engine commercially. So why can’t Apple charge to use their SDK too?
The point is that Europe isn’t going to have much of a tech industry if the EC sets the precedent that you can’t charge money for IP.
> But they shouldn't be able to be a "gate keeper" and charge commission to third parties releasing apps/content on their platform.
Ok, so now we’re back to “not allowed to charge for their IP”. Which is contrary to the goal of having a European tech industry.
But, are you even reading what you’re writing? You’d be ok with Apple just completely shutting out 3rd party apps, but you’re not ok with them allowing 3rd parties to license certain tech?
Apple does not charge for "using their SDK". They charge for installing (commercial) applications to devices they produce and sell.
Even if I build an application completely without the Apple SDK, just with open source software, I can't sell it to people without paying the "Apple tax".
Your example VS Code is not related to that at all, because Microsoft doesn't prevent installing applications built with other tools.
Same with the Epic game engine. Windows/Android/etc don't force you to use the Epic game engine for all games built on their platform. You can use any other technology of your choice.
What Apple is doing right now is comparable to a car manufacturer that would only allow you filling up your tank at their own gas stations. For +30% the market price. And a lot of countries would not allow this kind of anti-competitive behaviour.
In the EU for example all car manufacturers need to provide documentation and spare parts to third party shops. So the car manufacturer can't force buyers to rely on their potentially overpriced services, discriminate competitors and prevent the development of a free market.
I know that this kind of "market freedom" is something that doesn't feel right for US citizens.
Even if I build an application completely without the Apple SDK, just with open source software, I can't sell it to people without paying the "Apple tax".
Your example VS Code is not related to that at all, because Microsoft doesn't prevent installing applications built with other tools.
Same with the Epic game engine. Windows/Android/etc don't force you to use the Epic game engine for all games built on their platform. You can use any other technology of your choice.
What Apple is doing right now is comparable to a car manufacturer that would only allow you filling up your tank at their own gas stations. For +30% the market price. And a lot of countries would not allow this kind of anti-competitive behaviour.
In the EU for example all car manufacturers need to provide documentation and spare parts to third party shops. So the car manufacturer can't force buyers to rely on their potentially overpriced services, discriminate competitors and prevent the development of a free market.
I know that this kind of "market freedom" is something that doesn't feel right for US citizens.
> Apple does not charge for "using their SDK". They charge for installing (commercial) applications to devices they produce and sell.
The mechanics of how the fee is charged don't determine what it is for. This is like saying Amazon charges you a $49 fee to use their checkout page when ordering a book.
> Your example VS Code is not related to that at all, because Microsoft doesn't prevent installing applications built with other tools. Same with the Epic game engine. Windows/Android/etc don't force you to use the Epic game engine for all games built on their platform. You can use any other technology of your choice.
Nobody is forcing you to use Apple's SDK, either: You are free to use open-source software or to write your own... Of course those tools do not exist today, and your PM probably wants to ship the app sometime this decade. Nothing stops you from doing it yourself, but you would save a lot of work if you use Apple's. This is like complaining that your neighbor built a nice house and now he won't let you live it in for free when you are not willing to do the work to build your own house.
> Even if I build an application completely without the Apple SDK, just with open source software, I can't sell it to people without paying the "Apple tax".
Irrelevant. As of today there is no distinction between "an iOS app" and "an iOS app made using Apple's tools which attracts a fee from Apple".
Anyway, you are trying to diverge from the point: As I stated before, if the EC declares Apple's fee illegal (when there is no alternative tool), that sets a precedent that you cannot charge reasonable fees to license intellectual property. That is contrary to the aim of the DMA to encourage the European tech industry. Thus, predict they will make no attempt to close this supposed loophole.
Additionally, the actual DMA, as far as I can tell from English Wikipedia says nothing about gatekeepers charging fees generally, nor allowing free side-loading specifically.
> In the EU for example all car manufacturers need to provide documentation and spare parts to third party shops.
And those parts are free (as in beer)? No, you pay a reasonable price for them. Here is just the same. Third party software shops pay a reasonable fee, and then do whatever they want with the parts Apple provides. In this case the documentation fee is $99, plus $0.50 per part. If you are a registered non-commercial entity, Apple will even give you the parts for free.
> I know that this kind of "market freedom" is something that doesn't feel right for US citizens.
You mean the kind of market freedom where Spotify (with a 70% market share) is not a monopoly (sorry, "gatekeeper") and Apple (with a 30% market share) somehow is a gatekeeper? Spotify had over $13B in revenue, but paid just $9B to record companies last year. Won't anyone think of those poor record companies that have to pay *35%* "Spotify tax"? Doesn't anyone care that Spotify prevents record companies from having a human relationship with their listeners (and offering Exceptional Customer Service)? Oh, wait, I forgot: they're Americans and the gatekeeper is based in Sweden, and maybe someone is a friend of a friend, so we don't care right?
Yea, I guess I don't mind when the government doesn't have the "freedom" to arbitrarily decide who its friends and enemies are. Rule by law, not by man. Due process and all that. Y'all should try it over there sometime.
The mechanics of how the fee is charged don't determine what it is for. This is like saying Amazon charges you a $49 fee to use their checkout page when ordering a book.
> Your example VS Code is not related to that at all, because Microsoft doesn't prevent installing applications built with other tools. Same with the Epic game engine. Windows/Android/etc don't force you to use the Epic game engine for all games built on their platform. You can use any other technology of your choice.
Nobody is forcing you to use Apple's SDK, either: You are free to use open-source software or to write your own... Of course those tools do not exist today, and your PM probably wants to ship the app sometime this decade. Nothing stops you from doing it yourself, but you would save a lot of work if you use Apple's. This is like complaining that your neighbor built a nice house and now he won't let you live it in for free when you are not willing to do the work to build your own house.
> Even if I build an application completely without the Apple SDK, just with open source software, I can't sell it to people without paying the "Apple tax".
Irrelevant. As of today there is no distinction between "an iOS app" and "an iOS app made using Apple's tools which attracts a fee from Apple".
Anyway, you are trying to diverge from the point: As I stated before, if the EC declares Apple's fee illegal (when there is no alternative tool), that sets a precedent that you cannot charge reasonable fees to license intellectual property. That is contrary to the aim of the DMA to encourage the European tech industry. Thus, predict they will make no attempt to close this supposed loophole.
Additionally, the actual DMA, as far as I can tell from English Wikipedia says nothing about gatekeepers charging fees generally, nor allowing free side-loading specifically.
> In the EU for example all car manufacturers need to provide documentation and spare parts to third party shops.
And those parts are free (as in beer)? No, you pay a reasonable price for them. Here is just the same. Third party software shops pay a reasonable fee, and then do whatever they want with the parts Apple provides. In this case the documentation fee is $99, plus $0.50 per part. If you are a registered non-commercial entity, Apple will even give you the parts for free.
> I know that this kind of "market freedom" is something that doesn't feel right for US citizens.
You mean the kind of market freedom where Spotify (with a 70% market share) is not a monopoly (sorry, "gatekeeper") and Apple (with a 30% market share) somehow is a gatekeeper? Spotify had over $13B in revenue, but paid just $9B to record companies last year. Won't anyone think of those poor record companies that have to pay *35%* "Spotify tax"? Doesn't anyone care that Spotify prevents record companies from having a human relationship with their listeners (and offering Exceptional Customer Service)? Oh, wait, I forgot: they're Americans and the gatekeeper is based in Sweden, and maybe someone is a friend of a friend, so we don't care right?
Yea, I guess I don't mind when the government doesn't have the "freedom" to arbitrarily decide who its friends and enemies are. Rule by law, not by man. Due process and all that. Y'all should try it over there sometime.
seriously?!
There is no loop hole.
Apple is able to charge a per-sale license fee for using their SDKs same as Epic, Microsoft etc.
There isn't a single court or government in the world who has disagreed with this.
Apple is able to charge a per-sale license fee for using their SDKs same as Epic, Microsoft etc.
There isn't a single court or government in the world who has disagreed with this.
No thats not the intent of the newly passed digital markets act which will come into effect soon.
But I am happy to come back to you when the EU takes action though!
Anti-trust laws are perfectly legal. We can make and enforce laws that force Apple to change, just like laws exist in all parts of the world.
But I am happy to come back to you when the EU takes action though!
Anti-trust laws are perfectly legal. We can make and enforce laws that force Apple to change, just like laws exist in all parts of the world.
You have invented that intent.
Because it is not in the act nor have there been any public statements about it.
Because it is not in the act nor have there been any public statements about it.
The intent was for people to be able to freely sideload apps.
Also, it is in the law. There was a specific part where it said that gatekeepers cannot sidestep the law via contractual terms, or something similar to that.
But once again, I am more that happy to come back to you when the EU regulators take action against Apple, to force them to comply.
Will you admit that you are wrong if action is taken by the EU regulators against Apple?
Also, it is in the law. There was a specific part where it said that gatekeepers cannot sidestep the law via contractual terms, or something similar to that.
But once again, I am more that happy to come back to you when the EU regulators take action against Apple, to force them to comply.
Will you admit that you are wrong if action is taken by the EU regulators against Apple?
I think you're completely missing the point.
The problem is not access to the SDK, the problem is that Apple is locking down their platform to competitors. They can't sell apps or content without giving a commission to the "gate keeper" Apple.
Epic is not one of the biggest device manufacturers. And Microsoft is definitively not locking out third party developers from Windows. Everyone can just sell Windows applications without paying Microsoft a dime. Windows is even fully open to PWAs, with the Edge browser from Microsoft or any other third party browser.
The problem is not access to the SDK, the problem is that Apple is locking down their platform to competitors. They can't sell apps or content without giving a commission to the "gate keeper" Apple.
Epic is not one of the biggest device manufacturers. And Microsoft is definitively not locking out third party developers from Windows. Everyone can just sell Windows applications without paying Microsoft a dime. Windows is even fully open to PWAs, with the Edge browser from Microsoft or any other third party browser.
> They can't sell apps or content without giving a commission to the "gate keeper" Apple
Again. There isn't a single court or government that has said this is not permitted.
Including the EU.
Again. There isn't a single court or government that has said this is not permitted.
Including the EU.
False, that's exactly what the Digital Markets Act is about.
Apple is trying to circumvent it right now with those new fees, and I think this won't hold in court.
https://commission.europa.eu/strategy-and-policy/priorities-...
Apple is trying to circumvent it right now with those new fees, and I think this won't hold in court.
https://commission.europa.eu/strategy-and-policy/priorities-...
Ok, so charge each user $1? Problem solved.
Abs then your 2.4M install base turns into 50k installs, instead.
Well, gee, if users think the app isn’t worth even $1 (what can you even buy for a dollar these days?), it sounds like not much was lost by limiting its distribution.
Ok, you can give me $1 for replying to my comment.
Thanks
Thanks
> PWAs will only replace native apps when the operating systems support them properly.
There's a whole operating system dominating the mobile market that "supports PWAs properly". We've yet to se any significant number of these great beautiful useful usable PWAs
There's a whole operating system dominating the mobile market that "supports PWAs properly". We've yet to se any significant number of these great beautiful useful usable PWAs
I think developers need to clearly put blame on Apple for PWA not working. In apps you're not allowed to mention apple's shady behaviour when it comes to fees, but on the web you can.
Since 2016 I've had the option for users to enable push notifications, with a big red disclaimer if the user is using iOS that it does not work on an iPhone. Still, I got so so many requests from user saying they had tried with Chrome(or whatever other browser) instead, and it's still not working, not understanding that all browsers on iOS is limited in the same way because of apple.
If there are any more problems with web push on iOS I'll clearly tell the user that Apple doesn't allow the user to use it, and that they will have to ask apple to enable it, and give them contact information. If the user bought the phone expecting web push to work then they can probably return it and buy an Android phone instead if the seller can't fix web push.
Since 2016 I've had the option for users to enable push notifications, with a big red disclaimer if the user is using iOS that it does not work on an iPhone. Still, I got so so many requests from user saying they had tried with Chrome(or whatever other browser) instead, and it's still not working, not understanding that all browsers on iOS is limited in the same way because of apple.
If there are any more problems with web push on iOS I'll clearly tell the user that Apple doesn't allow the user to use it, and that they will have to ask apple to enable it, and give them contact information. If the user bought the phone expecting web push to work then they can probably return it and buy an Android phone instead if the seller can't fix web push.
> I think developers need to clearly put blame on Apple for PWA not working.
I think that developers need to choose technologies that work on the platform they want to support, instead of blaming the platform. It is totally valid for Apple to say "if you want to develop an iOS app, use the iOS native framework".
> If the user bought the phone expecting web push to work then they can probably return it and buy an Android phone instead if the seller can't fix web push.
Who sells an iPhone saying explicitly that web push works? I guess nobody (it would make no sense). If a user bought a phone expecting to be able to use it as a surfboard, they probably can NOT return it for that reason.
I think that developers need to choose technologies that work on the platform they want to support, instead of blaming the platform. It is totally valid for Apple to say "if you want to develop an iOS app, use the iOS native framework".
> If the user bought the phone expecting web push to work then they can probably return it and buy an Android phone instead if the seller can't fix web push.
Who sells an iPhone saying explicitly that web push works? I guess nobody (it would make no sense). If a user bought a phone expecting to be able to use it as a surfboard, they probably can NOT return it for that reason.
I don't think there's a "should" here, it's just that as a developer, I don't like dealing with Apple and chose long ago to stop taking jobs as an iPhone app dev. I'd only do it for significant extra money. And my side projects don't go out of their way to support iPhones anymore. If Apple cleans up their act, I'll reconsider, not that my single decision sways them at all.
The surfboard analogy is silly; it’s reasonable that the user expects the iPhone to be a general computing device (since it’s a powerful computer).
I exaggerated to make my point. It's absolutely not reasonable to expect <arbitrary feature> to run on an iPhone. Otherwise I can extend it to anything. Would you say that "If the user bought the phone expecting to have root access then they can probably return it" is reasonable? If yes, just try to return your iPhone and see :-).
PWAs will never be as good as native, definitionally. There is always API drift. There is always runtime cost. Nothing inside a system can ever have parity with its parent container. If it could, it would be the system itself.
People's experience with hardware and physical objects matters. If you accept that, you should always want to be closer to the metal at the cost of convenience or portability.
People's experience with hardware and physical objects matters. If you accept that, you should always want to be closer to the metal at the cost of convenience or portability.
I don't understand why you got downvoted for this. Cross-platform is never as good as native, but in some situations it is cheaper. And there is a need for "cheaper but not as good" (we don't all drive a Porsche, do we?).
There are constant complaints about electron apps being bad and people wanting native apps, except in the case of PWAs. I can't keep all the complaining straight lol
Electron apps are getting much better.
VS Code is considered the best app in its class by a distant margin and it’s an electron app.
The first round of Electron apps were created by people who were simply trying to get some cross platform native version of their apps out.
It’s only been recently that companies are now creating electron apps as first class products and now those apps are doing very well.
VS Code is considered the best app in its class by a distant margin and it’s an electron app.
The first round of Electron apps were created by people who were simply trying to get some cross platform native version of their apps out.
It’s only been recently that companies are now creating electron apps as first class products and now those apps are doing very well.
> VS Code is considered the best app in its class by a distant margin and it’s an electron app.
Yes, and by now they have spent spent hundreds of millions of dollars and hundreds of man-years of dev time on it. And it's still the only poster child for "good Electron app"
Yes, and by now they have spent spent hundreds of millions of dollars and hundreds of man-years of dev time on it. And it's still the only poster child for "good Electron app"
The popularity of VSCode is mystifying to me: IntelliJ is a much nicer application and VSCode always ends up lagging randomly for me.
They both lag. They're both resource hogs. IntelliJ has a better out of the box experience. VSCode has a much much more diverse and interesting plugin ecosystem. I run both. VSCode is interesting in that, depending on the project and/or the plugins required for that project, it can be much kinder or much worse on my battery life. IntelliJ is more predictably bad.
All being equal I'd choose VSCode at this point. When I want to do something like run tests the test plugins for pretty much everything I've looked at are way better. IntelliJ has some powerful configuration capabilities that somehow always manage to be constrained in a sucky way. Support answers are like "oh you want to do THAT. No, you can't do that, read this doc" where the VSCode way would tend to not be as configurable but support the thing you actually wanted to do.
Plus VSCode plugins are majority free. It's not that I mind playing for plugins per se, but my experience with Intellij plugins has been poor, so I don't want to go through the hassle of paying to find out it's rubbish.
All being equal I'd choose VSCode at this point. When I want to do something like run tests the test plugins for pretty much everything I've looked at are way better. IntelliJ has some powerful configuration capabilities that somehow always manage to be constrained in a sucky way. Support answers are like "oh you want to do THAT. No, you can't do that, read this doc" where the VSCode way would tend to not be as configurable but support the thing you actually wanted to do.
Plus VSCode plugins are majority free. It's not that I mind playing for plugins per se, but my experience with Intellij plugins has been poor, so I don't want to go through the hassle of paying to find out it's rubbish.
IntelliJ is very expensive and VS Code is free. That's a big driver for popularity.
JetBrains isn’t “very expensive”: for one thing, there’s a free and open source community edition; for another, the IntelliJ license is about the same as a Netflix subscription and, rather than being a pure cost, it’s a tool that supports one’s valuable skills.
The community edition only supports Java-style languages (and python with the PyCharm version). It's no match for the huge breadth of free vscode plugins.
And it's very hard to compete with free. You really have to code a lot to make it worth it. Personally I don't usually have a Netflix subscription because of the price though I'd sometimes get it for a month or so to watch something particular.
And for work purposes it's the difference of just being able to start using it versus justifying the expense to multiple levels in the org which can be prohibitive.
I totally understand how VS Code took fight like it did with its free model.
And it's very hard to compete with free. You really have to code a lot to make it worth it. Personally I don't usually have a Netflix subscription because of the price though I'd sometimes get it for a month or so to watch something particular.
And for work purposes it's the difference of just being able to start using it versus justifying the expense to multiple levels in the org which can be prohibitive.
I totally understand how VS Code took fight like it did with its free model.
i've found the opposite, once the codebase is large enough jetbrains ides get slower and slower. i've been on teams which had to split their monorepo because it was so bad
Same here, I love the JetBrains IDEs.
Except VS Code is missing tons of native functionality that makes it still feel out of place.
Strong disagree.
Sure, theoretically, any PWA could possibly be developed as a better native app.
But in the real world people develop apps. If the iOS app developer and designer market declines, then even if theoretically a native app would be better, the best developers and designers will have little to no experience with native and so the best apps will likely be PWAs where the best developers and designers are.
Native only always win if you’re looking at the capability of the platform as the only constraint. In reality, the developer/designer market, money available to develop apps, money and resources available to maintain apps, etc are all additional constraints for real apps, and native apps have significant disadvantages in those other constraints.
Sure, theoretically, any PWA could possibly be developed as a better native app.
But in the real world people develop apps. If the iOS app developer and designer market declines, then even if theoretically a native app would be better, the best developers and designers will have little to no experience with native and so the best apps will likely be PWAs where the best developers and designers are.
Native only always win if you’re looking at the capability of the platform as the only constraint. In reality, the developer/designer market, money available to develop apps, money and resources available to maintain apps, etc are all additional constraints for real apps, and native apps have significant disadvantages in those other constraints.
> If the iOS app developer and designer market declines
That's a pretty huge "if". If the web developer market declines, then native will be better, too.
> In reality, the developer/designer market, money available to develop apps, money and resources available to maintain apps, etc are all additional constraints for real apps, and native apps have significant disadvantages in those other constraints.
In my experience, the reality is much more nuanced than that. There are plenty of mobile devs, and many will tell you that they are not slower writing two apps (iOS/Android) than writing one cross-platform one. I don't know a single mobile dev who likes a cross-platform framework better than the native experience, too.
No really, I think cross-platform seems cheaper if you are a manager (and don't really have experience with any of those frameworks) or if you are a web dev (and don't really have experience with mobile frameworks).
That's a pretty huge "if". If the web developer market declines, then native will be better, too.
> In reality, the developer/designer market, money available to develop apps, money and resources available to maintain apps, etc are all additional constraints for real apps, and native apps have significant disadvantages in those other constraints.
In my experience, the reality is much more nuanced than that. There are plenty of mobile devs, and many will tell you that they are not slower writing two apps (iOS/Android) than writing one cross-platform one. I don't know a single mobile dev who likes a cross-platform framework better than the native experience, too.
No really, I think cross-platform seems cheaper if you are a manager (and don't really have experience with any of those frameworks) or if you are a web dev (and don't really have experience with mobile frameworks).
PWAs can absolutely be as good as native, however they aren't being given a chance due to reasons unrelated to technology. I personally believe it is the protection of Apple's fees that is driving its poor implementation of web technologies (even though their original plan was to only have web apps, with a small number of native apps for very specific things). The money they could extract from the app store made them change their tune re web apps, and they've managed to convince every Apple fan it's for their benefit. Unfortunately, this goes unchallenged by the average Apple user, who lacks the tech knowledge or desire to question Apple.
No, not definitionally. Some kinds of apps simply can't be native in iOS, either because of their content or their function. Whatever gimped version ends up on the app store is worse than what can be found on the web.
> Nothing inside a system can ever have parity with its parent container. If it could, it would be the system itself.
I have no idea what you mean by this, can you give some justification? It sounds kind of nonsensical
> you should always want to be closer to the metal at the cost of convenience or portability.
Right but that isn't really a thing anymore. Even machine code is very abstract compared to the actual physical processes going on inside. Bare metal programming is an illusion for pipelined CPUs with speculative execution
I have no idea what you mean by this, can you give some justification? It sounds kind of nonsensical
> you should always want to be closer to the metal at the cost of convenience or portability.
Right but that isn't really a thing anymore. Even machine code is very abstract compared to the actual physical processes going on inside. Bare metal programming is an illusion for pipelined CPUs with speculative execution
> Right but that isn't really a thing anymore.
"Wanting to be closer" does not mean "needing to be at the lowest theoretical level". In this case it just means that native mobile frameworks are one layer of abstraction lower than web frameworks, and it is better (not cheaper, not easier, but better).
"Wanting to be closer" does not mean "needing to be at the lowest theoretical level". In this case it just means that native mobile frameworks are one layer of abstraction lower than web frameworks, and it is better (not cheaper, not easier, but better).
Native libraries are already an huge abstraction. Anyone can write a GUI framework, even on iPhone. I don’t understand where the line is being drawn here
I am not the OP, but my line here is between the APIs provided by Apple and the third-party abstractions. As an iOS developer, the "lowest" you can get is the Apple framework. PWAs are a third-party abstraction on top of that, which come with all the risks/limitations of both third-party dependencies and abstractions.
I just don't really agree, almost all modern JS engines compile to machine code, so it's as "low" as writing Swift or Objective-C.
The JIT aspect is merely one component of the larger picture. With PWA’s specifically you have the entire browser stack to move around. Native code simply does not have this constraint.
They are (IMO) correct that having less layers between you and the lowest layer is ideal. The browser is an engineering marvel but it’s still a nuisance to work around.
They are (IMO) correct that having less layers between you and the lowest layer is ideal. The browser is an engineering marvel but it’s still a nuisance to work around.
I think you're not talking about the same thing. What I am saying is that if you depend only on Apple and their framework, then you have all the improvements as soon as they exist and you don't really have the risk that Apple stops developing iOS (or if they do, then iOS is most likely dead).
If you depend on, say, Qt-for-iOS, then you need Qt to integrate the new features (with more or less success, taking more or less time), and you have a much higher chance that Qt will stop working on iOS some day (or that some important feature never reaches Qt, or that it is super painful to use with iOS).
Removing third party dependencies reduces your risk.
If you depend on, say, Qt-for-iOS, then you need Qt to integrate the new features (with more or less success, taking more or less time), and you have a much higher chance that Qt will stop working on iOS some day (or that some important feature never reaches Qt, or that it is super painful to use with iOS).
Removing third party dependencies reduces your risk.
Sure but the person I originally implied to was not talking about capabilities alone, they were saying how being closer to the metal is strictly better, but there is no inherent link between being closer to the metal and capabilities. It's a mistake to connect the two.
Lets start with a browser based application that struggles with basic IOS capabilities. Not entirely a web app’s fault, but dealing with badges and push notifications will most certainly be a better experience in a native app.
I admit that I am not saddened by this hurdle. The moment that becomes a thing, further enshitification will ensue with every web site trying to drop and icon and start pushing messages.
“Closer to metal”? Not sure you are wrong to ask if there is a line given SwiftUI. That is some very high abstraction.
I admit that I am not saddened by this hurdle. The moment that becomes a thing, further enshitification will ensue with every web site trying to drop and icon and start pushing messages.
“Closer to metal”? Not sure you are wrong to ask if there is a line given SwiftUI. That is some very high abstraction.
I agree that Apple make it so that unless you use their frameworks then you can't use certain functionalities of the OS, but that has nothing to do with being "lower" or "higher". It's just that Apple has a specific abstraction that you must use in order to access those features. It could just as easily be the other way around and have it so that only web apps can access those features and so-called "native" apps cannot. It just has nothing to do with the level of abstraction.
If you wrote pure machine code without system calls you can't even read a file. You have to call into the kernel, which could even be written in javascript, in order to do that.
If you wrote pure machine code without system calls you can't even read a file. You have to call into the kernel, which could even be written in javascript, in order to do that.
Found the article they linked[0] much more interesting / problematic:
> Now, when a user in Europe taps a web app icon, they will see a system message asking if they wish to open it in Safari or cancel. The message adds that the web app "will open in your default browser from now on." When opened in Safari, the web app opens like a bookmark, with no dedicated windowing, notifications, or long-term local storage. Users have seen issues with existing web apps such as data loss, since the Safari version can no longer access local data, as well as broken notifications.
[0] https://www.macrumors.com/2024/02/08/ios-17-4-nerfs-web-apps...
> Now, when a user in Europe taps a web app icon, they will see a system message asking if they wish to open it in Safari or cancel. The message adds that the web app "will open in your default browser from now on." When opened in Safari, the web app opens like a bookmark, with no dedicated windowing, notifications, or long-term local storage. Users have seen issues with existing web apps such as data loss, since the Safari version can no longer access local data, as well as broken notifications.
[0] https://www.macrumors.com/2024/02/08/ios-17-4-nerfs-web-apps...
I expect this is because they have to provide equal standing to other browsers in both user choice and rendering engine, but they don’t have to and have not provided a way to use an alternative browser in the full-screen PWA mode.
Of course, there are numerous ways this could be addressed, such as not changing anything at all if the user chose Safari as their default browser anyway. But it seems quite clear Apple is willing to drag everyone down with them in their malicious compliance of the DMA.
Of course, there are numerous ways this could be addressed, such as not changing anything at all if the user chose Safari as their default browser anyway. But it seems quite clear Apple is willing to drag everyone down with them in their malicious compliance of the DMA.
I'm guessing they were only doing the little they did for PWAs to stave off anti-trust attention by being able to say "we're not gatekeepers. You can use the web," but now that the EU forced them allow alternative app stores, they don't want anybody using PWAs and they have no need for them anymore, so they're killing them.
Apple announced web apps on macOS as keynote feature last year where they have no anti-trust scrutiny. This theory has holes.
macOS seems like a very different beast than iOS. I don't think you can draw conclusions from that any more than you could conclude that on iOS you can sideload because Apple allows that on macOS.
I think this is going to be just a temporary issue. They ran out of time and had to comply ASAP, as the DMA is going to take effect in a few weeks.
The DMA didn't come by surprise, but I guess they tried to play all their cards to get around it, or even get it pushed last minute. Maybe they were close to achieving that and in the end it didn't work out.
Like mentioned in another post there might be some alternative solutions via third party app stores, but my knowledge doesn't go deep enough into the iOS API and what options third party browsers are going to have.
I could imagine a "PWA Shell" app that can host multiple PWAs inside. The only limitation I see for now is that there will be only one app icon and it can only show up once in the task switcher on the iPhone. For the iPad multi-windows apps are possible.
The DMA didn't come by surprise, but I guess they tried to play all their cards to get around it, or even get it pushed last minute. Maybe they were close to achieving that and in the end it didn't work out.
Like mentioned in another post there might be some alternative solutions via third party app stores, but my knowledge doesn't go deep enough into the iOS API and what options third party browsers are going to have.
I could imagine a "PWA Shell" app that can host multiple PWAs inside. The only limitation I see for now is that there will be only one app icon and it can only show up once in the task switcher on the iPhone. For the iPad multi-windows apps are possible.
That sucks. I use PWAs a lot for my own dev stuff. Let’s hope Apple roles back this change.
I think this is more an illustration of how Apple are intentionally trying to hobble web apps so they can continue to tax all transactions on the app store, than any kind of issue with web technology itself. If Apple implemented the necessary features and fixed the bugs, it could well be a strong alternative to a native app. But they make money from preventing that and are doing everything they can to prevent other browsers from implementing quality PWA support.
“There are no silent pushes, so we can only update the app icon badge with a displayed push. Ideally, if you clear your notifications elsewhere, we automatically remove the badge on your phone. This isn’t possible with PWAs via push.”
Damn, is Apple doing these slight annoyances on purpose to degrade the user experience?
Damn, is Apple doing these slight annoyances on purpose to degrade the user experience?
Does the Tin Man have a sheet-metal willy? Of course they are, it's typical Apple behavior to make it seem that anything non-apple is flawed in one way or another. It's to foster negative opinions towards PWAs so they can peddle iOS apps instead.
is Apple doing these slight annoyances on purpose to degrade the user experience?
It's to degrade the developer experience to force you to native apps and the app stores for distribution
It's to degrade the developer experience to force you to native apps and the app stores for distribution
[deleted]
Weird, I saw mdn says safari support silent property of notification constructor. Does the article specify how it didn't work? Like does nothing at at even specified. Work in browser but not pwa, and so on?
Yes. Obviously.
Maybe we should be pushing for fewer PWAs overall. I personally will not use any web-based app when I can use a native app (with a few exceptions). PWAs just add unnecessary bloat, and the current HTML/CSS/JS stack that the web uses was designed for delivering text documents, not apps, so that inherently limits the experience.
I’m 50/50 on this: if I care about something enough to install it rather than going to a website, I’ll take a half decent native app over a PWA any day, even without the gimping on Apple’s part. Truly native anyway; I have a strong dislike for stuff like Flutter both conceptually and in practice.
But I also consider Apple’s iron grip on the platform to be against the spirit of computing, and I think having a viable alternative is important. I think there is a segment of software that would benefit from a nice PWA, but where two native apps would not really be worth anyone’s time.
But I also consider Apple’s iron grip on the platform to be against the spirit of computing, and I think having a viable alternative is important. I think there is a segment of software that would benefit from a nice PWA, but where two native apps would not really be worth anyone’s time.
> But I also consider Apple’s iron grip on the platform to be against the spirit of computing
But the problem here is the App Store, right? Both native iOS apps and PWAs need access to the hardware, which is provided by Apple.
Really my understanding is that people push hard for PWAs either because they want to work around the App Store, or because they are web dev (and every dev tends to be imperialist with their favourite language, that's not only a web thing).
But the problem here is the App Store, right? Both native iOS apps and PWAs need access to the hardware, which is provided by Apple.
Really my understanding is that people push hard for PWAs either because they want to work around the App Store, or because they are web dev (and every dev tends to be imperialist with their favourite language, that's not only a web thing).
People just like the open web. PWAs are part of the open web.
It's not so fun when Apple decides to change the app store rules and now your app is banned forever.
There is no guarantee that your app won't disappear from the App Store tomorrow.
It's not so fun when Apple decides to change the app store rules and now your app is banned forever.
There is no guarantee that your app won't disappear from the App Store tomorrow.
> People just like the open web. PWAs are part of the open web.
"Open" is relative in this context: I can't just go merge any code I want into Chromium so that I can distribute my cool app with my very custom feature to all the Chromium users, can I?
Because some people like PWAs (and what they represent) does not mean that private companies should be forced to support them.
> There is no guarantee that your app won't disappear from the App Store tomorrow.
That is completely different debate, unrelated to PWAs, right?
"Open" is relative in this context: I can't just go merge any code I want into Chromium so that I can distribute my cool app with my very custom feature to all the Chromium users, can I?
Because some people like PWAs (and what they represent) does not mean that private companies should be forced to support them.
> There is no guarantee that your app won't disappear from the App Store tomorrow.
That is completely different debate, unrelated to PWAs, right?
I personally will not use any native app when I can use a web app
I personally will not use any web app when I can use a native app.
Let me tell you a secret: a LOT of native apps are built on web technologies. Those apps are just shells with some web views.
That's why I avoid Electron software when possible. I use nheko instead of Element for my Matrix client, avoid VSCode unless I really need it, and shun Discord when possible.
I'm not talking about Electron software, Electron doesn't exist on iOS or Android.
Android and iOS have integrated webview componentes that are much more lightweight and are used in a lot of "native apps". Very often you will never notice if you don't look at the source code.
Android and iOS have integrated webview componentes that are much more lightweight and are used in a lot of "native apps". Very often you will never notice if you don't look at the source code.
Im always refreshing my pwa because not all resources get loaded or some js fails to run.
Since iOS 17.4 for EU users
1. Apple will DELETE user's data without notice 2. Lot of apps will stop working and there will be no way to access them without update 3. Web Push will stop working; users expecting notifications will never get them 4. Apple breaks the Web platform
This was published in the document "Update on apps distributed in the European Union" https://developer.apple.com/support/dma-and-apps-in-the-eu/
1. Apple will DELETE user's data without notice 2. Lot of apps will stop working and there will be no way to access them without update 3. Web Push will stop working; users expecting notifications will never get them 4. Apple breaks the Web platform
This was published in the document "Update on apps distributed in the European Union" https://developer.apple.com/support/dma-and-apps-in-the-eu/
The solution is simple beyond belief. Stop supporting Apple devices.
Last time I looked into alternatives (it’s been a while) there was no manufacturer that provided updates to latest Android without any delays for longer than 2 years. And manufacturers constantly broke their promise to keep delivering updates as long as possible.
I usually buy 2 year old high end iPhones. So this is very relevant for me. Also from an ecological perspective, smartphones should last at least 5 years.
I usually buy 2 year old high end iPhones. So this is very relevant for me. Also from an ecological perspective, smartphones should last at least 5 years.
Smartphones are now required by the EU to provide updates for five years. Samsung even promises seven years now.
I guess only security updates are mandated. With an iPhone you always get the newest version of iOS and many/most new features, not just some patches.
No, besides security updates the regulation also covers corrective updates (i.e. bugfixes) and functionality updates for “the same OS”.
Personally I would actually prefer stability over having the system and UI changing every year, and getting slower every year on older hardware.
Personally I would actually prefer stability over having the system and UI changing every year, and getting slower every year on older hardware.
Google Pixels are now shipping 7 years of updates.
Lol. My Pixel is newer than that, and I haven't gotten a single update in 2.5 years.
They started this on a recent gen, maybe 7. Certainly 8.
It hasn't been 7 years yet for either the Pixel 7 or the 8, but I suppose Google never cancels things.
Exactly, there were a lot of similar promises like that before. And then the excuses started. Old phones got the promised updates months after the Android release. Sometimes even after already the next Android version was released.
Sure, but they'll open themselves up to lawsuits if they back out of this. Cancelling a saas product is one thing; cancelling "guaranteed updates" is another.
Can you see the problem? People have Android phones from big manufacturers and not getting updates. If this will change in the future that's great. But now people have phones that don't get updates.
Simple != feasible. Apple devices are where the majority of money is spent on mobile. People are not going to switch to Android if your software isn’t available on iOS, they’re going to move to a competitor that is.
Side note but, man, I hate it when write ups like this refer to events in relative terms without including a published date...
> Last month [...]
> At the same time [...]
> That was over 6 months ago [...]
From when?!? What good is a relative timeline of events and your "current" thinking without a timestamp?
Digging though the source, it looks like this is from a few days ago.. "created_at":"2024-02-14T01:45:45.254Z"
/rant
> Last month [...]
> At the same time [...]
> That was over 6 months ago [...]
From when?!? What good is a relative timeline of events and your "current" thinking without a timestamp?
Digging though the source, it looks like this is from a few days ago.. "created_at":"2024-02-14T01:45:45.254Z"
/rant
Apple has confirmed that PWAs will be just a browser bookmarks from now on.
Other browsers won't also have access to add (actual, not bookmark) PWAs. That is the main reason to not allow them.
If other browsers can add powerful PWAs then it competes with App Store.
Other browsers won't also have access to add (actual, not bookmark) PWAs. That is the main reason to not allow them.
If other browsers can add powerful PWAs then it competes with App Store.
> If other browsers can add powerful PWAs then it competes with App Store.
This is exactly it. If they can't have full control over how PWAs work, they prefer to cut the feature out of iOS.
This is exactly it. If they can't have full control over how PWAs work, they prefer to cut the feature out of iOS.
I expect PWA to remain noticeably limited relative to native, and probably with a noticeable gradient between Google and Apple. But I also expect PWA to steamroll all conventional app development nonetheless: PWA optionally bundled with some native components for filing the gaps, as in Tauri. Progressive will just grow another stage beyond manifest and serviceworker: manifest and serviceworker running in a customized variant of the browser installed through the app store.
> a customized variant of the browser installed through the app store
On iOS, apps can only run a single app instance. Which means that, if you want to run multiple PWAs in parallel, you’d need a separate browser app per PWA.
On iOS, apps can only run a single app instance. Which means that, if you want to run multiple PWAs in parallel, you’d need a separate browser app per PWA.
A separate app per PWA that is little more than a tiny shim for whatever API Apple refuses to provide in the browser (many of them for very good reasons) and a script for spinning up another instance of the system browser with the API shims available. That's the Tauri model: you wouldn't install tens of browsers, but tens of configurations for the browser that is already there.
It means that the PWAs wouldn’t appear as separate apps, but as tabs within the same browser app.
Also, unlike native PWAs, you couldn’t have per-PWA notification badges on the app icons (because there’s only one). A browser app could maybe emulate this by providing different widgets per PWA, but still it would be a less straightforward experience.
Also, unlike native PWAs, you couldn’t have per-PWA notification badges on the app icons (because there’s only one). A browser app could maybe emulate this by providing different widgets per PWA, but still it would be a less straightforward experience.
On iOS, native app are not allowed to ship their own html renderer implementation and therefore have to delegate to the renderer provided by the OS. If that happens, does the markup appear as a view in the app instance, or does the content appear as a tab in the browser? I assume that it's the former. iOS Firefox is famously not gecko but a Firefox-flavored safari and if that would cause markup to appear as tabs in regular safari, FF-iOS would be little more than a URL bar. Each "PWA+" would be its own "safari dressed up as a different app", just like Firefox-flavored safari is.
This was about "PWA+" installed from the app store, individually, just like you can install both FF-iOS and Chrome-iOS (and it's still hardly more than a parody of Microsoft's troubles with forcing internet explorer into win98). Conventional PWA that don't come packaged from the app store appear as tabs or as separate depending on whatever mood Apple had been in the last update cycle I guess.
This was about "PWA+" installed from the app store, individually, just like you can install both FF-iOS and Chrome-iOS (and it's still hardly more than a parody of Microsoft's troubles with forcing internet explorer into win98). Conventional PWA that don't come packaged from the app store appear as tabs or as separate depending on whatever mood Apple had been in the last update cycle I guess.
To be clear, you can ship your own renderer (I’ve done it for e.g Apple TV). You get fucked when you want your own complex engine with a JIT JS engine.
> PWA optionally bundled with some native components for filing the gaps, as in Tauri.
Isn't that essentially Capacitor?
https://capacitorjs.com
Isn't that essentially Capacitor?
https://capacitorjs.com
I guess? Just from looking at the way tauri and capacitor present themselves, capacitor might benefit a lot in dev experience from focus on android and iOS, whereas tauri's primary claim to fame is on the desktop, where it picks up the local descendant of KHTML across a wide range of operating systems.
Difference is you can write your native layer in Rust.
I'm sure Apple doesn't have a vested interest in making PWAs good, I am actually surprised they added webpush.
Despite my best efforts and I still have no idea what a Progressive Web App is and why I need to use one. Seems like it's just a website that fits a certain accessibility criteria. It also seems like a hassle to get working correctly offline based on what I have read.
You can think of it like a web app that's been coded to have extra features when "added to the homescreen".
When added, the app can work offline, doesn't have an address bar/back button/etc, gets the ability to access device sensors, can send push notifications, etc. A well-made PWA usually looks and feels just like a native app.
When added, the app can work offline, doesn't have an address bar/back button/etc, gets the ability to access device sensors, can send push notifications, etc. A well-made PWA usually looks and feels just like a native app.
What if I only want an app that works offline? Is there a reason to use a PWA? For example, I want to make a simple notes app that has no reason to need connectivity.
If you don't have a complete Apple development environment, PWA is the best shot you have getting that little offline note taking to run on an iPhone.
That's not what I'm asking about. Whether it's Apple, Android, or desktop, if I just want to make an offline app why would I use a PWA?
the argument isn't why use a PWA, it's why use a native app?
in most cases, a team wants their product to be easily installable, live on the home screen, and have access to all native APIs. right now, the best way to do that is a native app
the cost to that is going through the app store, meaning paying apple for the dev license, paying apple a percentage of sales, adhering to the app store rules, allowing extra time before release to get apple approval, difficulty updating because you need apple's approval and the user to update it, needing apple hardware, separate codebase/dev skills for android/ios, etc.
if you don't need those pros above, you could maybe get away with a PWA, and avoid all of that hassle. in most cases, you can't, but avoiding all of that stuff is the value prop for a pwa
in most cases, a team wants their product to be easily installable, live on the home screen, and have access to all native APIs. right now, the best way to do that is a native app
the cost to that is going through the app store, meaning paying apple for the dev license, paying apple a percentage of sales, adhering to the app store rules, allowing extra time before release to get apple approval, difficulty updating because you need apple's approval and the user to update it, needing apple hardware, separate codebase/dev skills for android/ios, etc.
if you don't need those pros above, you could maybe get away with a PWA, and avoid all of that hassle. in most cases, you can't, but avoiding all of that stuff is the value prop for a pwa
I don't care whether something is a native app or a PWA. If I can create something that works completely offline without a ton of hassle then that is the option I will go with. If it is easier to do that with a PWA then great! And the question is definitely "why use a PWA?" Native apps are the established norm and if you want to change that then the case needs to be made as to why.
If you want an app that works offline without a ton of hassle, then PWAs are the easiest way to write something that's multiplatform. As a bonus, updates to your app are totally under your control and distributed as quickly as you want them to be.
If you only want to target one platform, and if you are already completely set up for native development for that platform, then yes, there's nothing to gain from going PWA instead of native.
Other than the learning experience of course, which you might consider valuable unless know for sure that all your future projects will remain on that one single platform.
Other than the learning experience of course, which you might consider valuable unless know for sure that all your future projects will remain on that one single platform.
I understand the benefits of PWAs for developers. Can someone explain to me the benefits for users? From a UX perspective how is a PWA superior to a native app?
For users, one of the ways PWAs are superior to native apps is that the user gets to use an app at all. It's hard to maintain 2 or 3 different codebases of an app, which means it might not get built at all. As a user, I'd rather use a decent app that exists, than not get to use an app at all.
The benefit is my app exists.
I'm not buying a mac or paying for an apple developer license, sorry.
I'm not buying a mac or paying for an apple developer license, sorry.
No need to open App Store to download 100MB update every month.
That the app exists.
And what is the state of PWAs on Android? Is it any better?
Yes.
Google Chrome has support and documentation on Android: https://support.google.com/chrome/answer/9658361?hl=en&co=GE...
Mozilla has documentation about PWAs across many platforms, including Android: https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
Mozilla's docs are very clear in defining what makes a PWA special:
> One of the defining aspects of a PWA is that it can be promoted by the browser for installation on the device. Once installed, a PWA appears to users as a platform-specific app, a permanent feature of their device which they can launch directly from the operating system like any other app.
This is precisely what Apple is breaking for iPhone users in the EU.
Google Chrome has support and documentation on Android: https://support.google.com/chrome/answer/9658361?hl=en&co=GE...
Mozilla has documentation about PWAs across many platforms, including Android: https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
Mozilla's docs are very clear in defining what makes a PWA special:
> One of the defining aspects of a PWA is that it can be promoted by the browser for installation on the device. Once installed, a PWA appears to users as a platform-specific app, a permanent feature of their device which they can launch directly from the operating system like any other app.
This is precisely what Apple is breaking for iPhone users in the EU.
Mozilla's docs are also out of date. Safari on desktop can install PWAs.
It's night and day. For example:
- Installing a PWA from Firefox browser adds to home screen with Firefox engine
- beforeinstallprompt event https://developer.mozilla.org/en-US/docs/Web/API/Window/befo...
- Installing a PWA from Firefox browser adds to home screen with Firefox engine
- beforeinstallprompt event https://developer.mozilla.org/en-US/docs/Web/API/Window/befo...
It's much better, but most of our users are on iPhones. The one (yes, one) Android PWA user is really happy.
Probably the best part about PWAs on Android is that you install it more like an actual app. iOS still makes you "Add to Home Screen" which is very unintuitive.
Probably the best part about PWAs on Android is that you install it more like an actual app. iOS still makes you "Add to Home Screen" which is very unintuitive.
Significantly.
E.g. no multi-month broken light/dark mode.
E.g. no multi-month broken light/dark mode.
> That means that if you’re viewing a chat thread on your PWA and you get a new message, you can’t suppress the new-message push. This is incredibly annoying for users.
Am I confused, or can't you just have the client tell the server you are viewing the thread, and suppress the push at the server side? If everything is encrypted maybe it reveals a bit of extra metadata about what you are looking at at the time though.
They went with a 10 second delay or something, but just keeping track of the user's state could be easier (you might have connectivity gaps, requiring some keepalive logic too and then something like the delay to avoid spamming them with notifications they didn't need).
Am I confused, or can't you just have the client tell the server you are viewing the thread, and suppress the push at the server side? If everything is encrypted maybe it reveals a bit of extra metadata about what you are looking at at the time though.
They went with a 10 second delay or something, but just keeping track of the user's state could be easier (you might have connectivity gaps, requiring some keepalive logic too and then something like the delay to avoid spamming them with notifications they didn't need).
[deleted]
(Repeating a previous comment on another post)
Browsers should only display documents, not apps. That's what operating systems are for.
Just give native apps what made the web popular in the first place:
• Ability to instantly launch any app just by typing its "name"
• No need to download or install anything
• Ability to revisit any part of an app just by copy/pasting some text and sharing it with anyone.
That's what ultimately matters to end users.
Browsers should only display documents, not apps. That's what operating systems are for.
Just give native apps what made the web popular in the first place:
• Ability to instantly launch any app just by typing its "name"
• No need to download or install anything
• Ability to revisit any part of an app just by copy/pasting some text and sharing it with anyone.
That's what ultimately matters to end users.
For those of us who want to know,
From Wikipedia:
A progressive web application (PWA), or progressive web app, is a type of application software delivered through the web, built using common web technologies including HTML, CSS, JavaScript, and WebAssembly. It is intended to work on any platform with a standards-compliant browser, including desktop and mobile devices.
A progressive web application (PWA), or progressive web app, is a type of application software delivered through the web, built using common web technologies including HTML, CSS, JavaScript, and WebAssembly. It is intended to work on any platform with a standards-compliant browser, including desktop and mobile devices.
Anyone have experience with/opinions on Apache Cordova? [1]
It seems like it would solve most of the PWA issues. Although I vaguely recall reading that Apple is not too fond of apps that are basically just wrapped web views.
[1] https://cordova.apache.org/
It seems like it would solve most of the PWA issues. Although I vaguely recall reading that Apple is not too fond of apps that are basically just wrapped web views.
[1] https://cordova.apache.org/
Even tough my disdain for devs using Electron instead of developing native apps feels a like challenged with PWA's, I think that ultimately devs/users should have the option.
Apple just confirmed PWA functionality is being cut in the EU, because they would otherwise "favor Safari". This is so clearly bullshit malicious pettyness at the cost of their users to get back at EU regulators, I'd like to return my iPhone now, please. This is like being out with your friends while they're having the beginnings of a breakup.
"you must show the notification when you receive it", is it not possible to filter the notifications on the server before sending them down?
That's what they did. 10 second delay before sending out a "new message" notification to give it time to be marked as read.
You know it's not PWA or pure native app, right? There are many other options, including Capacitor which will let you use most of your web code but get native platform access.
As an iOS user, I'm glad.
As an iOS user you would also prefer only Apple accepted websites in browser?
seems like minor annoyances rather than the deal breaker the headline insinuates
A better title would've been, "PWAs aren't a replacement for native iOS apps right now"
The drawbacks in the article are good to know, but in my circles it's common knowledge that Apple is putting less than 0 effort into supporting them. Right now, they are absolutely not a drop-in replacement for a native app
But that says nothing about the future. In 10 years, why should we still be building separate apps per platform when we have an amazing and open web? The losers are the app stores, because it gets harder to take their cut. As PWAs get closer to feature parity, and once apple gives up their horrendous pushback, it will only make more and more sense to ditch the native app
The drawbacks in the article are good to know, but in my circles it's common knowledge that Apple is putting less than 0 effort into supporting them. Right now, they are absolutely not a drop-in replacement for a native app
But that says nothing about the future. In 10 years, why should we still be building separate apps per platform when we have an amazing and open web? The losers are the app stores, because it gets harder to take their cut. As PWAs get closer to feature parity, and once apple gives up their horrendous pushback, it will only make more and more sense to ditch the native app
They won't that's the point,why they do, even if we allow third party stores, apple will be still the defaut
But as a web dev community we need to stand firm and build PWAs regardless. If we treat pwas on iOS like we did Internet explorer (i.e. giving it special attention and hack solutions as opposed to just not developing for it) we will lose the fight.
I suggest you call out the issues with ios and put disclaimers on your app page saying what's not supported, or add taglines like "for the best experience, use <other broswer>".
Apple can afford the dev work to update Safari or work with the standards committee, but im sure with their new vr goggles they will take the proprietary route