4 ms·
> The fact that iOS safari supports SO many lifecycle features except BeforeInstallPrompt is just so frustrating. BeforeInstallPrompt is non-standard. They rem
by JimDabell 1y ago
> The fact that iOS safari supports SO many lifecycle features except BeforeInstallPrompt is just so frustrating.
BeforeInstallPrompt is non-standard. They removed it from the specification because Mozilla had no plans to support it and Apple wouldn’t commit either.
Here’s the discussion:
> There is also some disagreement on the a `BeforeInstallPrompt()` event (BIP). Despite BIP having been in the spec for a few years, neither Safari nor Firefox have opted to support it. As it stands, Mozilla does not plan to support BIP. We are unsure what WebKit's plans are - @hober maybe could let us know? If WebKit doesn't plan to support it, then we should probably remove it from the spec.
— https://lists.w3.org/Archives/Public/public-webapps-github/2019Sep/0256.html?utm_source=chatgpt.com https://lists.w3.org/Archives/Public/public-webapps-github/2...
So yet again, this is a case of Google wanting something, Google implementing it unilaterally, Google not being able to convince any other rendering engine to implement it, then the non-standard, Blink-only behaviour is being presented in situations like this as if Safari alone is failing to support a standard.
Web standards are not whatever Google wants. They are arrived at through consensus.
- kelthuzad 1y agoYou're absolutely right about BeforeInstallPrompt. It never achieved consensus, Mozilla declined to implement it, and this is exactly how standards should work. But here's the thing, this actually makes the broader argument stronger, not weaker. The issue isn't any one feature rejection, it's the pattern. Remember the iOS 17.4 thing from February 2024. Apple completely disabled PWAs in the EU, claiming alternative browser engines created insurmountable security problems that would require building "an entirely new integration architecture" that wasn't practical given DMA timelines. Then after two weeks of backlash they reversed it. If the technical barriers were real, how did they solve them in 14 days? That looks less like a technical limitation and more like testing how much they could get away with. Or push notifications, Safari on macOS got them in 2013. Safari on iOS got them in 2023. Same WebKit engine, same APNs infrastructure, 10 years apart. What's the technical explanation for that gap? And even after iOS finally got push notifications, they only work for PWAs installed to home screen, not in Safari itself. That's a restriction that doesn't exist anywhere else. Android Chrome has had this working in the browser since 2015. That's the genius of plausible deniability, every individual decision has some technical justification you can point to. BeforeInstallPrompt lacks consensus (true). Safari has limited resources (as has Chrome). Security is hard (definitely true). But the cumulative effect of all these decisions, year after year, is that PWAs on iOS are hobbled compared to native apps in ways that just happen to protect a $20B+ App Store business. Your fact-check on BeforeInstallPrompt actually demonstrates why the other patterns are harder to explain away. It shows Apple can legitimately decline features through proper standards processes, which makes the decade-long notification delay and the iOS 17.4 reversal look even more suspicious by comparison.
- JimDabell 1y ago> 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 agoYou'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?