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)