4 ms·

But why should third party developers forced to use the engine Apple provides, instead of trying to innovate? The whole point of having different browsers is t

But why should third party developers forced to use the engine Apple provides, instead of trying to innovate? The whole point of having different browsers is to have competition (which means better performance/new features), but currently in the iOS world there is Safari and multiple reskinned Safaris.

jeromegv 10y ago
Because of security, browsers are a huge vector of attack.
- koolba 10y ago
  > Because of security, browsers are a huge vector of attack. That's not a valid reason. With per-app sandboxing. At worst a non-Apple native browser that escape the confines of the web page and be subject to app security. That amounts to using "security" as an argument for not being allowed to do something with the reason as, "Because we're smart and you're not".
  - st3fan 10y ago
    There is a sandbox, but to be a competitive third-party browser you also need something else: Safari has a special permission (entitlement) that allows it to compile JavaScript to native code. This is what their JIT does. This is something that no third-party app has ever gotten. No JIT means slow JavaScript. No ASM.js, no WebAssembly. I have mixed feelings about giving third-party applications (browsers) this permission. Bugs can lead to remote code execution, can lead to sandbox escapes, can lead to compromised devices. This is a really tough one. Specially for apps that load random content from the web.
- zanny 10y ago
  Then I guess we need to get rid of all the alternate browsers on Android, Windows, Linux, etc because they are all just ticking time bombs waiting to destroy your device.
  - m82labs 10y ago
    They are. But Apple was the only company smart enough to control that on their mobile platform BEFORE it became an issue.
st3fan 10y ago
Stop talking about 'reskinned safari' please. This is not how it works. It is not what those alternative browsers currently are. You make it sound like we just change the color of the bezel. There are huge amounts of code around the WKWebView, which is the only thing common between browsers.
- Latty 10y ago
  Sure, but there is also a huge amount in the rendering engine that can't be changed, which is the issue.
  - st3fan 10y ago
    My counterpoint is that with better, more open, APIs in WKWebview we would be able extend the current engine with new, unique, functionality. I would be happy with that as a start.
- AsyncAwait 10y ago
  Servo for example cannot come to iOS because of Apple's restrictions. It doesn't matter that YOU are fine with WebKit, some of us want to see dfferent rendering engines seeing how they're kind of core to the whole browser. WebKit is slowly but surely becoming another IE, something I think we can all agree would be a bad thing.
  - st3fan 10y ago
    Oh I agree that the ban on alternative engines should be lifted. No disagreement there.
  - eridius 10y ago
    Edit: The following comment is incorrect. I checked the guidelines and they've actually revised it to explicitly say you have to use WebKit for apps that browse the web. > Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript Original comment: AIUI the only real restriction here is against executing downloaded code, but you should be able to still write your own competing engine as long as you use JavaScriptCore to execute JS. That said, you can't do out-of-process execution or JIT compilation, so your engine won't be as fast as WKWebView, which means it won't be competitive and so there's not much reason to go through all the effort of making a new iOS browsing engine if users aren't going to want to use it.

jeromegv 10y ago

Because of security, browsers are a huge vector of attack.

koolba 10y ago
> Because of security, browsers are a huge vector of attack. That's not a valid reason. With per-app sandboxing. At worst a non-Apple native browser that escape the confines of the web page and be subject to app security. That amounts to using "security" as an argument for not being allowed to do something with the reason as, "Because we're smart and you're not".
- st3fan 10y ago
  There is a sandbox, but to be a competitive third-party browser you also need something else: Safari has a special permission (entitlement) that allows it to compile JavaScript to native code. This is what their JIT does. This is something that no third-party app has ever gotten. No JIT means slow JavaScript. No ASM.js, no WebAssembly. I have mixed feelings about giving third-party applications (browsers) this permission. Bugs can lead to remote code execution, can lead to sandbox escapes, can lead to compromised devices. This is a really tough one. Specially for apps that load random content from the web.
zanny 10y ago
Then I guess we need to get rid of all the alternate browsers on Android, Windows, Linux, etc because they are all just ticking time bombs waiting to destroy your device.
- m82labs 10y ago
  They are. But Apple was the only company smart enough to control that on their mobile platform BEFORE it became an issue.

st3fan 10y ago

Stop talking about 'reskinned safari' please. This is not how it works. It is not what those alternative browsers currently are. You make it sound like we just change the color of the bezel. There are huge amounts of code around the WKWebView, which is the only thing common between browsers.

Latty 10y ago
Sure, but there is also a huge amount in the rendering engine that can't be changed, which is the issue.
- st3fan 10y ago
  My counterpoint is that with better, more open, APIs in WKWebview we would be able extend the current engine with new, unique, functionality. I would be happy with that as a start.
AsyncAwait 10y ago
Servo for example cannot come to iOS because of Apple's restrictions. It doesn't matter that YOU are fine with WebKit, some of us want to see dfferent rendering engines seeing how they're kind of core to the whole browser. WebKit is slowly but surely becoming another IE, something I think we can all agree would be a bad thing.
- st3fan 10y ago
  Oh I agree that the ban on alternative engines should be lifted. No disagreement there.
- eridius 10y ago
  Edit: The following comment is incorrect. I checked the guidelines and they've actually revised it to explicitly say you have to use WebKit for apps that browse the web. > Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript Original comment: AIUI the only real restriction here is against executing downloaded code, but you should be able to still write your own competing engine as long as you use JavaScriptCore to execute JS. That said, you can't do out-of-process execution or JIT compilation, so your engine won't be as fast as WKWebView, which means it won't be competitive and so there's not much reason to go through all the effort of making a new iOS browsing engine if users aren't going to want to use it.