I like the spirit of this idea, but I don't think the code is complete. I installed Chrome but do not want it to be my default browser. If apps started doing this, I'd just uninstall Chrome. A better choice would be to present a UIActionSheet asking the user which browser to use and then save that preference to the app's Settings bundle with NSUserDefaults.
That sounds much better than just defaulting to chrome if available.
That said, this is a bit too much overhead for most developers to actually implement. For instance, you would also need to create a settings bundle, so users can reset this setting if they want.
What I'd really like to see is Apple enable this at a system level. FireFox for iOS would be nice to see, and we don't want developers to have to revisit this issue if/when it comes.
What about Google building this into the Chrome app?
When you launch the app for the first time, it could ask "Do you want to open URLs in Chrome by default in Chrome-enabled apps?", and make it possible to change this in Chrome's settings menu.
This setting could then be stored in a UIPasteboard named something like com.google.chrome.default, and apps that want to implement the functionality suggested in the original post would just look in this pasteboard for the current setting.
According to Apple's documentation, "The UIPasteboard class enables an application to share data within the application or with another application using system-wide or application-specific pasteboards." http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/...
For a couple examples: OpenUDID and SecureUDID use UIPasteboard.
It sounds like a lot of overhead, but it's really quite simple. Objective-C is a bit verbose for a Hacker News comment, so I put it up as a Github Gist: https://gist.github.com/3080870
As for making a Settings bundle, that's pretty easy too and you wouldn't have to do it unless you wanted an easy way to let someone change their preference later.
Besides all that, I think everyone agrees with you that Apple should make it possible to do it at a system level. The simplest way to do this in my opinion would be to allow users to remove pre-installed apps if there is an alternative on the device. For instance, if I have an app that responds to "http:// URLs, allow Safari to be removed.
I guess my point was, without a settings option to re-set this, it's an incomplete feature. It works for a very narrow scenario, but not for the vast diversity of scenarios that the real world will bring. For instance, your code has a fairly large bug... if the user sets chrome as the default, then at some later point they delete chrome, it won't open urls anymore.
I would definitely encourage you to polish up that gist into some kind of easily incorporated module (a category on UIApplication, perhaps?)... the more people who start doing this sort of thing, the more pressure there will be on Apple to enable this the "right" way.
Polishing it up as a category is a good idea; I might do that tomorrow. But yeah, the point of all this is that you can't set a default browser in iOS.
"Chrome for iOS has some pretty major technical restrictions imposed by the App Store, such as the requirement to use the built-in UIWebView for rendering, no V8, and a single-process model. As a result it’s been challenging to re-use critical Chromium infrastructure components.
That said, there is a lot of code we do leverage, such as the network layer, the sync and bookmarks infrastructure, omnibox, metrics and crash reporting, and a growing portion of content."
2) Sometimes my bookmarks get rearranged on the desktop after I use them in iOS.
Otherwise, great job. Syncing my browser history/bookmarks/passwords is great. And it feels more snappy than Safari, which I didn't think was even technically possible.
Yes, great job. Besides the fast networking part it also feels snappy because of the page snapshot feature. It is also a cool feedback to see reduced colors, when the content has not refreshed yet.
How would you handle the UIWebView networking yourself? THe UIWebView is really opaque, doing everything by itself.
I guess you could download the HTML externally and get it into the view through loadHTMLString:baseURL: , but that would still make the UIWebView load all images etc.
You can replace the global NSURLCache with a custom implementation, and trap all the connections in there. We use it to replace online resources with resources we've prepackaged in the bundle when possible.
You can register a NSURLProtocol to handle networking requests for UIWebView. Some applications use this to provide transparently decrypted local files to a UIWebView.
Cydia has a tweak to change your default browser. Sorted.
iOS Chrome has greater issues.
Tab management is all whizz bang but very unintuitive.
I have used it for about a day and can it fathom how to email a link to the current page to someone.
Emailing a link to the current page is not a standard use case for desktop but it is typical on mobile.
Further: it's hard to see where to arrest the loading of a page, the progress thermometer 'blue zing' thing is very attractive but it doesnt allow any interaction.
Somehow the load new incognito tab button is nearer my fingers than the load a tab in background button. It's annoying that you'd assume I'm fapping.
I think the guys developing this app need to spend more time using other mobile browsers to get a feel for the knds of things people want to do on mobile... iOS Chrome feels like a desktop experience squeezed into 3.5 inches.
Why not take this idea in a more comprehensive direction: a donation supported site with API to register your app as consuming specific mime-types, so any compliant app wanting a producer of emails for instance, could grab a list from this site and then ask the user which they prefer, out of those apps they have installed (since those apps would all phone home to the server and say "user foo@bar.com has installed app Y on device with MAC ID M".
This is a start: http://handleopenurl.com/scheme/ Register your URL scheme there to avoid collisions and help garner support from those who want to support your app.
I don't think this would make Chrome better but rather make every app that uses this code pretty crummy. What would make Chrome (and iOS) better would be Apple setting up some kind of default app system for links, mail, photo editing etc. Out of very few things, Intent is something that Android still has over iOS. Plus of course Chrome would be better with some Nitro on top :)
If you are using a jailbroken device, there are a few extensions that can provide this functionality. I believe the most comprehensive is by Ryan Petrich.
"If a user has Chrome installed, chances are they wish that it would be their default browser."
Horrible assumption. I am all for Apple stealing Android's intents. Assuming that because the user has an app installed they want it to be the default is wrong.
I think the better approach would be each app could ask the user once if they want Google Chrome to be their default browser and then store which one they should open. Sure it is more code but it will be a better user experience than forcing them to uninstall Google Chrome if they don't want it.
What's stopping the app creator from asking the user (in a settings" page) which browser s/he wants to open web pages in? Default will be Safari, unless changed explicitly
In my opinion, Android's default action system could be improved. To clear an action currently, you have to clear the associated application's defaults through its configuration page in Settings. A dedicated page would make this much easier, especially with many associated applications installed. Two things they got right was asking again if an associated program is installed/updated and giving a persistent checkbox of whether to ask again.
Curious, why? You don't really need more than one browser on your phone. If you installed Chrome and haven't deleted it, one can assume it's because the person prefers Chrome. Otherwise you can just delete it after having tried it out. Or am I missing something?
It can't really even be for testing, since on iOS it's not like it's possible for Chrome to render any differently than in Safari!
My iPad has lots of rarely-used apps in it, as do most of my friends'. I haven't used Chrome enough to decide if I want to keep it or not, the mere fact that it exists shouldn't indicate preference.
Given the lack of Nitro support for non-Safari browsers, you'd likely need to use another browser to better support a site which was largely JS based.
Also, for some reason I can have many 10s of tabs open to pages on Safari (with a jailbreak tweak) whereas doing the same in a non-Safari browser causes a crash.
I use it on the rare occasion I want to move a url from the desktop (where I use chrome). Aside from that, Safari works well for me. (The desktop remote debugging coming in 6.0 is really nice, too.)
I'd probably use it for bookmark sync, too, but my bookmarks are such an unmanageable mess I usually just google stuff I need to find again. (Beyond a few very static bookmarks.)
This is one the many reasons why I would never buy another iPhone if it couldn't be jailbroken.
It seems weird that 'hacker news' readers aren't more excited about 'hacking' the incredible computer in their pockets.
We don't need to beg developers to support Chrome if we can just change the default browser ourselves - http://i.imgur.com/f50Kxl.png
Other reasons to jailbreak:
* Grooveshark - Seems to have a bigger music collection than Spotify, best $9 I spend each month.
* VLC media player
* SSH - how is that not useful?
* SBSettings
* 5 columns for Springboard icons
* Compiling and installing any open source iPhone apps
While this is an interesting idea, it is pretty useless in practice, IMO. Email is by far the app I (and I assume most others) am going to be clicking the most links from, and I'm gonna go out on a limb and say that Apple won't be changing their links to go to chrome.
If you use something like the gmail app, they (if they don't already) should probably be doing something like this.
That's a bit of a stretch. You shouldn't notice that much of a performance difference unless you go to the desktop version of Gizmodo or BusinessInsider. Fortunately they already have mobile versions (at least Gizmodo does).
Good idea to come up with a minimal implementation of intents on the caller side. Apple will probably block it if it threatens to become useful though, because that would challenge iOS Safari.
I haven't used iOS, but as an Android user I can definitely see why they haven't implemented it yet. It's a powerful feature, but at least on Android, it's also a usability disaster.
Basically, the way it works on Android is that whenever an intent is passed for which there is no default, the user gets a dialog. The dialog will contain the applications that the user has installed for handling that intent. When there are 4+ items (eg, PDF) this can be confusing.
Then when they pick one (hopefully the one they really wanted) they check the box to make it default. So far this is confusing for some people, but they generally muddle through somewhat happily.
But there are issues... which protocols does the browser accept? Oh, http, https, and possible one or two more. So later they tap an https url and have to go through the same process again.
The next day, one of their four web browsers auto-updates from the Play store. This clears the defaults, and they have to go through the whole process again.
Seriously, the underlying concept seems solid, but the implementation is severely lacking. I hope that they (or someone) does this right in the future. I'm not entirely sure what a solid solution would look like, but I certainly don't expect Apple to copy the Android approach. It's completely incompatible with a number of their UX goals for the platform, IMO.
The lack of "Intents" on iOS is deliberate IMHO. Apple's products are in the default roles for all the common intents and implementing support for switching intents across the OS would result in less people using Apple's first-party apps. Being the browser is a very valuable position, and not one I expect Apple would invest dev resources to give up.
Is Chrome for iOS open source? Would there be a way to add V8 back in and release it on Cydia? That may extend the lifespan of Apple products indefinitely. My iPad 1 is already deemed obsolete by Apple and will never receive another web browser update ever, which is obviously retarded. Apple seriously needs to get that giant stick out of their ass.
a) AFAIK, no (as in, it is not open source). b) The change would not just be to mess with the JavaScript engine: it would require totally replacing out the UIWebView backend they are currently using from Apple and, well, pretty much putting back Chrome. They are not rendering the HTML, Apple's UIWebView class is; it would probably be easier to just attempt to recompile/replace JavaScriptCore system wide to stub into v8. c) According to Apple (whom you may or may not believe), v8 is not actually much faster (if not slower) than Nitro right now, so you may as well just turn on Nitro in Chrome (which is easy to do on a jailbroken device).
> so you may as well just turn on Nitro in Chrome (which is easy to do on a jailbroken device).
I know you may mean that it is easy to implement this but just checking if there already exists something which can do this. I searched Google and Cydia with no results. This definitely can be very very useful to a lot of people, esp hackers.
I believe it is just a matter of adding the "dynamic-codesigning" entitlement. I started typing up instructions for how to do it with a few shell commands, but then I ran into a limitation with my ancient version of codesign_allocate that caused me to fail. :( You should definitely be able to do it from a Mac fairly easily, however.
I'm not concerned about raw performance. I'm concerned with Apple forceably making iPad 1 (along with all older devices) unnecessarily obsolete by restricting the web browser on the device.
A really good example is the iPad 1 is still using an obsolete version of the WebSocket protocol. That means web servers that want to support iPad 1, must run libraries that support an outdated version of the protocol (one that contains security vaulnerabilities). The protocol can never be updated because Apple won't allow new web browsers on the device. It's a two-pronged approach which both forces obsolescense, and forces developers to needlessly add backwards compatibility layers to cover all the bases.
This is many times worse than the nightmare web developers have been facing with IE6, IE7, and IE8 support requirements because in those cases there was always the option of installing another browser, or something like Chrome-frame.
First step to making it better might be fixing the awful scrolling. Chrome on iOS is slick but it stutters like hell when scrolling large vertical pages. Safari has no problem.
