PWAs wont replace native iOS apps(app.campsite.co) |
PWAs wont replace native iOS apps(app.campsite.co) |
They do not allow Chrome to build too powerful apps outside of App Store.
Yes, I'm happy with that. But if at any point I become unhappy, I'll buy a different phone.
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
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
We should just have the story that we are making better and better web apps and Apple isn't keeping up with others.
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 ;)
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.
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.
It is not fundamentally wrong to do custom stuff. I prefer native apps as well but this sound bite needs to go away.
In this case you’d need “use <other operating system>”. There’s no alternatives to Safari for PWAs on iOS.
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.
> "for the best experience, use <other browser>"
You just lost a customer.
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).
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.
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.
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-...
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.
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
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 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.
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.
> 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...
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.
Damn, 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
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 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).
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/
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.
> 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
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.
This is exactly it. If they can't have full control over how PWAs work, they prefer to cut the feature out of iOS.
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.
Isn't that essentially Capacitor?
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.
I'm not buying a mac or paying for an apple developer license, sorry.
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.
- 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...
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.
E.g. no multi-month broken light/dark mode.
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).
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.
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.
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.
https://www.macrumors.com/2024/02/08/ios-17-4-nerfs-web-apps...
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).
So fuck me I guess :(
https://9to5mac.com/2024/02/15/ios-17-4-web-apps-european-un...
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
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?
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.
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".
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.
If PWAs are limited competitively on the platform with the highest ROI for developers … that's a problem.
That's the perfect usecase for like... a website.
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.
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).
To add to your statistics: I am an Android user, and I mostly hate PWAs. I want native apps.
Still I don't think it's a reason to completely give up on the good ways.
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
"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).
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.
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.
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…
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.
Personally I would actually prefer stability over having the system and UI changing every year, and getting slower every year on older hardware.
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.
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.
> 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.
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.
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.
> The thing is, "more" is not always "better".
In the free market, competition is king. "Better" is decided by pitting it against "more".
> 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.
Brb gotta go get a whole new computer
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
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.
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.
This has yet to be made clear to me.
Could you attempt to convince us?
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?
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.
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.
"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 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.
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.
Thanks
In that regard, webapps work perfectly.
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.
Some things are important enough for a bookmark, others are important enough for home screen.
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?
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.
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.
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"
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.
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 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.
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.
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.
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.
or just the features they're motivated not to offer a path to using for other publishers?
(Like, webapp support)
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.
and a dozen other similar questions...
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.
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?
Cannot say the same about iOS emulators.
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.
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").
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.
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.
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.
https://python.plainenglish.io/python-for-ios-the-ultimate-g...
Yes?
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.
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".
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 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.
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 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.
It is not and it seems like the developer focused its resources on native software for Apple products.
The lack of native apps is the App Store reviews process fault.
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.
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.
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.
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.
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.
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 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.
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.
Because it is not in the act nor have there been any public statements about it.
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.
Again. There isn't a single court or government that has said this is not permitted.
Including the EU.
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?
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-...
> 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.
It's literally elementary stuff.
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.
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?)
https://s-hens.github.io/ios-webkit-quirks/
Feels mildly off-topic anyway.
Apple has every right to self-determination, but sometimes that means deciding whether they agree with the law.
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.
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.
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.
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.