Comment by abalone | Hacker News Reader

Comment by abalone | Hacker News Reader

Parent Full thread

> You can install 3rd party apps that can do whatever they want (within the limitations of the platform) power-wise.

The key phrase being "within the limitation of the platform." Apple's been pretty consistent in designing (and limiting) key developer APIs to be power efficient. And they're willing to ship later to achieve it. I mentioned WebKit. A more obvious example of this is their approach to multitasking. Android let apps do more or less whatever they wanted and they supported multitasking first. Apple waited until iOS 4, but the more structured and regulated set of APIs they came out with was much more battery friendly.

> I think the most charitable explanation possible is that Apple doesn't want any kind of "open with..." choice

Yet iOS 8 added a bunch of extension APIs.[1] You can literally open content in other apps via the system share dialog, including third party mapping and voip apps. The stated reasons for waiting until iOS 8 were that they needed to do a bunch of architectural work first.[2]

[1] https://developer.apple.com/library/content/documentation/Ge...

[2] http://www.imore.com/our-full-transcript-talk-show-wwdc-2016...

Your argument is still not making much sense. I don't see how the power efficiency of the APIs is relevant. The point is that they currently allow tons of applications (E.g. Candy Crush) that drains the battery. What's the reason for making the browser a special case? It's just rendering to the screen like any other application.

One argument I could see being made is that the browser is used more than others and thus warrants tighter control. But even that is weak. People are draining their batteries all day long playing games as it is.

I believe that the real reason is that Webkit needs privileged APIs and unique executable memory regions for the jit. Giving third-party developers that access would make jailbreaking a simpler process.

Anything that makes jailbreaking simpler also makes it easier for the device and data to be compromised.

Apple might have walled garden motives, but the security story is compelling on its own.

> The key phrase being "within the limitation of the platform." Apple's been pretty consistent in designing (and limiting) key developer APIs to be power efficient.

Which I applaud. But those APIs constrain all applications equally.

So if Apple allowed browser applications to include their own rendering engines, their APIs would naturally constrain those applications too.

Now it could be that Apple does not want to enable applications other than WebKit access to APIs that would allow jit compilation. OK, that is reasonable. But in that case, why not allow browsers to provide their own rendering engine but just mandate that only JSC is allowed to run JS?

Or why not just say that only Apple apps can jit and let the market figure it out?

(I'm going to drop the thing about 'open with...' because it was a distraction and ancillary to my main point, which is that Apple is doing this because they want to control progress of the web platform on iOS)

Reply on news.ycombinator.com