4 ms·

I can't comment on desktop Safari, but mobile Safari certainly deserves the hate it receives. I think it has to do with the update cycle, or lack thereof. The

I can't comment on desktop Safari, but mobile Safari certainly deserves the hate it receives. I think it has to do with the update cycle, or lack thereof. The iOS browser gets updated a couple times a year with new minor OS releases, whereas browsers for older OS versions get no updates ever. So if a bug is hardy enough to survive an entire year, it's there to stay. Given Apple's opaque approach to support, even a good repro case of a bug in an upcoming iOS release is unlikely to ever make it to a fixed shape by the time said OS version is obsolete. So you have to switch for every single OS version, by name, since features are in fact in place, but work inconsistently between versions. Before typing this, I just finished putting the first few new iOS9 switches into the app I'm developing, resurrecting various things that they killed in the beta. Maybe those switches can come out when they ship the real thing. But that has never happened before, so I'm not holding out any hope.

mikeash 11y ago
Mobile Safari also deserves hate because Apple prohibits all alternatives. You cannot ship a browser for iOS unless it uses Safari's engine. There's no technical reason, it's just a decree from Apple about what they'll allow.
- xbmcuser 11y ago
  There is a technical reason other engines won't hamper or slow web apps. This will allow for apps on ios from outside the app store. That is the only reason they are not allowing other browser engines.
  - mikeash 11y ago
    How does Safari hamper or slow web apps?
- bobajeff 11y ago
  If I remember correctly. That wasn't spelled out exactly. I think the policy that browser vendors are referring to is one that says something like "[no app can duplicate functionality that's in the OS]" or something to that effect. Basically, no vendor wants to put in the work of porting to iOS without the guarantee that it can be excepted in the App Store.
  - mikeash 11y ago
    I'm not sure how it was in the past, but it's explicit now: "2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"
    - bobajeff 11y ago
      Oh, too bad about that.
- mightykan 11y ago
  There is very much a technical reason that third-party rendering engines won’t work: JavaScript JIT. Basically, for JIT to work, a process has to be able to mark a piece of memory executable, which would cause all sorts of issues with sandboxing/security. Apple did introduce XPC in iOS 8 and all the extensions use XPC extensively to respect the sandboxing rules. This is what they used to introduce the WebKitViewController whose JavaScript performance is on part Mobile Safari (UIWebView’s JavaScript performance is poor due to not having JIT). In fact, the new SafariViewController that was introduced in iOS 9, which is effectively an embedded Mobile Safari in third-party apps, is mainly possible because the OS has first-class support for XPC within the confines of the application sandbox. I could see, although I’m not sure how likely it would be, Apple introducing a new Extension Point for rendering engines. Although it’s attractive to attribute malice to their intentions, I don’t think Apple are actively enforcing the “all third-party browsers have to use WebKit" for any other reason than security and battery life impact. If they could find a way to allow third-party rendering engines/browsers to work within the confines of the application sandbox, be secure and have insignificant impact on the battery life, they would allow it. They’re almost there technically, anyway.
  - mikeash 11y ago
    Since UIWebView doesn't do JIT, as you say, and third party browsers using UIWebView are allowed, I don't think this theory holds up. The inability for third-party engines to do JIT certainly is a problem, but it doesn't look like the problem that causes Apple to make this restriction.
- koffiezet 11y ago
  I'm pretty sure Opera for iOS uses it's own renderer: https://dev.opera.com/blog/opera-mini-8-for-ios/ https://dev.opera.com/blog/opera-mini-8-for-ios/
  - mikeash 11y ago
    This is either a loophole due to the fact that rendering happens server-side, or Apple just hasn't bothered to smite them yet. The rules are extremely clear.
rocky1138 11y ago
The author lost me when he wrote "On mobile I’ll take iOS Safari over any Android-based browser..." Safari on mobile is crap because it doesn't render like the other browsers do. Just like with IE we are constantly having to do special conditions for those unfortunate souls on iOS Safari. Hence, Safari is the new IE.
Avernar 11y ago
I absolutely hate mobile Safari. I've got a dozen workarounds for various things in my code and still can't get a few things to work quite right. I had to make my own buttons as having too many buttons would slow rendering of the page to a crawl. The gradient background was the speed killer. Doesn't help that you can only remote debug the browser from a Mac.

mikeash 11y ago

Mobile Safari also deserves hate because Apple prohibits all alternatives. You cannot ship a browser for iOS unless it uses Safari's engine. There's no technical reason, it's just a decree from Apple about what they'll allow.

xbmcuser 11y ago
There is a technical reason other engines won't hamper or slow web apps. This will allow for apps on ios from outside the app store. That is the only reason they are not allowing other browser engines.
- mikeash 11y ago
  How does Safari hamper or slow web apps?
bobajeff 11y ago
If I remember correctly. That wasn't spelled out exactly. I think the policy that browser vendors are referring to is one that says something like "[no app can duplicate functionality that's in the OS]" or something to that effect. Basically, no vendor wants to put in the work of porting to iOS without the guarantee that it can be excepted in the App Store.
- mikeash 11y ago
  I'm not sure how it was in the past, but it's explicit now: "2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"
  - bobajeff 11y ago
    Oh, too bad about that.
mightykan 11y ago
There is very much a technical reason that third-party rendering engines won’t work: JavaScript JIT. Basically, for JIT to work, a process has to be able to mark a piece of memory executable, which would cause all sorts of issues with sandboxing/security. Apple did introduce XPC in iOS 8 and all the extensions use XPC extensively to respect the sandboxing rules. This is what they used to introduce the WebKitViewController whose JavaScript performance is on part Mobile Safari (UIWebView’s JavaScript performance is poor due to not having JIT). In fact, the new SafariViewController that was introduced in iOS 9, which is effectively an embedded Mobile Safari in third-party apps, is mainly possible because the OS has first-class support for XPC within the confines of the application sandbox. I could see, although I’m not sure how likely it would be, Apple introducing a new Extension Point for rendering engines. Although it’s attractive to attribute malice to their intentions, I don’t think Apple are actively enforcing the “all third-party browsers have to use WebKit" for any other reason than security and battery life impact. If they could find a way to allow third-party rendering engines/browsers to work within the confines of the application sandbox, be secure and have insignificant impact on the battery life, they would allow it. They’re almost there technically, anyway.
- mikeash 11y ago
  Since UIWebView doesn't do JIT, as you say, and third party browsers using UIWebView are allowed, I don't think this theory holds up. The inability for third-party engines to do JIT certainly is a problem, but it doesn't look like the problem that causes Apple to make this restriction.
koffiezet 11y ago
I'm pretty sure Opera for iOS uses it's own renderer: https://dev.opera.com/blog/opera-mini-8-for-ios/ https://dev.opera.com/blog/opera-mini-8-for-ios/
- mikeash 11y ago
  This is either a loophole due to the fact that rendering happens server-side, or Apple just hasn't bothered to smite them yet. The rules are extremely clear.

rocky1138 11y ago

The author lost me when he wrote "On mobile I’ll take iOS Safari over any Android-based browser..." Safari on mobile is crap because it doesn't render like the other browsers do. Just like with IE we are constantly having to do special conditions for those unfortunate souls on iOS Safari. Hence, Safari is the new IE.

Avernar 11y ago

I absolutely hate mobile Safari. I've got a dozen workarounds for various things in my code and still can't get a few things to work quite right. I had to make my own buttons as having too many buttons would slow rendering of the page to a crawl. The gradient background was the speed killer. Doesn't help that you can only remote debug the browser from a Mac.