Apple Approved iPhone Inter-process Communication

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 https:// or https:// URL on the originating site, causing Alocola to exit.

The system launches Safari to handle the https:// 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 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 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:@"https://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.