Apple Approved iPhone Inter-process Communication

By
On January 27, 2009

Apple is famously restrictive about confining third party apps to their sandboxes. That Apple doesn’t allow background processes is well-known, and Apple rejects apps that attempt to read the various databases and media folders directly.

So it’s a bit surprising that Apple supports a form of inter-process communication (IPC) using URL protocol handlers.

In this post, I’ll show how Alocola — our open source, Apple approved, in the App Store, Safari location helper — uses URL protocol handlers for IPC to work alongside Safari.

How Alocola Works: IPC Using URL Handlers

Alocola registers a protocol handler with the iPhone.

When Safari encounters a URL beginning with alocola:// it issues a call to open the URL, causing Safari to exit.

The system launches Alocola and passes the URL to it. Alocola then gathers the location information and opens an http:// or https:// URL on the originating site, causing Alocola to exit.

The system launches Safari to handle the http:// or https:// URL.

Let’s break this down into pieces and look at how they’re implemented:

Registering A Protocol Handler

iPhone applications store runtime configuration information, including the URL schemes the application handles, in the extensively documented Info.plist file.

Add a CFBundleURLTypes element to the application’s Info.plist to register it as a URL handler for a particular protocol. Xcode makes this easy:

  1. Open the Info.plist file (typically found under the “Resources Folder”) in Xcode.
  2. Select the top-level “Information Property List” element and add a new child-key to by clicking the new child button.
  3. Scroll to the bottom of the drop-down list and select “URL types.”
  4. Enter a unique identifier (e.g., com.mydomain.myprotocol) for the value of the “URL identifier” key.
  5. With “URL identifier” still selected, click the add button and select “URL Schemes” from the resulting list
  6. Enter the protocol name — e.g., http, alocola or, as in the example below, myprotocol — as the value for the “Item 1″ key.
  7. The finished Info.plist looks like this:

That’s all there is to registering a protocol handler. The iPhone will automatically wire up the association when the app in installed.

Handling An Open URL Request

The iPhone OS hands the URL off to an app by sending the – application:handleOpenURL: message to the application’s delegate. I’ll use the Alocola source as an example:

Alocola’s application delegate, AlocolaAppDelegate.m, implements the – application:handleOpenURL: method:

- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
	[viewController handleURL:url];
	return YES;
}

This code is called when the application is launched to handle a URL.

I’m not doing much with the URL in the application delegate except passing it onto a method I’ve defined in my view controller. Alocola is a simple, one-view app with just a few hundred lines of code, so I put nearly all of its functionality into AlocolaViewController.m, its one view controller.

Opening a URL From An Application

Alocola is, as far as I know, the only app that supports a “round trip” from one application to another and then back to the originating application. To support this, Alocola has to open a URL that’ll be handled by the originating application.

The UIApplication class’ openURL method handles opening URLs from an application. Use the [UIApplication sharedApplication] singleton to access the UIApplication.

NSURL *url = [NSURL URLWithString:@"http://www.mobileorchard.com"];
[[UIApplication sharedApplication] openURL:url];

Coming Soon

I’ll be finishing off this series on how Alocola ticks with a post on using the iPhone’s location services.

Also look for a future post on using URL handling to send email and post to Twitter, as well some of the limitations and gotchas of this approach.

  • http://blog.innerfence.com/2009/01/05/2-way-app-integration-on-the-iphone-how-it-works/ Ryan Johnson

    Hey, we’ve been doing the same kind of 2-way communication on the iPhone with Credit Card Terminal. Our scenarios involve communication between two third-party apps (not Safari). We even have some open source code to deal with calling between the apps. So far we have two partner apps in the app store already (Ring It Up and Timewerks) and another one is awaiting approval.

    I’m excited to see others thinking about the same kind of 2-way communication. I think it can really enhance the iPhone platform.

  • Pingback: More on Inter-App Communication on the iPhone

  • http://twitter.com/n_fuhs Norbert Fuhs

    Very interesting article let´s see what Apple itself intends for this…

  • Pingback: iPhone e a nova actualização – Carlos Serrão

  • http://www.NA.com NA

    Umm, guys, that is been in the phone since V1.0. Read the docs.

  • Dan Grigsby

    @NA what’s been in since 1.0? If you mean Safari + location: don’t think so. See http://lists.apple.com/archives/safari-iphone-web-dev/2008/Jun/threads.html#00004 If you mean URL handlers, well of course, but I think you’re missing the point.

  • hkk

    The digg post you guys put up is quite misleading, don’t you think?
    “Great news for iPhone development, as Apple _now_ allows apps to communicate with each other”. Sounds like this is some brand new development. As far as I remember URL handlers have been in the SDK from day 1, no?
    And they are so limited that they are pretty much useless for most purposes. For example there is no way to find out if a certain URL handler is registered (other than trying to call it, which quits the current app).
    Sure, going to and from Mobile Safari works fine. But calling this “inter-process communication” is a bit misleading. I don’t think starting another program after exiting the current one qualifies as IPC.

  • Pingback: iPhone e a nova actualização

  • Pingback: Hello There: A CoreLocation Tutorial

  • Pingback: Lite to Paid iPhone Application Data Migrations with Custom URL Handlers

  • Pingback: links for 2009-11-01 « Blarney Fellow

  • Nick

    Is there a way to track inbound requests where an application uses a registered protocol handler to arrive at your app?

  • Ariel

    Hey guys,
    I was wondering if anyone knows – if an iPhone service is launched from within Safari (i.e. from within a web page) – is there any way to catch an exception on the web page in case the application is not installed?
    For example, if I write an HTML page that tries to invoke the alocola:// URL, but the alocola app is not installed on the iPhone – is there any way (perhaps with javascript) I can catch an exception on the page and display some announcement (or perhaps a link to the app store to download the app)?

    Thanks :-)
    Ariel

  • Jay

    Does anyone have an answer to Ariel’s question? I’m curious about that as well.