Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> like all browsers on iOS, this is just a UI skin and added functionality over the Mobile Safari core

Not true, for example Opera Mini[1], perhaps others. I wouldn't jump to conclusions that fast.

1. http://www.opera.com/mobile/iphone



Opera Mini represents the ONLY way to get around Apple's onerous restrictions: render the content entirely on servers and push it to the browser. It's inefficient and messy and makes for a less than stellar user experience. It also sets the barrier to entry very high. This is why you won't see Firefox on iOS. Mozilla would be happy to build it, but they won't live the lie of having a Firefox name on the Mobile Safari engine (in slower 3rd party mode).

No one is jumping to conclusions here. This is the specific result Apple wants and is by design of their policies. It's well known and there's no debate over it. You can have your own browser on iOS, but it can't interpret JavaScript (no interpreted code on iOS), meaning it's completely useless on the modern internet. It's the perfect way to enforce a one-browser-to-rule-them-all rule, locking out all competitors, while couching it in a 'security' guideline.


Just because you don't have a JIT doesn't mean it's "completely useless on the modern internet." On the contrary, I rarely (ever?) have run into this as an actual bottleneck.


You're confusing two different things here:

1. Not being able to use JIT is just the anti-competitive part that Apple does to people who ship UIs/skins over Mobile Safari.

2. The more insidious bit is that you can't run interpreted code in your own app AT ALL, which prevents Google, Mozilla, Opera, etc from being able to ship their own full browser engine because it wouldn't be able to implement JavaScript AT ALL, making it completely useless on the modern internet.

So, you're left with Chrome on iOS which is just a fancy skin/UI over Mobile Safari (sans JIT so it's forced to be slower so Safari looks better by comparison). Compare that to Chrome for Android which is the full Blink-based browser stack tweaked to be as fast and smooth as possible. Or Firefox on Android which is the full Gecko engine with a custom Android native UI running over the top. You can't have the Gecko or Blink engines at all on iOS because Apple says so.


How is this any different from what MS was doing in the 90's?


Apple isn't preventing the use of JIT in a UIWebView to make safari look better, they're doing it because if the JIT has to break the sandbox and that screws up their whole app model.

I'm sure it can be done, but that's the biggest reason it hasn't been done.


The same MS that tried (and failed) to disrupt and dislodge Netscape's JavaScript?


And your point is? It was wrong, anti-competitive, and anti-consumer then. It's the same now. It's just being done by a different company that doesn't have a monopoly (thanks to Android).


Yep, don't disagree with any of that stuff, just the fact that no JIT is a dealbreaker. It's not.


Which is odd, since I never claimed it was a dealbreaker. I just said that's why all the browsers on iOS are slower than Safari. It artificially keeps Safari's performance high relative to competing browsers (well, Safari skins).

The only thing that's a dealbreaker for me is that Apple prevents all other real browsers from shipping for iOS. One browser only is a dealbreaker for me on any OS.


Ah, appears I misread your original comment -- you were talking about third party browser implementors. My bad.


There are two separate issues:

1) You can't ship your own browser engine 2) If you use the built in engine, you don't get JIT on (but Mobile Safari does)




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

Search: