Hacker News new | past | comments | ask | show | jobs | submit login

For the record, I am more than happy to use Apple's web components. WebKit is great. They just need to open the APIs more. Like WebKit on macOS. Then we can actually build competing browsers and do more innovative things.

The WebKit team is great. Look at all the web standards being worked on. Look at the ES6 progress. They are pushing the state of the web forward on iOS.

Now put some of that same energy in WKWebView. Open it up. We need more than just loadURL()

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.

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.

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.

Oh I agree that the ban on alternative engines should be lifted. No disagreement there.

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.

Sure, but there is also a huge amount in the rendering engine that can't be changed, which is the issue.

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.

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

> 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".

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.

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.

They are. But Apple was the only company smart enough to control that on their mobile platform BEFORE it became an issue.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact