2-way app integration on the iPhone: How it works
January 5th, 2009 by RyanI’m really excited about the recently announced integration between our Credit Card Terminal app and PingySoft’s RingItUp Point of Sale app.
I suspect that other apps will want to provide similar integration. Just last week, Erica Sadun was talking about what she called “Bridging Functions” on Ars. That’s what I’m talking about here.
The URL Handler for Twitteriffic was the first thing Craig Hockenberry posted about after the NDA went away. Such URL handlers are a good sign that the community wants to expose app functionality in a reusable way, but they only solve half the problem since the user is stranded in the new app. Who wants to tap the home screen, find the original app, and navigate back to the right place?
Speaking of Twitteriffic, have you noticed how many iPhone apps have their own ad-hoc web browser built-in instead of using Safari? It’s because calling into Safari leaves the user stranded. We need an experience like playing a video from Safari. The video launches like a separate app, but there’s a Done button to return to what I was doing.
The basic idea, to quote my abstract algebra prof (sorry, Dr. Sherman!), is “Go somewhere; do something; come back.” The more apps that provide this kind of integration, the richer the iPhone platform will be.
Thankfully, since Apple has provided an underlying URL-based method for applications to communicate with each other, we can use existing techniques from the web space to accomplish our aim. Two apps can pass control between each other fairly easily when both are registered to handle a URL scheme in their Info.plist.
So here’s how the Credit Card Terminal / RingItUp integration works (video):
1. App A invokes a URL for App B, including a returnURL parameter that acts as a “continuation”
When you tap “Accept Credit Card Payment” in RingItUp, it crafts a URL for Credit Card Terminal. This is the familiar URL handler pattern that Craig talked about on his blog. You can specify various parameters on the query string and Credit Card Terminal will pre-fill those values.
The trick here is that RingItUp also includes a returnURL parameter so that Credit Card Terminal knows how to come back when the Credit Card Processing is done. The returnURL contains all the information RingItUp needs to bring the user back to the same place they started. In RingItUp’s case, this is as simple as including a record_id parameter. But you could imagine an arbitrarily complex “continuation” encoded in the URL.
→ com-innerfence-ccterminal://charge/1.0.0/?invoiceNumber=123&returnURL=my-return-url%3A%2F%2F%3Frecord_id%3D123
2. When App B is done, it invokes the returnURL from App A, including any additional info
When you tap “Return to RingItUp” in Credit Card Terminal, it invokes the returnURL from the request, tacks on some additional return parameters that indicate whether the charge was approved (the return parameters are prefixed with ifcc_ to avoid collisions).
→ my-return-url://?record_id=123&ifcc_responseType=declined
3. App A handles the returnURL, restoring the “continuation”
When RingItUp re-launches, it loads the correct record using the record_id parameter, then stores information about the credit transaction in the Notes field for that record.
I would be remiss if I failed to point out the security implications here. By registering to handle a URL scheme, an iPhone app becomes a de facto web app, subject to many of the nasty attacks that work on the web. Apps implementing this scheme must be careful to validate any parameters they get from the URL lest they be vulnerable to old friends like SQL injection. Another one to be careful of is unsolicited response attacks. The calling app should store a nonce value which it includes in the returnURL and reject any response with the incorrect nonce (similar to CSRF mitigation on the web).
Due to the security issues, as well as the sometimes tricky matter of properly encoding query string parameters, we’ve chosen to provide Objective-C classes for submitting the request and parsing the response when interacting with Credit Card Terminal. These are MIT Licensed, and we’d be very happy to see other app developers use them as templates for their own integration offerings.
What other apps would you like to see support 2-way integration? I’d love to see one of the twitter apps do it. That way I could expose the ability to send a quick tweet from my app without worrying about stranding the user and without writing against the twitter API directly. Which is a relief, because I certainly don’t want to be in the business of collecting people’s twitter passwords right now. :-)
Update: Of course, since iPhone apps are generally servicing one user, the easiest way to deal with the continuation problem is just to save what you need to NSUserDefaults.
Tags: 2-way integration, Credit Card Terminal, iphone, url handler
January 5th, 2009 at 6:23 pm
Thanks for releasing the code!
This idea is a cool workaround for a shortcoming of the iPhone. It’s a far cry from Android’s Intents which allow apps to use the services of one another and can all be running at once - without letting the other app take over the screen - to really build on-device mashups. As more Android devices and a pay-per-app marketplace are launched, I suspect we will start to see some really cool component-based applications.
January 6th, 2009 at 7:02 am
[…] from Innerface have posted source code for the scheme, but they note a few security […]
January 6th, 2009 at 10:35 pm
[…] from Innerface have posted source code for the scheme, but they note a few security […]
January 22nd, 2009 at 8:10 am
[…] is one of the first iphone apps to provide a return path when it is invoked. See this post on their blog for more details and some security […]
January 28th, 2009 at 12:55 pm
[…] iPhone app. Shortly thereafter, Ryan Johnson of InnerFence commented that they’ve been doing the same for a while with their own […]
February 6th, 2009 at 5:48 pm
I built a scheme similar to this for my apps.
I also include a digital signature in the URL to authenticate the sender and the UUID of the device.
Also the iPhone will display a different Default.png startup screen from the app bundle depending on the URL handler used to invoke the application. That can be used for some interesting tricks perhaps to provide feedback to the user.
February 25th, 2009 at 10:53 pm
[…] Here’s a writeup from the people who integrated a credit card app and a point of sale app. […]
March 28th, 2010 at 7:56 am
[…] Apple’s own applications which are available as frameworks. Some developers have managed to enable inter application communication using custom URL registrations like Innerfence and their Credit Card Terminal application, but that definitely is a hack. In the […]