3 ms·

> The issue isn't any one feature rejection, it's the pattern. Yes, and this pattern keeps popping up: - Google wants something - Google writes a spec. - Go

> The issue isn't any one feature rejection, it's the pattern. Yes, and this pattern keeps popping up: - Google wants something - Google writes a spec. - Google implements it. - No other rendering engine wants it. - It starts popping up on sites like this. - People complain that it’s Apple’s fault for not implementing the standard. Google keeps doing this over and over again. This is embrace and extend all over again. Web standards are not whatever Google wants them to be. They need to be arrived at through consensus. Google gives Mozilla billions and billions of dollars and they still can’t get Mozilla to agree to these things. Google can’t get anybody outside of Google to implement these things. Stop ignoring the fact that Mozilla is also saying no to a tonne of stuff. Stop ignoring the fact that no other rendering engine wants these things. This is not “Apple is holding things back”. This is “Google is trying to unilaterally control web standards”.

kelthuzad 1y ago
You're making a fair point about Google and embrace-and-extend, but you didn't actually address the evidence I raised. Let me ask more directly. Again, the iOS 17.4 situation. Apple claimed building PWA support for alternative browser engines wasn't "practical to undertake" due to security architecture requirements. They removed the feature. Two weeks later they brought it back. I'm asking one more time, what changed in those 14 days? If the architecture work genuinely "created insurmountable security problems that would require building "an entirely new integration architecture" that wasn't practical given DMA timelines", how was it completed so quickly? Push notifications on iOS versus macOS. 2013 on Mac, 2023 on iPhone, same WebKit engine, same APNs backend. Apple controls the browser and the notification system on both platforms. Why the 10 year gap for what should be the same technical implementation? The thing is, whether or not Google tries to control standards doesn't explain these Apple-specific patterns that are clearly driven by Apple's conflict of interest. Mozilla declining BeforeInstallPrompt doesn't explain why features Apple already built for macOS took a decade to reach iOS. These are implementation decisions about Apple's own technology on Apple's own platforms. You can argue Google is problematic (I'd also agree on that!) and also admit that Apple's decisions around PWAs are clearly driven by their conflict of interest to protect their $20+ billion dollar App Store business model. Those aren't mutually exclusive. But you haven't explained the iOS 17.4 reversal or the notification delay at all. Could you address those specifically?
- JimDabell 1y ago
  > Again, the iOS 17.4 situation. Apple claimed building PWA support for alternative browser engines wasn't "practical to undertake" due to security architecture requirements. They removed the feature. Two weeks later they brought it back. I'm asking one more time, what changed in those 14 days? If the architecture work was genuinely impractical, how was it completed so quickly? The target changed. The EU rules implied that there was a requirement for parity between Safari and the other browsers. Implementing that parity by adding a tonne of new APIs for other browsers is understandably infeasible to achieve in a short timeframe. Can we agree on that? So the other option to achieve parity is by removing the functionality from Safari. Which is what they did – in a beta not a release version if I remember correctly. That got a big reaction, and the EU backed off. So Apple no longer had to achieve this parity in a short timeframe, so they could just keep the status quo. And I think we can agree that keeping the status quo is easy to implement, right? So what we’re really saying here is that adding a load of new APIs is hard, and not adding them is easy. In that light, Apple saying “hey this is hard” and then a few weeks later going “never mind” makes total sense. And since that time, they have been adding a load of new APIs for other browsers to achieve parity – just not on the super short timescale. > Push notifications on iOS versus macOS. 2013 on Mac, 2023 on iPhone, same WebKit engine, same APNs backend. Apple controls the browser and the notification system on both platforms. Why the 10 year gap for what should be the same technical implementation? I don’t believe Apple have ever claimed it was a technical limitation have they? If you ask real users – even here on Hacker News – a bunch of them will say they don’t want websites to send them notifications on their phone. The user demand isn’t as high as you think it is. > even after iOS finally got push notifications, they only work for PWAs installed to home screen, not in Safari itself. You will see this in a lot of Apple decisions around web standards. They see visiting a website and installing a PWA as expressions of different levels of trust and they are trying to avoid permission prompt fatigue. Do you want any random website to send you notifications? No. Do you want websites to constantly prompt you for permission? No. If they do that, will lots of users accidentally say yes? Yes. Are the answers to these questions different for something a user explicitly installs? Yes. If you read through the discussions on the web specification proposals, you’ll see this kind of thing come up several times, from Mozilla as well. > You can argue Google is problematic (I'd also agree on that!) and also admit that Apple's decisions around PWAs are clearly driven by their conflict of interest to protect their $20+ billion dollar App Store business model. I definitely think that Apple makes choices that deprioritise the web. But I also think that 90% of the things people here actually complain about are actually reasonable, and it’s only a small minority that are less justifiable. I also think it’s less a case of moustache-twirling “let’s hold the web back to boost native apps” and more “why should we?” End-users strongly prefer native to web. End-users are not asking for PWAs in meaningful numbers. At this point people often blame Apple for holding PWAs back, but this isn’t the case. Apple are not holding PWAs back on Android. Google implement all the APIs they feel like on Chrome for Android. PWAs on Android are not held back. PWAS on Android are a best-case scenario for PWAs. But end users still overwhelmingly choose native apps over PWAs on Android. If PWAs were preferred by users and artificially limited by Apple, then we would see end-users pick PWAs on Android. Developers wouldn’t build native apps on Android so much, they would just build PWA+iOS and skip the native Android implementation. They don’t do that. The causality is the opposite direction to what you think. Apple aren’t causing PWAs to fail; PWAs failing causes Apple to not care about them.
yujzgzc 1y ago
Should we really care what the rendering engines want? What about what users and app authors want? If Google was adding things that nobody cared about, it wouldn't be a problem. The problem is that these things are useful.
- JimDabell 1y ago
  > Should we really care what the rendering engines want? Yes. Let’s use Web MIDI as an example. This was proposed by Google, and implemented by Google. It was initially rejected by both Mozilla and Apple on privacy and security grounds. Mozilla eventually gave in and implemented it. Then it came to light that porn sites had been using Web MIDI to fingerprint and track users. https://news.ycombinator.com/item?id=23679063 https://news.ycombinator.com/item?id=23679063 I think Apple made the right call there. Just blindly saying yes to functionality is not good for the web.
  - yujzgzc 1y ago
    I sort of agree with Safari's call - a lot of Chrome's functionality is declined by Safari on reasons that it enables fingerprinting. For that reason I think the site is misleading in its rating of privacy. But I don't think Google's to blame for making a different choice about it. It's picking a different privacy / functionality trade-off, but it's doing it with open standards that others are free to implement if they want. It's putting some pressure on Apple because users often care more about functionality than about privacy, but not so much that they're worried about it, I think. They seem to be doing well!

kelthuzad 1y ago

You're making a fair point about Google and embrace-and-extend, but you didn't actually address the evidence I raised. Let me ask more directly. Again, the iOS 17.4 situation. Apple claimed building PWA support for alternative browser engines wasn't "practical to undertake" due to security architecture requirements. They removed the feature. Two weeks later they brought it back. I'm asking one more time, what changed in those 14 days? If the architecture work genuinely "created insurmountable security problems that would require building "an entirely new integration architecture" that wasn't practical given DMA timelines", how was it completed so quickly? Push notifications on iOS versus macOS. 2013 on Mac, 2023 on iPhone, same WebKit engine, same APNs backend. Apple controls the browser and the notification system on both platforms. Why the 10 year gap for what should be the same technical implementation? The thing is, whether or not Google tries to control standards doesn't explain these Apple-specific patterns that are clearly driven by Apple's conflict of interest. Mozilla declining BeforeInstallPrompt doesn't explain why features Apple already built for macOS took a decade to reach iOS. These are implementation decisions about Apple's own technology on Apple's own platforms. You can argue Google is problematic (I'd also agree on that!) and also admit that Apple's decisions around PWAs are clearly driven by their conflict of interest to protect their $20+ billion dollar App Store business model. Those aren't mutually exclusive. But you haven't explained the iOS 17.4 reversal or the notification delay at all. Could you address those specifically?

JimDabell 1y ago
> Again, the iOS 17.4 situation. Apple claimed building PWA support for alternative browser engines wasn't "practical to undertake" due to security architecture requirements. They removed the feature. Two weeks later they brought it back. I'm asking one more time, what changed in those 14 days? If the architecture work was genuinely impractical, how was it completed so quickly? The target changed. The EU rules implied that there was a requirement for parity between Safari and the other browsers. Implementing that parity by adding a tonne of new APIs for other browsers is understandably infeasible to achieve in a short timeframe. Can we agree on that? So the other option to achieve parity is by removing the functionality from Safari. Which is what they did – in a beta not a release version if I remember correctly. That got a big reaction, and the EU backed off. So Apple no longer had to achieve this parity in a short timeframe, so they could just keep the status quo. And I think we can agree that keeping the status quo is easy to implement, right? So what we’re really saying here is that adding a load of new APIs is hard, and not adding them is easy. In that light, Apple saying “hey this is hard” and then a few weeks later going “never mind” makes total sense. And since that time, they have been adding a load of new APIs for other browsers to achieve parity – just not on the super short timescale. > Push notifications on iOS versus macOS. 2013 on Mac, 2023 on iPhone, same WebKit engine, same APNs backend. Apple controls the browser and the notification system on both platforms. Why the 10 year gap for what should be the same technical implementation? I don’t believe Apple have ever claimed it was a technical limitation have they? If you ask real users – even here on Hacker News – a bunch of them will say they don’t want websites to send them notifications on their phone. The user demand isn’t as high as you think it is. > even after iOS finally got push notifications, they only work for PWAs installed to home screen, not in Safari itself. You will see this in a lot of Apple decisions around web standards. They see visiting a website and installing a PWA as expressions of different levels of trust and they are trying to avoid permission prompt fatigue. Do you want any random website to send you notifications? No. Do you want websites to constantly prompt you for permission? No. If they do that, will lots of users accidentally say yes? Yes. Are the answers to these questions different for something a user explicitly installs? Yes. If you read through the discussions on the web specification proposals, you’ll see this kind of thing come up several times, from Mozilla as well. > You can argue Google is problematic (I'd also agree on that!) and also admit that Apple's decisions around PWAs are clearly driven by their conflict of interest to protect their $20+ billion dollar App Store business model. I definitely think that Apple makes choices that deprioritise the web. But I also think that 90% of the things people here actually complain about are actually reasonable, and it’s only a small minority that are less justifiable. I also think it’s less a case of moustache-twirling “let’s hold the web back to boost native apps” and more “why should we?” End-users strongly prefer native to web. End-users are not asking for PWAs in meaningful numbers. At this point people often blame Apple for holding PWAs back, but this isn’t the case. Apple are not holding PWAs back on Android. Google implement all the APIs they feel like on Chrome for Android. PWAs on Android are not held back. PWAS on Android are a best-case scenario for PWAs. But end users still overwhelmingly choose native apps over PWAs on Android. If PWAs were preferred by users and artificially limited by Apple, then we would see end-users pick PWAs on Android. Developers wouldn’t build native apps on Android so much, they would just build PWA+iOS and skip the native Android implementation. They don’t do that. The causality is the opposite direction to what you think. Apple aren’t causing PWAs to fail; PWAs failing causes Apple to not care about them.

yujzgzc 1y ago

Should we really care what the rendering engines want? What about what users and app authors want? If Google was adding things that nobody cared about, it wouldn't be a problem. The problem is that these things are useful.

JimDabell 1y ago
> Should we really care what the rendering engines want? Yes. Let’s use Web MIDI as an example. This was proposed by Google, and implemented by Google. It was initially rejected by both Mozilla and Apple on privacy and security grounds. Mozilla eventually gave in and implemented it. Then it came to light that porn sites had been using Web MIDI to fingerprint and track users. https://news.ycombinator.com/item?id=23679063 https://news.ycombinator.com/item?id=23679063 I think Apple made the right call there. Just blindly saying yes to functionality is not good for the web.
- yujzgzc 1y ago
  I sort of agree with Safari's call - a lot of Chrome's functionality is declined by Safari on reasons that it enables fingerprinting. For that reason I think the site is misleading in its rating of privacy. But I don't think Google's to blame for making a different choice about it. It's picking a different privacy / functionality trade-off, but it's doing it with open standards that others are free to implement if they want. It's putting some pressure on Apple because users often care more about functionality than about privacy, but not so much that they're worried about it, I think. They seem to be doing well!