10 ms·

If you look at the features that Apple lags on adding support for, usually it's either because: 1. they can be abused (PWAs) 2. are complex to implement (WebR

If you look at the features that Apple lags on adding support for, usually it's either because: 1. they can be abused (PWAs) 2. are complex to implement (WebRTC – for the longest time the recommendation in the WebRTC community if you wanted to build a C++ app was to bundle a good chunk of Chrome's libraries) 3. or could be bad for battery (web workers) So yeah, it makes some developers' jobs harder but generally there's a good reason for punting features.

amiga-workbench 5y ago
Okay, sure. But can I please have input type="number" and have the css gap property work with flex like it does in every other browser?
slivanes 5y ago
Actually, pretty sure it's only one reason, money. If they made Safari on iOS actually good (re: PWA notification support), it would burn into their App store profits.
- foxes 5y ago
  It can be both. Caring about the user experience is obviously going to increase their profit. But then they can also try to push people towards their store.
- diebeforei485 5y ago
  What sort of apps are in the intersection of being performant enough to be written in JavaScript and also generate lots of in-app purchase revenue (which is typically recurring revenue)? Certainly not most games, which are the biggest money-spinners, and also not pro camera apps or video editing apps. Video streaming apps (eg. Netflix / YouTube Premium) come to mind, but they don't rely too much on in app purchase I think. That leaves news apps like the New York Times which need notifications to deliver breaking stories, and perhaps dating apps with messaging/photo features. Thing is, for every New York Times, there are tons of "news" clickbait content farm websites out there, and I certainly don't need to elaborate on the risks of "free-for-all" dating apps with no enforced guidelines. I'd much rather Apple end the anti-steering rules where apps are not being allowed to tell people that they can subscribe on the website. Congress is working on this[1]. 1. https://stratechery.com/2021/the-cicilline-salvo/ https://stratechery.com/2021/the-cicilline-salvo/
  - nmfisher 5y ago
    > What sort of apps are in the intersection of being performant enough to be written in JavaScript and also generate lots of in-app purchase revenue (which is typically recurring revenue)? Or maybe it's just selection bias - we don't see these types of apps because the experience is so fundamentally broken, noone ever bothers to develop them.
    - diebeforei485 5y ago
      We'd see at least one of them on the App Store, then. 30% revenue share is a lot (and I hope Congress bans the anti-steering provisions and apps can link you to their website to pay), but it doesn't kill entire categories of apps.
      - remus 5y ago
        > 30% revenue share is a lot...but it doesn't kill entire categories of apps. Personally Im not so optimistic. 30% is a huge chunk of revenue and is completely unworkable for anything that doesn't have a huge margin built-in.
  - jeroenhd 5y ago
    I use a Home Assistant PWA that I'm quite happy with. No need to install native code that has access to everything on my device when I can interface with it from a browser sandbox. I also regularly use a local weather app that has an app version, stuffed with tracking, and a PWA version that gets protected against by my browsers privacy settings. There is also a very interesting project for programming certain ESP32 boards using WebSerial for easy to use home automation. You import some yaml and flash an ESP32 board without ever even installing the Arduino SDK. I think the problem is they we've reversed the question here. Why on earth should it even be acceptable that websites need an app for something as basic as watching videos, reading the news or checking the weather. Youtube and Netflix have no need for a native application if the developers actually cared about performance of their website. Especially Netflix should just work, because their web app also needs to work on ancient smart TVs and therefore has strict performance requirements. Dating apps where the most engaging thing you do is swipe in a direction and type into a basic chat screen also have no need for native code. There's a good reason Tinder works just fine as a PWA on every platform other than iOS. Those "free for all" dating apps do exist and have always existed. If they're illegal or immoral it's not up to Apple to pass judgement, that's what the legal system is for. I, for one, do not accept the tech overlords as my government.
- Synaesthesia 5y ago
  Safari is still the best mobile web browser in terms of performance and usability, and I'm using Firefox on Android, it's great, but Safari is the fastest.
  - paxys 5y ago
    Considering there are no other browsers on iOS to compare to, Safari is obviously the fastest by default.
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
    - Jcowell 5y ago
      The OP is comparing to android browsers as well though.
afavour 5y ago
In what way can PWAs be abused?
- vorador 5y ago
  Sorry, I'm using the OPs parlance here – by PWA I think he means "JS apps that use advanced browser APIs". The typical concern is that a phisher will use to make a page that looks like Google's sign-in page and display it in fullscreen mode. This would let them collect credentials while mirroring the input in a real form that'd be filled in the background.
  - upbeat_general 5y ago
    How is that related to the APIs being talked about? What advanced browser APIs does phishing in full screen require? The new iOS 15 safari is full screen (and you’ve always been able to add to home screen to make a website really fullscreen)…
- fmajid 5y ago
  The Web Workers API allows your JS code to keep running in the background even when your site is not loaded in any tab. Sucking up battery life, tracking your IP, doing who knows what else. That does not excuse Apple’s cavalier attitude towards bugs, but many of the APIs they refuse to implement deserve to die, like WebUSB or Bluetooth access, because of the privacy or security risks of weakening the browser sandbox. Has Google not learnt from the ActiveX fiasco?
  - jeroenhd 5y ago
    WebUSB and Web Bluetooth are actually very useful in very specific circumstances. I've seen several internal projects use it to communicate with obscure proprietary hardware that would otherwise require my company (mostly a web dev shop) to rewrite or extend the code with a native component only a few people could maintain reliably. For most people this stuff is unnecessary, which is why there's permission prompts to these APIs, bbut for certain use cases they're very convenient. Google made a tool that allows flashing firmware onto their Pixel devices directly from websites instead of requiring admin permissions to install some kind of one-off binary tool, for example. Then there's the ESPHome flasher which is very convenient. ActiveX allowed for breaking out of the web sandbox and running native code, these new APIs don't. They allow more direct communication with devices, but only with permissions and even then with limitations. If I want a website to communicate with a device, I'd prefer it if they'd stick to the web sandbox instead of requiring a native tool. These APIs help prevent an ActiveX world where everything needs an app that runs native code, with all security implications that comes with, and help people stick to the web sandbox. Perhaps that's why Apple refuses to implement certain APIs, they make billions from the ActiveX world that has come out of the app store.
lifthrasiir 5y ago
Safari is not only notorious for unimplemented features but also for unique (and often critical) bugs in spite of the shared origin with Chrome.
- ArchOversight 5y ago
  "shared origin with Chrome" You mean Chrome was a fork from Webkit when Google decided they could no longer play nice with Apple...
  - soperj 5y ago
    You're saying it like Webkit wasn't also a fork.
    - ArchOversight 5y ago
      That's not at all what I was saying. WebKit was a fork of KHTML, but implying that Safari has shared origin with Chrome was a little farfetched.
      - pankajdoharey 5y ago
        Webkit is far off from KHTML, just a simple code statistics will show you the number of hours by Apple Engineers on Webkit, at this point Webkit is a complete rewrite and has zero semblance with KHTML. Apple Engineers have more contributions in the repo than Google Engineers ever did. At the End Google strategy to build plugins and track users doesnt gel with the WebKit Strategy. For everyday use Safari is very energy Efficient compared to Chrome which is a Battery Hog.
jansan 5y ago
I work a lot with SVGs and from my perspective it looks like Apple just doesn't care. I have even given up sending bug reports to them, because they never get fixed.
Orphis 5y ago
Chrome engineer, working on WebRTC here. Here's my personal opinion: Safari's WebRTC implementation is not outdated, it's just bindings over the same library that is used and developed by Chrome. At worst, it's lagging a bit by a few months. What the post highlights is how some features are not available, like some codecs on some platforms. That's unlikely to be a decision from the browser engineers but probably closer to the lawyers who need time to approve a codec or other engineers working on HW acceleration. Another point is also that while WebRTC was available in most contexts, getUserMedia wasn't, and that's the API used to access cameras and microphones. Without it, WebRTC functionality loses its appeal. I believe that's now fixed and webviews can now use it. While I don't necessarily approve of those decisions for the users' sake, I still respect their choice to be able to make decisions on their own product and chose when a feature is deemed safe for release in potentially dangerous contexts. I don't know their security model, but from talking with the engineers on many occasions, they are not unreasonable people. And while Safari is lacking some new WebRTC related APIs released in Chrome, it would be fair to say that they are not all standardized yet at the IETF or W3C level. Other browsers don't necessarily implement them either, and that's fine.

amiga-workbench 5y ago

Okay, sure. But can I please have input type="number" and have the css gap property work with flex like it does in every other browser?

slivanes 5y ago

Actually, pretty sure it's only one reason, money. If they made Safari on iOS actually good (re: PWA notification support), it would burn into their App store profits.

foxes 5y ago
It can be both. Caring about the user experience is obviously going to increase their profit. But then they can also try to push people towards their store.
diebeforei485 5y ago
What sort of apps are in the intersection of being performant enough to be written in JavaScript and also generate lots of in-app purchase revenue (which is typically recurring revenue)? Certainly not most games, which are the biggest money-spinners, and also not pro camera apps or video editing apps. Video streaming apps (eg. Netflix / YouTube Premium) come to mind, but they don't rely too much on in app purchase I think. That leaves news apps like the New York Times which need notifications to deliver breaking stories, and perhaps dating apps with messaging/photo features. Thing is, for every New York Times, there are tons of "news" clickbait content farm websites out there, and I certainly don't need to elaborate on the risks of "free-for-all" dating apps with no enforced guidelines. I'd much rather Apple end the anti-steering rules where apps are not being allowed to tell people that they can subscribe on the website. Congress is working on this[1]. 1. https://stratechery.com/2021/the-cicilline-salvo/ https://stratechery.com/2021/the-cicilline-salvo/
- nmfisher 5y ago
  > What sort of apps are in the intersection of being performant enough to be written in JavaScript and also generate lots of in-app purchase revenue (which is typically recurring revenue)? Or maybe it's just selection bias - we don't see these types of apps because the experience is so fundamentally broken, noone ever bothers to develop them.
  - diebeforei485 5y ago
    We'd see at least one of them on the App Store, then. 30% revenue share is a lot (and I hope Congress bans the anti-steering provisions and apps can link you to their website to pay), but it doesn't kill entire categories of apps.
    - remus 5y ago
      > 30% revenue share is a lot...but it doesn't kill entire categories of apps. Personally Im not so optimistic. 30% is a huge chunk of revenue and is completely unworkable for anything that doesn't have a huge margin built-in.
- jeroenhd 5y ago
  I use a Home Assistant PWA that I'm quite happy with. No need to install native code that has access to everything on my device when I can interface with it from a browser sandbox. I also regularly use a local weather app that has an app version, stuffed with tracking, and a PWA version that gets protected against by my browsers privacy settings. There is also a very interesting project for programming certain ESP32 boards using WebSerial for easy to use home automation. You import some yaml and flash an ESP32 board without ever even installing the Arduino SDK. I think the problem is they we've reversed the question here. Why on earth should it even be acceptable that websites need an app for something as basic as watching videos, reading the news or checking the weather. Youtube and Netflix have no need for a native application if the developers actually cared about performance of their website. Especially Netflix should just work, because their web app also needs to work on ancient smart TVs and therefore has strict performance requirements. Dating apps where the most engaging thing you do is swipe in a direction and type into a basic chat screen also have no need for native code. There's a good reason Tinder works just fine as a PWA on every platform other than iOS. Those "free for all" dating apps do exist and have always existed. If they're illegal or immoral it's not up to Apple to pass judgement, that's what the legal system is for. I, for one, do not accept the tech overlords as my government.
Synaesthesia 5y ago
Safari is still the best mobile web browser in terms of performance and usability, and I'm using Firefox on Android, it's great, but Safari is the fastest.
- paxys 5y ago
  Considering there are no other browsers on iOS to compare to, Safari is obviously the fastest by default.
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - Jcowell 5y ago
    The OP is comparing to android browsers as well though.

afavour 5y ago

In what way can PWAs be abused?

vorador 5y ago
Sorry, I'm using the OPs parlance here – by PWA I think he means "JS apps that use advanced browser APIs". The typical concern is that a phisher will use to make a page that looks like Google's sign-in page and display it in fullscreen mode. This would let them collect credentials while mirroring the input in a real form that'd be filled in the background.
- upbeat_general 5y ago
  How is that related to the APIs being talked about? What advanced browser APIs does phishing in full screen require? The new iOS 15 safari is full screen (and you’ve always been able to add to home screen to make a website really fullscreen)…
fmajid 5y ago
The Web Workers API allows your JS code to keep running in the background even when your site is not loaded in any tab. Sucking up battery life, tracking your IP, doing who knows what else. That does not excuse Apple’s cavalier attitude towards bugs, but many of the APIs they refuse to implement deserve to die, like WebUSB or Bluetooth access, because of the privacy or security risks of weakening the browser sandbox. Has Google not learnt from the ActiveX fiasco?
- jeroenhd 5y ago
  WebUSB and Web Bluetooth are actually very useful in very specific circumstances. I've seen several internal projects use it to communicate with obscure proprietary hardware that would otherwise require my company (mostly a web dev shop) to rewrite or extend the code with a native component only a few people could maintain reliably. For most people this stuff is unnecessary, which is why there's permission prompts to these APIs, bbut for certain use cases they're very convenient. Google made a tool that allows flashing firmware onto their Pixel devices directly from websites instead of requiring admin permissions to install some kind of one-off binary tool, for example. Then there's the ESPHome flasher which is very convenient. ActiveX allowed for breaking out of the web sandbox and running native code, these new APIs don't. They allow more direct communication with devices, but only with permissions and even then with limitations. If I want a website to communicate with a device, I'd prefer it if they'd stick to the web sandbox instead of requiring a native tool. These APIs help prevent an ActiveX world where everything needs an app that runs native code, with all security implications that comes with, and help people stick to the web sandbox. Perhaps that's why Apple refuses to implement certain APIs, they make billions from the ActiveX world that has come out of the app store.

lifthrasiir 5y ago

Safari is not only notorious for unimplemented features but also for unique (and often critical) bugs in spite of the shared origin with Chrome.

ArchOversight 5y ago
"shared origin with Chrome" You mean Chrome was a fork from Webkit when Google decided they could no longer play nice with Apple...
- soperj 5y ago
  You're saying it like Webkit wasn't also a fork.
  - ArchOversight 5y ago
    That's not at all what I was saying. WebKit was a fork of KHTML, but implying that Safari has shared origin with Chrome was a little farfetched.
    - pankajdoharey 5y ago
      Webkit is far off from KHTML, just a simple code statistics will show you the number of hours by Apple Engineers on Webkit, at this point Webkit is a complete rewrite and has zero semblance with KHTML. Apple Engineers have more contributions in the repo than Google Engineers ever did. At the End Google strategy to build plugins and track users doesnt gel with the WebKit Strategy. For everyday use Safari is very energy Efficient compared to Chrome which is a Battery Hog.

jansan 5y ago

I work a lot with SVGs and from my perspective it looks like Apple just doesn't care. I have even given up sending bug reports to them, because they never get fixed.

Orphis 5y ago

Chrome engineer, working on WebRTC here. Here's my personal opinion: Safari's WebRTC implementation is not outdated, it's just bindings over the same library that is used and developed by Chrome. At worst, it's lagging a bit by a few months. What the post highlights is how some features are not available, like some codecs on some platforms. That's unlikely to be a decision from the browser engineers but probably closer to the lawyers who need time to approve a codec or other engineers working on HW acceleration. Another point is also that while WebRTC was available in most contexts, getUserMedia wasn't, and that's the API used to access cameras and microphones. Without it, WebRTC functionality loses its appeal. I believe that's now fixed and webviews can now use it. While I don't necessarily approve of those decisions for the users' sake, I still respect their choice to be able to make decisions on their own product and chose when a feature is deemed safe for release in potentially dangerous contexts. I don't know their security model, but from talking with the engineers on many occasions, they are not unreasonable people. And while Safari is lacking some new WebRTC related APIs released in Chrome, it would be fair to say that they are not all standardized yet at the IETF or W3C level. Other browsers don't necessarily implement them either, and that's fine.