Google looks to spark iOS browser war with OpenInChrome function
Google looks to be attempting to grow its mini-ecosystem on Apple's iOS platform, as the search giant is now enticing developers to have their apps open web links in its Chrome browser.
Google on Tuesday publicized a new API feature, OpenInChromeController, in a post (via The Inquirer) on The Chromium Blog. OpenInChromeController allows developers to have links within their apps open in Google's Chrome iOS browser instead of in the default Safari browser. OpenInChromeController also makes the Back button in Chrome point toward the originating app, so that users can return to the app in one tap.
The feature also allows for checking whether Chrome is installed on a device, and developers can specify whether a link should open in a new tab or not.
Google provided additional documentation on the OpenInChromeController API on its developers site. Developers can download the API from that site in order to integrate it into their apps, if they wish.
Taken in combination with Google's recent Chrome efforts on iOS, the search giant's push to integrate and expand its own micro-ecosystem on Apple's mobile platform comes into stark relief. Monday saw the release of an updated Gmail app that doesn't route web links, location data, and YouTube links through Apple's default Safari browser. Instead, the app now opens such links directly within Google's relevant apps: Chrome Google Maps, and YouTube.
Google's Chrome browser debuted to some degree of popularity, but the inability to set it as a default browsing app on iOS has relegated the browser to a very distant second place to Apple's Safari among iOS browsers.
Tying Chrome and other Google services together, though, could be a way for the search giant to grow browser share and enrich its suite of apps on Apple's platform. Google has, for the past few months, been building in the capability for its apps to interact with each other, tweaking its Google+ app to open links in Chrome in addition to its more recent efforts.
Opening up the possibility for developers to specify a default browser other than Apple's Safari, though, could mark the beginning of a new generation of browser wars similar to the struggles seen between Microsoft's Internet Explorer and other competitors in the desktop computing era.
Google on Tuesday publicized a new API feature, OpenInChromeController, in a post (via The Inquirer) on The Chromium Blog. OpenInChromeController allows developers to have links within their apps open in Google's Chrome iOS browser instead of in the default Safari browser. OpenInChromeController also makes the Back button in Chrome point toward the originating app, so that users can return to the app in one tap.
The feature also allows for checking whether Chrome is installed on a device, and developers can specify whether a link should open in a new tab or not.
Google provided additional documentation on the OpenInChromeController API on its developers site. Developers can download the API from that site in order to integrate it into their apps, if they wish.
Taken in combination with Google's recent Chrome efforts on iOS, the search giant's push to integrate and expand its own micro-ecosystem on Apple's mobile platform comes into stark relief. Monday saw the release of an updated Gmail app that doesn't route web links, location data, and YouTube links through Apple's default Safari browser. Instead, the app now opens such links directly within Google's relevant apps: Chrome Google Maps, and YouTube.
Google's Chrome browser debuted to some degree of popularity, but the inability to set it as a default browsing app on iOS has relegated the browser to a very distant second place to Apple's Safari among iOS browsers.
Tying Chrome and other Google services together, though, could be a way for the search giant to grow browser share and enrich its suite of apps on Apple's platform. Google has, for the past few months, been building in the capability for its apps to interact with each other, tweaking its Google+ app to open links in Chrome in addition to its more recent efforts.
Opening up the possibility for developers to specify a default browser other than Apple's Safari, though, could mark the beginning of a new generation of browser wars similar to the struggles seen between Microsoft's Internet Explorer and other competitors in the desktop computing era.
Comments
Considering that Google is looking to branch WebKit into their own project, at which point I don't think future versions of Chrome will be allowed on the store (unless, of course, they don't integrate the new code they swear they have and need said branching to implement)... does it really matter? Seems like they're only setting up developers - and Chrome users - for disappointment when in a few months to a year, everything gets shunted back to Safari and devs need to redo their apps.
Quote:
Originally Posted by OllieWallieWhiskers
i have chrome installed, but i don't want it to be my default browser... so this is rather annoying.
If I read right it doesn't change your default browser, it would still be Safari. Developers would just have a choice of making a call to Chrome within their app, if Chrome is already installed. I think I have that right.
Somehow this seems to be like pushing the envelope of what is "allowed" by Apple in iOS. If some smaller developer attempted something like this, Apple would shut him down in a heartbeat.
I don't think we have heard the last of this yet.
Quote:
Originally Posted by Gatorguy
If I read right it doesn't change your default browser, it would still be Safari. Developers would just have a choice of making a call to Chrome within their app, if Chrome is already installed. I think I have that right.
i think your right....but that code is useless if you don't have Chrome installed? But it would be nice to have the ability to choose what browser you want have as default.
The entire content of this article boils down to ... "There is a thing called an 'open in chrome controller' that exists now."
It is an app? It is an API? It is made entirely of Cheese? It's a demo? It's a beta? It's a planned product? It's an existing (working) product?
Quote:
Originally Posted by Gatorguy
If I read right it doesn't change your default browser, it would still be Safari. Developers would just have a choice of making a call to Chrome within their app, if Chrome is already installed. I think I have that right.
And what if I have Chrome installed but only use it for certain pages that don't display right in Safari? If the article is correct, it looks for Chrome and then directs you to it if it is installed. And I think I have the right to NOT have random apps go "Oh, you have Chrome installed? Then screw your normal surfing habits, I'm taking you to Chrome instead of Safari".
Quote:
Originally Posted by Gazoobee
How can anyone sensibly comment on this development when the article says absolutely *nothing* about how this trick is accomplished?
The entire content of this article boils down to ... "There is a thing called an 'open in chrome controller' that exists now."
It is an app? It is an API? It is made entirely of Cheese? It's a demo? It's a beta? It's a planned product? It's an existing (working) product?
If you actually read the article instead of being sarcastic, it's something developers can download and add to their apps that modifies the behavior of links within their apps. It's up for download now, meaning it could theoretically be in the wild as of... what's the average pass through from submission to App Store approval these days?
Quote:
Originally Posted by AppleInsider
... The feature also allows for checking whether Chrome is installed on a device...
This sounds like a security hole in the sandboxing that Apple needs to plug in the next iOS update. Apps ought not be able to check what other apps are installed.
Quote:
Originally Posted by skottichan
And what if I have Chrome installed but only use it for certain pages that don't display right in Safari? If the article is correct, it looks for Chrome and then directs you to it if it is installed. And I think I have the right to NOT have random apps go "Oh, you have Chrome installed? Then screw your normal surfing habits, I'm taking you to Chrome instead of Safari".
If you actually read the article instead of being sarcastic, it's something developers can download and add to their apps that modifies the behavior of links within their apps. It's up for download now, meaning it could theoretically be in the wild as of... what's the average pass through from submission to App Store approval these days?
you are right...i re-read the article. So an app developer could put code in their app to re-direct a link to use chrome to open a link instead of Safari?
But that would only happen if they had Chrome installed. I wonder if Apple will let this get through the app approval/certification process?
You've had a browser choice since day one of the App Store. What you haven't had is browser engine choice. This is a bit tricky whilst still maintaining security of their highly popular, highly ubiquitous iOS platform but I think Apple will eventually allow it.
Do apps getting access to the WebKit engine yet have the same low-level access that allows for much faster JS that Apple's native iOS apps have?
Quote:
Originally Posted by skottichan
And what if I have Chrome installed but only use it for certain pages that don't display right in Safari? If the article is correct, it looks for Chrome and then directs you to it if it is installed. And I think I have the right to NOT have random apps go "Oh, you have Chrome installed? Then screw your normal surfing habits, I'm taking you to Chrome instead of Safari".
Right, this has nothing to do with Google promoting user choice. This is all about Google compromising your privacy on iOS in any way they can, and asking naive and stupid app developers to help them do it. All the more reason not to install any Google apps (i.e., spyware) on any of your systems.
i think so because this has been a part of their OS for years.
Quote:
Originally Posted by Gatorguy
If I read right it doesn't change your default browser, it would still be Safari. Developers would just have a choice of making a call to Chrome within their app, if Chrome is already installed. I think I have that right.
The rights you have are determined by Apple on their platform not Google or any other competitor who is trying to leverage the IOS platform for their own gain. If I down load an app that has a link in it I don't want it opening into Chrome because I don't want an unguarded Google on my phone. If I did I would buy an Android phone. If the link is directed to open in Chrome and I don't have it then it would of course demand that I download it to continue which I would also find annoying and an interruption to my experience. GOOGLE NEEDS TO GO WAY!!!!!!!!
Google is not promoting user choice if the third party app automatically opens Chrome. I also have Chrome on my iPhone, but I never use it. I downloaded it to be curious. Now all the sudden third party apps are going to open up things in Chrome. No thanks.
Quote:
Originally Posted by Gazoobee
How can anyone sensibly comment on this development when the article says absolutely *nothing* about how this trick is accomplished?
The entire content of this article boils down to ... "There is a thing called an 'open in chrome controller' that exists now."
It is an app? It is an API? It is made entirely of Cheese? It's a demo? It's a beta? It's a planned product? It's an existing (working) product?
Essentially they have created an new protocol to replace http:// and https://
very good,but i do'nt like google
I'm not against browser choice by any stretch (cough, AdBlock, cough, cough), but I'd be very unlikely to ever install Chrome. Google collects enough information as it is.
Quote:
Originally Posted by SolipsismX
You've had a browser choice since day one of the App Store. What you haven't had is browser engine choice. This is a bit tricky whilst still maintaining security of their highly popular, highly ubiquitous iOS platform but I think Apple will eventually allow it.
Do apps getting access to the WebKit engine yet have the same low-level access that allows for much faster JS that Apple's native iOS apps have?
Very nice distinction! I missed that....