May 24, 2010 · 4 min read

Interaction between iPhone apps

Brent Simmons, in his latest blog post talked about how iPad apps could work together, just like on Mac Os, Apple Scripts, services and apple events to allow applications to basically communicate with each others. The funny thing is this is actually possible on iPhone OS, but apparently not popular enough among developers to take advantage of that. This is even quite easy to do, as explained for example here. The idea is that an application can decide to open a URL, using the following method of UIApplication:

- openURL:(NSURL\*) url;

What is even funnier is that this method is the one used to give calls, access maps, open URL in browser etc. The part not very well explored is that any application can register a particular URL scheme so that it can also respond to the above method when called from another application. Brent Simmons thesis is that this technology could be used by applications to become real services that other applications could use. For example, according to him, you can decide to subsribe to a blog via NetNewsWire from a tweet you read in Twitterrific app. All of this looks very nice but what popped up in my mind is that this technology could be used in some major processes. I will only cover one in this post: Authentification

Authentification

With Facebook recent support that they now support OAuth 2.0 and Twitter announce to discontinue Basic Authentification as of June 2010 in order to support only OAuth, it seems that this mode of authentification will be used by more and more apps. For those not familiar with the subject:

Basic Authentification on Twitter:

  • You just give your Twitter username and password to an Tweeter app so that it can access twitter APIs
  • The client will just use them to send GET requests to twitter with your username and password as arguments
  • The limit of this is that you must trust this application (or a web application) to give it your password.

OAuth:

  • When the app tries to connect to Twitter, it sends an access request to twitter
  • The user is sent to "the real twitter" with a message like "this app wants to have access to your Twitter account"
  • Then the user tells twitter that this app is granted access or not to your twitter account
  • Then twitter sends a message back to this app with an access token, in case the users accepts it.
  • The access token is then used by the this app to access twitter, and the user can remove this access directly in twitter if needed
Oauth or similar authentification systems have the great advantage that you don't need to give away your password to any app because twitter is the only access authority.

On iPhone, OAuth is always a bit heavy because of the process itself of 1.connecting to the target site, 2. log in,  3.then grant access or not. For example, facebook has implemented a very nice library that allows any app to access facebook using facebook connect following OAuth scheme. iShareTunes uses this (but also shazam), and it looks like this:

This is a nice solution, especially if you try to achieve this kind of results for Twitter which is much more difficult at the moment. But I see very big disadvantages of this method:

  1. It can very well be falsified so that you think this is facebook but you are actually giving your password to the [malicious] app. Don't forget that this happens within the application and you cannot be sure that the app uses the Facebook code as is.
  2. It is sooooo frustrating to have to type your username password all the time. Keyboard on mobiles are really not comfortable to use, and it is really important to minimize the usage of keyboard input for a user
The solution would be really simple! What if Facebook implemented this inside its own application? The process would them be:
  1. The user clicks on "post to Facebook" for example
  2. If signing in is necessary, the app calls Facebook using a URL scheme and its app_id already registered on Facebook (which is the case today)
  3. The Facebook app launches and asks you to grant or not access to iShareTunes
  4. You don't need to sign in because you already did for the Facebook app ! Only this makes the process mush better in terms of user experience
  5. There is no doubt on the fact that you are actually asked by Facebook to grant access to iShareTunes, which is great.
  6. When you have accepted, Facebook launches iShareTunes with a URL specified in the original call.
All of this is actually not a protocol, it would just be an implementation of current login protocols like OAuth. The only thing facebook would need to do is to wrap this within its Facebook iPhone SDK.

Imagine that this logic could be implemented by major companies, like Facebook, Twitter itself (this can be done using a webapp interface with no problem), and also Google. Personally I am fed up with giving my Google account password to newsrack and Google Docs clients, because I would really not like to have my gmail account hacked. I would prefer having Google managing this using OAuth.

To close this post I will formulate my own wishes regarding this question:

  • Apple should just communicate much more on URL scheme for third part applications, even though it is already in the iPhone Programming Guide. This is actually part of the multitasking story.
  • Facebook, Twitter, Google to implement it ?
  • Why not having a built-in "Apple Connect" available using OAuth (or whatever), so that you don't need to type your passwords all the time, they are just stored once and for all in keychain or more probably in the cloud.

🧑‍💻  I'm Romain, software engineer, ex co-founder and CTO at Yeeld and Eventmaker.

You may be interested in ways I help or simply want to follow me on Twitter / LinkedIn / Github.