13 ms·

I think it's bizarre to conflate Apple's refusal to allow other webkits on iOS with the fact that Safari remains a viable alternative engine. They're far from h

I think it's bizarre to conflate Apple's refusal to allow other webkits on iOS with the fact that Safari remains a viable alternative engine. They're far from heroes here. I think it's great they maintain a Chrome alternative kit that mostly works but let's not pretend they're saints or kid ourselves about the reasons for it. The only reason they disallow Chromium and Mozilla is they want their users locked into their environment and they want to leverage that substantial locked-in user base to dictate terms. It's only being one of the richest companies in history that gives them a seat at the table. If they're afraid of having to open the platform, that's because they're not keeping up. It's not that they're one judgment away from that day. They know that. It's just that they want to get as much mileage as they can before they too abandon Safari and first allow, then switch to Chromium. That will happen in the next 5 years. What might come of it all would be a reset where new branches form and new innovators get to introduce new proposals. Standards aren't a bad thing if they're open. If Safari dies then Google will be next in the line of fire for antitrust action anyway... things will fragment again. I'm personally pissed at the number of great technologies left as litter along the road, not least AS3, just to get to this shitty middle ground / cold browser war between two companies I hope die and one that won't help itself. Let the standards win and let's have a standard platform to innovate on top of.

leononame 4y ago
> It's not that they're one judgment away from that day. They know that. It's just that they want to get as much mileage as they can before they too abandon Safari and first allow, then switch to Chromium. That will happen in the next 5 years. I'm not a great future-reader myself, but I don't see this happening soon. The web is a great threat to their app (and also subscription) revenue stream, and they have a lot to lose with little to win for their platform. They lag behind because they want to, not because they can't.
- threeseed 4y ago
  > The web is a great threat to their app (and also subscription) revenue stream This is as ridiculous today as it has been every year since the iPhone began. Mobile web apps are terrible and despite all the years of promises that "feature X" will fix this nothing has changed. And you can't blame Apple because Google et al could easily have made mobile web apps work on Android. If you want to make a mobile web app then go right ahead. Apple isn't stopping you. But just don't be surprised when no user is interested in it.
  - encryptluks2 4y ago
    You do realize web apps can be packaged up and distributed on the Play Store and work just like regular apps on Android, and so YouTube Music among others are already web apps. Pretending like no one is interested when we're talking about probably close to 100 million users or more for a single web app is disingenuous. Apple is a walled garden and their cultist will make up any excuse to not have to admit so.
    - threeseed 4y ago
      Web apps can be packaged up and distributed on App Store as well. People tried it with PhoneGap for years and it failed. I even built some of them. It has nothing to do with Apple and everything to do with the experience being objectively terrible. So bad in fact that even Google gave up trying and built Flutter.
      - encryptluks2 4y ago
        https://blog.pwabuilder.com/posts/publish-your-pwa-to-the-ios-app-store/ https://blog.pwabuilder.com/posts/publish-your-pwa-to-the-io... > While WebKit is making progress on PWA support, at the time of this writing, PWAs remain a second-class citizen on iOS. The iOS App Store’s support for PWAs is non-existent, requiring a web view-based solution like PWABuilder’s. > Additionally, because iOS doesn’t allow 3rd party browser engines, your PWA is limited to WebKit’s PWA capabilities, which are currently lagging behind other browser engines. Google isn't abandoning PWAs, and in fact Chromium continues expanding support to make them as native as possible: https://web.dev/window-controls-overlay/ https://web.dev/window-controls-overlay/ Might I also add that the web app manifest is also an open standard, that Safari is lacking on: https://developer.mozilla.org/en-US/docs/Web/Manifest https://developer.mozilla.org/en-US/docs/Web/Manifest https://w3c.github.io/manifest/ https://w3c.github.io/manifest/
        threeseed 4y ago
        I can take a mobile web site, wrap it in a browser component and publish it to the App Store. Now I will lose one of the advantages of PWA e.g. remote updates but everything else I can do e.g. push notifications, access device APIs. This has been available for close to a decade. Guess what. Users hate it. They hate mobile web apps and their slow, clunky, feature-poor, non-native interfaces and for that reason they will also hate PWAs.
pilif 4y ago
> The only reason they disallow Chromium and Mozilla is they want their users locked into their environment and they want to leverage that substantial locked-in user base to dictate terms That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one. They also want to make sure that if they fix the next security flaw what will undoubtedly be reported in WebKit, that all the apps with an embedded browser will get the fix and won't continue to be vulnerable due to them not updating whatever version of Chromium they were embedding. Of course, between sandboxing and not allowing JIT compilation, those vulnerabilities couldn't do do much harm, but that embedded Chromium also wouldn't be much fun to use. Which means, if you let me make a prediction of the future, that when Apple is forced into allowing other browser engines, articles will be written about how Apple is complying by the letter of the law but not the spirit by "seriously hampering 3rd party engines" compared to their own by now allowing JIT compilation. If they had to then also allow those 3rd party engines to do JIT compilation and bypass the sandbox in means that browser engines need to, then we'll be in a much worse position security wise. We'll see how this is going to play out, but I'm pretty sure exerting control is not the only reason for Apples' stance.
- paol 4y ago
  > That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one. Yes, because Chrome and Firefox have such a terrible track record with security /sarcasm Lets face it, that's a conveniently plausible excuse, not an actual reason.
  - Klonoar 4y ago
    You’re completely cutting off the other half of their post which makes sense with the context you’re quoting.
- pmoriarty 4y ago
  "Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one." If they really cared about security then they could subject their browser to an independent security audit, and require the same audit be passed for any other browser that's allowed on their platform. Why don't they do this?
bfgoodrich 4y ago
replygirl 4y ago
> If they're afraid of having to open the platform, that's because they're not keeping up. webkit is a bit behind in some areas like APIs but ahead in others like CSS

leononame 4y ago

> It's not that they're one judgment away from that day. They know that. It's just that they want to get as much mileage as they can before they too abandon Safari and first allow, then switch to Chromium. That will happen in the next 5 years. I'm not a great future-reader myself, but I don't see this happening soon. The web is a great threat to their app (and also subscription) revenue stream, and they have a lot to lose with little to win for their platform. They lag behind because they want to, not because they can't.

threeseed 4y ago
> The web is a great threat to their app (and also subscription) revenue stream This is as ridiculous today as it has been every year since the iPhone began. Mobile web apps are terrible and despite all the years of promises that "feature X" will fix this nothing has changed. And you can't blame Apple because Google et al could easily have made mobile web apps work on Android. If you want to make a mobile web app then go right ahead. Apple isn't stopping you. But just don't be surprised when no user is interested in it.
- encryptluks2 4y ago
  You do realize web apps can be packaged up and distributed on the Play Store and work just like regular apps on Android, and so YouTube Music among others are already web apps. Pretending like no one is interested when we're talking about probably close to 100 million users or more for a single web app is disingenuous. Apple is a walled garden and their cultist will make up any excuse to not have to admit so.
  - threeseed 4y ago
    Web apps can be packaged up and distributed on App Store as well. People tried it with PhoneGap for years and it failed. I even built some of them. It has nothing to do with Apple and everything to do with the experience being objectively terrible. So bad in fact that even Google gave up trying and built Flutter.
    - encryptluks2 4y ago
      https://blog.pwabuilder.com/posts/publish-your-pwa-to-the-ios-app-store/ https://blog.pwabuilder.com/posts/publish-your-pwa-to-the-io... > While WebKit is making progress on PWA support, at the time of this writing, PWAs remain a second-class citizen on iOS. The iOS App Store’s support for PWAs is non-existent, requiring a web view-based solution like PWABuilder’s. > Additionally, because iOS doesn’t allow 3rd party browser engines, your PWA is limited to WebKit’s PWA capabilities, which are currently lagging behind other browser engines. Google isn't abandoning PWAs, and in fact Chromium continues expanding support to make them as native as possible: https://web.dev/window-controls-overlay/ https://web.dev/window-controls-overlay/ Might I also add that the web app manifest is also an open standard, that Safari is lacking on: https://developer.mozilla.org/en-US/docs/Web/Manifest https://developer.mozilla.org/en-US/docs/Web/Manifest https://w3c.github.io/manifest/ https://w3c.github.io/manifest/
      - threeseed 4y ago
        I can take a mobile web site, wrap it in a browser component and publish it to the App Store. Now I will lose one of the advantages of PWA e.g. remote updates but everything else I can do e.g. push notifications, access device APIs. This has been available for close to a decade. Guess what. Users hate it. They hate mobile web apps and their slow, clunky, feature-poor, non-native interfaces and for that reason they will also hate PWAs.

pilif 4y ago

> The only reason they disallow Chromium and Mozilla is they want their users locked into their environment and they want to leverage that substantial locked-in user base to dictate terms That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one. They also want to make sure that if they fix the next security flaw what will undoubtedly be reported in WebKit, that all the apps with an embedded browser will get the fix and won't continue to be vulnerable due to them not updating whatever version of Chromium they were embedding. Of course, between sandboxing and not allowing JIT compilation, those vulnerabilities couldn't do do much harm, but that embedded Chromium also wouldn't be much fun to use. Which means, if you let me make a prediction of the future, that when Apple is forced into allowing other browser engines, articles will be written about how Apple is complying by the letter of the law but not the spirit by "seriously hampering 3rd party engines" compared to their own by now allowing JIT compilation. If they had to then also allow those 3rd party engines to do JIT compilation and bypass the sandbox in means that browser engines need to, then we'll be in a much worse position security wise. We'll see how this is going to play out, but I'm pretty sure exerting control is not the only reason for Apples' stance.

paol 4y ago
> That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one. Yes, because Chrome and Firefox have such a terrible track record with security /sarcasm Lets face it, that's a conveniently plausible excuse, not an actual reason.
- Klonoar 4y ago
  You’re completely cutting off the other half of their post which makes sense with the context you’re quoting.
pmoriarty 4y ago
"Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one." If they really cared about security then they could subject their browser to an independent security audit, and require the same audit be passed for any other browser that's allowed on their platform. Why don't they do this?

bfgoodrich 4y ago

replygirl 4y ago

> If they're afraid of having to open the platform, that's because they're not keeping up. webkit is a bit behind in some areas like APIs but ahead in others like CSS