A call to iOS Twitter client developers!

With Instapaper’s x-callback-url support available, I hope people will start to see some of the cool possibilities for more complex handoffs between iOS apps. The next big thing I’d really like to see is for Twitter clients to extend their URL schemes to support x-callback-url, particularly to allow the user to jump over to post a tweet, and then be returned to what they were doing in their original app.

Most of the major iOS Twitter clients already support incoming URLs for status updates. For example, if you want to send a status update to Twitteriffic, just call:

twitterrific://post?message=Message%20Text

For Twitter:

twitter://post?message=Message%20Text

This is strictly a one-way call, however. Why not use x-callback-url to allow passing a return callback for after the user edits and sends the tweet. For example:

[targetAppScheme]://x-callback-url/post?message=Message&
  x-source=[SourceAppName]&
  x-success=[sourceAppScheme]://x-callback-url/tweetPosted

NOTE: arguments should be URL encoded, but were not for legibility.

This could work very much like the existing support in the Twitter app, opening the compose window with the text pre-entered — but after the user taps “Send” and the tweet is successfully posted, fire the callback URL and return the user to where they started.

With this sort of support available, it would be easy for apps to add “Share” functionality that lets their user take advantage of the accounts their users already have setup in their Twitter client, along with all the great composing tools, without forcing the user having leave their app with no clear way back.

If you think this is a cool idea, contact the developer of your favorite Twitter client and let them know. And tell them we’d be happy to help with testing!

x-callback-url DRAFT, revision 1

Revision 1 of the x-callback-url draft is now posted.  Only a minor change, removing the “version” parameter from the URL path.  It was pointed out that having the version in the path served little purpose since a calling app had no way to determine which versions were or were not supported by a target app.

We are now recommending that if your x-callback-url API requires versioning, that it be done by registering different URL schemes with the iOS for each version and handling that internally. The example app on Github has been updated to reflect the change as well.