I also wonder what's point of PWAs _only_ supported in WebKit.
It feels like they trying to keep playing cat and mouse.
It feels like they trying to keep playing cat and mouse.
The only reason Apple does not want PWA is because it threatens their App Store profit.
More information: https://open-web-advocacy.org/blog/apple-backs-off-killing-w...
They then realized that they could make much more money with locked-down proprietary apps that they could tax at will through their App Store. Since then Apple has blocked any meaningful evolution of web apps, to prevent them from competing with native apps.
The App Store was opened in 2008, and was a huge success in 2018 (https://www.apple.com/newsroom/2018/01/app-store-kicks-off-2...: “New Year’s Day Sets Record With $300 Million in Purchases”)
If “Since then Apple has blocked any meaningful evolution of web apps”, why did they add support for PWAs on iOS in 2018? (https://medium.com/awebdeveloper/progressive-web-apps-pwas-a...: “Safari is finally adding PWA features.”)
1) From a regulation standpoint, it's in Apple's interest for PWA's to exist; Apple has used the argument in court that PWA's are a viable alternative to it's App Store and therefore it does not have a monopoly on iOS "apps".
2) From a financial standpoint, it's in Apple's interest for the PWA experience to be sub-par.
And this is how we got here.
PWA’s were a brand new subsystem introduced in iOS 11 with substantial (yet not emough) ongoing investment since then.
The conspiracy theory still doesn’t answer “why have then been investing in PWA’s since iOS 11?”, if they wanted them dead they could have just removed them rather than doing incremental enhancements.
Employees take money and do what is required of them, and otherwise do what they think is awesome. Employees think PWAs are awesome so PWAs happen... until they threaten almighty App Store then it stops.
I don't see how a PWA-enabled Safari fits into this narrative.
Timeline:
0) Apple hires key people and invests 4 years in PWA support for Safari on iOS.
1) Apple releases support for PWAs in Safari for iOS worldwide.
2) The DMA compliance thing happens.
3) Apple allows alternative browser engines + disables PWAs in the EU.
4) Apple rolls back PWA disablement in the EU.
I mean, 0 and 1 are not some skunkwork. It hasn't been sneaked into the release. PWA support predates this DMA drama. It was disabled only in the EU.
PWAs challenging App Store revenue is completely orthogonal to them being Safari-exclusive or not. PWA support for iOS has been invested on, released, enabled, and has even more features coming up and prereleased in the tech preview. Nobody forced Apple to do that. That alone is solid material fact, blowing away hypothetical claims of evil intent.
Apple has been actively using the existence of PWA's as an argument in court that it's App Store does not have a monopoly on iOS app distribution. So, yes... It's likely Apple want's PWA's to exist on iOS.
It's also very likely (given their financial incentives) that they don't want them to be a very good experience.
...Like, seriously? I can fully understand disliking Apple, and disagreeing with their choices, but to claim that none of Apple's stated concerns—which are perfectly reasonable on their face, regardless of whether you consider their weight to be sufficient to justify the choice—are legitimate at all? That they are only concerned with profit?
We don't need to speculate, cross-browser PWA work fine on Android and are secure.
No, Apple's claims do not seem reasonable or valid here since there's an existing implementation contradicting them.
Regular sites in browser tabs can have SWs.
When the full Chrome(ium) or FF hits iOS (engine and all), they will want to run SW. And, if I understand the DMA correctly, Apple will be forced to make that possible for 3rd party browser engines.
For a long time they appeared to be in maintenance mode on iOS. They’re still years behind what Chrome allows PWAs to do.
I used this when I was taking a break from chrome, because Firefox cancelled their PWA support for Desktop.
And that’s not what most people consider a PWA.
Any app that's geared towards visitors or tourists is better served as a PWA - think of the apps used to pay for transit, or parking in a city you're visiting. A website is Ok, but offline access and a shortcut on the homescreen would be better.
To make this work with another browser. They would need to fix this, make a safe public api for it, and publish it in new ios version. (Which they think it's way too much work and rather want to get rid of it instead)
Edit: don't know why I am getting downvoted. A web page can do exaxt same thing as a PWA. Access camera,mic, files system, Bluetooth etc, send push notifications here's an example.
Sure, Webkit and mobile safari have supported things like service workers for years and years, but we just freaking got notifications and so it felt like they were yanking it back.
But to make push notifications happen, you need a central push server. How do you handle that with a third party browser engine? Where does the browser app request notification access? But then how is that delegated to a separate PWA if you have notifications turned off for the browser specifically? Currently, notifications run through Apple servers on iOS. With third party engine support, that opens a can of worms needed to proxy the requests into an iPhone.
Browsers are more code than most OS's they run on. Hell a browser IS its own operating system for all intents. One that can access the network and do all sorts of bad things on its own.
This matters for the phone. Its a device many people take with them everywhere, bathrooms, bedrooms etc.
Locking PWA's to web kit likely has some underlying security issues. If you dont think browsers aren't full of holes and permissions issues go look at the LAST compromise, Edge snarfing Chrome tabs.
All that said, there are a lot of places where PWA's still suck, because browsers suck.
If you squint a little, you'll notice that this sounds a little like the problem Craig Federighi cited with Xbox's cloud app. Namely that Apple doesn't want multiple apps wearing the same 'trenchcoat', so to speak. But they also don't want to actually implement the APIs necessary for an app to break itself apart in the UI and pretend to be multiple apps. So you can't have multiple icons on the home screen, or launch with different storage containers and permissions depending on what app was touched. You can't even have a dependency that gets shared across multiple apps, like what Microsoft wanted with the streaming and authentication code for Xcloud. Ship multiple copies.
Personally this still smells like malicious compliance. Apple does literally all of the things I just mentioned and has been doing them since iPhone OS 1.0. Any security issue caused by an app having two icons can be remedied by the exact same review process that Apple insists they need to be the kings of anyway.
[0] On Apple "device" OSes, each installed app has it's own sub-home directory inside the user's home directory (/var/mobile). This is called a container.
Originally the container had both the app install and it's data; but those were split around iOS 9 so that apps could write to shared containers. That's also why some apps don't actually show up on the Storage view in Settings, and instead there's a separate entry for the developer as a whole.
Containers don't exist on macOS. Mac App Store apps and iOS apps on macOS live in /Applications and write to your user home directory.
I don’t understand why people speculate weird conspiracies rather than doing a bit of research to see the actual issue. We can still pile on Apple for a bad design, lack of foresight, and unwillingness to totally rebuild the PWA architecture.