Hacker News Reader

Comment by paupino_masano | Hacker News Reader

I think this misses the point. I'm not sure about Windows phone, but iOS has Chrome and Opera already. While they are not default browsers, they still have an offering available for download.

I think when he says they can't, I think it is more about their code base/engine requirements than anything else.

View on HN

Correct me if I'm wrong, but iOS does not have Chrome or Opera because the only browser allowed is Safari/UIWebView. It has an app called "Chrome" that runs UIWebView and has features like tab/bookmark sharing.

Yeah, you're right: it appears it is just a skin: https://developers.google.com/chrome/mobile/docs/faq

Perhaps the idea was to get something out there for presence and then create a full rendering engine later? But then again, both Chrome and Safari are WebKit and Firefox is Gecko so I'm not sure how that changes things.

The core issue is actually JavaScript as I mentioned in another post. I doubt Google thinks this will ever change and they assume they'll never be able to deliver full Chrome on iOS. They provide the Chrome they do provide because one of the nice features of Chrome is universal syncing (of bookmarks, etc) between all your Chrome-running devices that you are signed into.

While Chrome on iOS isn't really Chrome, it does sync in to this so that your bookmarks, etc, work there just like on any real Chrome browser.

Firefox had a similar offering called Firefox Home on iOS which would sync bookmarks, history and even open tabs. It worked/works really well and I still use it. Mozilla, however, recently retired the app and made the source available on github[1]. The fact that Firefox currently has virtually no support on iOS is really frustrating for Firefox users in the Apple ecosystem.

[1] - https://blog.mozilla.org/services/2012/08/31/retiring-firefo...

I can't reply to the other reply, so I'll write it here: providing your own rendering engine is against Apple's ToS. That's why Chrome is just a UIWebView wrapper.

The practical impact is the same, but the way I understand it is providing your own rendering engine isn't a problem, the problem is providing your own JavaScript engine.

iOS technically prohibits JITs, which would kneecap v8, but on top of that they also, as policy, disallow running arbitrary code downloaded to the device from the Internet unless Safari's JavaScript engine is the thing running that code.

I read in a recent HN post that they changed that. Was it wrong?

"In fact, an earlier version of this article was tabled when Apple made changes to the developer license (circa April 2010) which forbade developing iOS applications in any language other than Objective-C and Javascript (the Javascript could be used either to build web apps or native apps via the UIWebView). Recently (September 2010), Apple again changed the developer license to allow the use of scripting languages.." http://www.luanova.org/ioswithlua

Yeah that's out of date. Even Flash is allowed now.

It wasn't wrong but the changes are somewhat subtle.

Previously Apple disallowed using languages other than Objective-C and JavaScript.

Now they allow you to use any language you can get to compile on the device (some languages have issues because you technically can't do JITing on the iOS device, the OS stops you from self-modifying code) but you aren't allowed to run code that was downloaded at runtime.

Example: You can embed a Lua interpreter into your app to run Lua scripts, but the scripts you execute have to all ship with your app, you can't download them at runtime and then execute them.

The only code interpreter allowed is the Safari code interpreter that's in the UIWebView.

Reply on news.ycombinator.com