4 ms·

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 UIW

by tl 14y ago

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.

paupino_masano 14y ago
Yeah, you're right: it appears it is just a skin: https://developers.google.com/chrome/mobile/docs/faq 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.
- georgemcbay 14y ago
  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.
  - rohitnair 14y ago
    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-firefox-home/ https://blog.mozilla.org/services/2012/08/31/retiring-firefo...
wahnfrieden 14y ago
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.
- georgemcbay 14y ago
  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.
  - MaxGabriel 14y ago
    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 http://www.luanova.org/ioswithlua
    - wahnfrieden 14y ago
      Yeah that's out of date. Even Flash is allowed now.
    - georgemcbay 14y ago
      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.
gte910h 14y ago
The only code interpreter allowed is the Safari code interpreter that's in the UIWebView.

by tl 14y ago

paupino_masano 14y ago

Yeah, you're right: it appears it is just a skin: https://developers.google.com/chrome/mobile/docs/faq 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.

georgemcbay 14y ago
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.
- rohitnair 14y ago
  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-firefox-home/ https://blog.mozilla.org/services/2012/08/31/retiring-firefo...

wahnfrieden 14y ago

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.

georgemcbay 14y ago
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.
- MaxGabriel 14y ago
  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 http://www.luanova.org/ioswithlua
  - wahnfrieden 14y ago
    Yeah that's out of date. Even Flash is allowed now.
  - georgemcbay 14y ago
    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.

gte910h 14y ago

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