Why We Still Need URL Schemes When iOS 8 Brings the Sharing Dialog to Every App?

Good question. Glad you’ve asked.¹ Before I answer this question, let’s back up.

Personally, I love automating my Mac, that’s for sure. And, despite of not posting many articles here about iOS automation, I’m a big fan.

Although, getting to a point where I was comfortable with customizing and enhancing my iOS experience was quite an odyssey. Automation on iOS has come a long way. The road was nothing but rocky… here’s a brief recap of what was and what is to come.

URL Scheme History or What You Should Know About the Dying Breed

You probably aware that apps like Launch Center Pro, Drafts and Mr. Reader provided a variety of ways to send and interact with data. I refer to them as my “hub” for triggering actions or opening other apps. These powerful iOS applications can allow a sort of interaction between apps which wasn’t possible before, c.f. exporting data from the app you’re currently in to another app. All this works thanks to their excellent use of URL schemes.

This was huge in the pre-iOS 8 era because it was a bridge to do more with iOS than what was originally intended and within the limited scope that Apple enforced upon it’s users. In early 2011 one of the pioneers, Greg Pierce, the developer of Drafts invented the x-callback-url protocol and added the necessary base for something that quickly grew over everyones expectations – even Greg’s.

The x-callback-url specification is intended to standardize the use of URLs and registered URL schemes for inter-app communication and messaging on Apple’s iOS platforms.

More and more developers followed and added support for URL schemes to their apps. Depending on the app, integration varied from basics actions like opening an app, up to advanced features with several parameters which users could edit. For example, one of my favorite apps, 1Writer, allows for replacing the content of a document. Another one which is incredibly useful to me is Due.app, a timer and reminder app with an excellent documentation and many parameters to tweak their URL schema.

In the beginning users had to fear that Apple might even take away support for these kind of hacks, but somehow they survived. Apple just silently tolerated them.

The biggest drawback of URL schemes still persists today: ultimately they are just not highly accessible – especially the advanced ones where you chain actions together, which is usually what your after when you trying to automate a task. It takes time and a willingness to learn them and to get it right.

On the educational front, URL scheme evangelist Alex Guyot (who published an insane amount of actions on his soon to be retired blog “The Axx“) wrote a guide to Launch Center Pro for MacStories to explain how to properly encode URL schemes to get them working and do what you want.

Others who publicly made an effort to shared their wisdom about iOS automation are…

• Eric Pramono (@epramono): Productivity and Workflows - Geeks With Juniors
• Phillip Gruneich (@Pgruneich): x-callback-url Library
• Alex Guyot (@the_axx): Unapologetic Automation Archive
• Federico Viticci (@viticci): MacStories – iOS Automation

Those guys aren’t the only ones, but their websites were the ones I most frequently visited when I wanted to learn some advanced automation techniques.

In addition to everything that was already in the App Store, in July 2012 Ole Moritz (@olemoritz) changed the game with the release of Pythonista. Not only did his app support the x-callback-url protocol, the main attraction of his app was providing a complete Python IDE on iOS. Combined with URL schemes this was the next level of iOS automation. If you were fluid in Python, the possibilities on the once restricted platform that iOS is suddenly became a lot less limited. Ole kicked it up a notch and his next app – Editorial, a Markdown editor – followed the same principle featuring a fully fledged Python IDE, but the app introduced another feature: workflows which made chaining different actions together easier then ever before. Later on, followed a UI Editor which allowed users to build own little interfaces on top of Editorial.

Alex Guyot’s FTP Client UI for Editorial

However, let’s head back from Ole’s Python-powered apps to URL schemes. Over the time developers lowered the entry bar and stepped it up, too. For instance Contrast, makers of Launch Center Pro, came up with some nifty solutions. They added special operators which could handle different kind of encodings for the user and a list builder to simplify the process of generating a useful dialog like this…

… which could free up space on you’re Home screen since otherwise you would have these sticking around (instead of storing them in a folder away along with other ‘nice’ apps like Newsstand):

But once you taste blood, you want more. A simple list builder isn’t enough, as you want nested lists. Consequently this means that you still have to do some handwork. Furthermore, regarding the special operators… I haven’t seen many people use them so far. Most users on Twitter seem a bit daunted by them and still encode there Launch Center actions by hand with several layers of percent-encoding, rendering their URL unreadable in the process.

Prime Time

In the past month we passed the peak of URL scheme high point. With well-established apps that provide good documentation of what is possible within their application, like: and a user base that has contributed tons of actions ready to use – even for beginners since most of those actions can be imported with one tab.

• Contrast: Launch Center Pro Documentation
• Launch Center Pro Actions
• Agile Tortoise: Drafts 4 Documentation
• Drafts Action Directory
• omz:software: Pythonista Documentation and Editorial Documentation
• Pythonista Forum
• Editorial Workflow Directory

Some examples of quality documentation and support.

But no matter what… the truth is, even once you get the hang of building your own URL schemes, you still need to do the old trial and error routine from time to time to make an url scheme work because some apps provide functions that can render advanced chains of URLs useless if not treated with care.

In short: iOS automation with URL schemes is still something only an approximately small amount of iOS users is willing to indulge.

As sad as it is, I think the golden age of URL schemes was over the moment Apple introduced its solutions to inter-app communication at the WWDC on June 2th, 2014. It will continue to exist and will have its loyal user-base, but it won’t be the center of attention anymore when it comes to automation.

The Transition

iOS 8 was released on September 17, 2014 and while it’s only on the market for a short period of time, Apple has already put their foot down several times rejecting and removing quite useful and promising apps.

(AP)Prohibition

First, there was the banishment of Launcher from the App Store - a Today view widget in the Notification Center to launch other apps via URL schemes - and second, the rejection of Craig Pearlman (@blackfog)’s Workflows app - a graphical URL workflow builder - which he worked on for more than half a year:

Craig had to find out the hard way that his app conflicts with Apple’s policy of what is allowed and what not. They made changes to the document about 2 years ago defining that new apps² shall not have the sole purpose of launching other apps. Don’t ask me where they draw the line… but it’s a shame. I’d have wished for a peaceful coexistence between powerful apps and Apple’s latest additions to their OS: keyboard extensions, photo editing extensions, lockscreen widgets, the document provider API and the revamped sharing dialog.

Another restriction is that apps aren’t allowed to replicate existing functionalities on iOS. I guess the formulation of the relevant paragraphs is that broad on purpose. It certainly does feel a bit random when apps like Launcher and Workflows happen to meet the exclusion criteria whilst others like Quick-Tap get approved.

But Apple being strict is no news at all. If Apple where my girlfriend, I’d say she got a tad too much control issues. (I think now is the perfect time to throw in a MF Doom quote… it’s either now or never.)

She f***ing with your head and got your heart in a tight curl. MF Doom »Favorite Ladies«

NFC Automation Excursion

With the general train of thought in this article being iOS automation and Apple slowly opening up, I can’t conceal what I would be most exciting about: NFC. More precisely, automation with NFC. Trigger (formerly NFC Task Launcher) from the Google Play Store is the one app in which I envy Android users for years now.

The procedure is the following: you get yourself some stickers (tags) or configure another trigger and configure them to perform certain actions when you tap with your device on the tag. It’s also a bit cheaper than placing iBeacons in your living room and the bedroom.

Sample applications are…

• front-door: leave your home and the Wi-Fi network shuts down
• car: activate bluetooth
• bedroom: activate airplane mode, set volume to 5%, set the brightness to 1%

It would get even better if we can hook up x-callback-url’s with it. Basically you could build an analoge Launch Center Pro for starting Backups, publishing blog post and uploading the last picture in your camera roll³ automatically to your Twitter – you know, the awkward one of you clipping your dogs toe nails wearing a kilt and smiling affectedly.

Of course Trigger has even more features and options than you and I can imagine, we’re iPhone users…. That’s also why the realistic timeframe for such a support would be in 7 years or, more likely, never. In case this would be possible with a trusted Cydia developers app, I’d be tempted to jailbreak again. The last time I did it, was for f.lux.⁴

Here’s a general introduction…

… and a home automation demo:

The Destination

Despite Apple acting arbitrary like with the rejections mentioned above, it is more clear what their motivation is when considering their grand scheme: keeping iOS safe, simple to use and doing this by preserving their own design aesthetic.

It seems Apple wants developers to focus on implementations which take place within their delimited parameter, ultimately making their vision of “iOS as a whole” better. As long as you stay away from the fuzzy lines which mark borders in their policy you’re okay as a developer.

Presumably, some other advantages for customers are that…

• … in case of lockscreen widgets users wont’t solely use their lockscreen instead of the real iOS. Extensions are build to have a short lifecycle;
• … we have found a fix constant in the (outdated) Home screen. It’s the place even grandma got accustomed to and instantly knows her way through. When someone switches from the first iOS version to the latest they still know how to use their phone. After all Apple is prone of being user-friendly. This contributes to it.

With extensions, widgets, the document provider integration and whatnot the new road is paved. So let’s cut the chase:

Why Do We Still Need a URL Schemes When iOS 8 Brings the Sharing Dialog to Every App?

There are advancements in more than one area, but I decided to pick the new sharing dialog as an example. It’s a large piece of the puzzle which went put together, is Apple’s current solution to the problem that inter-app communication was on iOS… and (unlike the document provider API) all your favorite apps already seem to support it.

Coming from zero “automation” this must feel like heaven. Speaking as someone who has a background with a decent set of automation I can say, this was long awaited and it is a fantastic feature.

In brief, things drastically changed for most people. Apart from that, some things won’t change so much for others.

Despite some extensions being valuable additions to my automation and worfklow toolbelt, I still have a good amount of bookmarklets in Safari for apps that have no extension yet or only have simply extensions. My hunch is that I will have to wait quite some time until I can replace these bookmarklets. They give me options to trigger a variety of Launch Center Pro lists acting on a websites title and URL in different ways (which you will hear about soon).⁵

But in all honesty, now that extensions are here, using bookmarklets feels like a workaround. Most times it’s exactly that, an extra step which manifests itself by having to tap the bookmark icon, eventually opening the folder with my bookmarklets, searching for the right own (without any visual aids other than emojis or unicode characters) and then in the final instance touching them to trigger the action. If you have the bookmarks bookmarklet folder always open you can cut a few steps. Still, it’s not ideal, but for power-user stuff this is status quo.

Whereas some workflows remain untouched, others get a breeze of fresh air. Clips.app for instance, a clipboard manager for iOS, is great if you don’t want to send the content far far away but rather act upon it soon. Linky makes sending of web findings to social networks a joy. Lastly, the Drafts extension takes care of the rest. I hope Drafts will be capable to customize the extension with selected Drafts actions soon, then I can get rid of each and every bookmarklet.

In a nutshell and without all the back and forth, the new sharing dialog with extensions and actions is a bliss and I’m certain it will be the biggest part of the future what iOS automation is. The greatest benefit over URL schemes is, that it is available in every application.

The only ones in trouble are apps which use a custom sharing dialog like Mr. Reader, Unread and Riposte. Those apps went the extra mile and created something which was superior to Apple’s outdated approach. Now they are missing out on the increasing availability of new extensions. The latter two apps are both developed by Jared Sinclair (@jaredsinclair) who created the OvershareKit – a custom share sheet - which he developed to provide “better inter-app communication and sharing APIs”. Jared stated that he will not publish any updates, but to make sure that OvershareKit is iOS 8 compatible.

Extensions are Apple’s answer to the problem that OvershareKit was created to solve. It seems to me that it’s better for all involved – both developers and users – for any app that’s using OvershareKit to migrate to Extensions and the UIActivity frameworks. … Evernote has a rich and complicated API. It doesn’t make sense for outside developers like me to spend limited resources building support for Evernote. Jared Sinclair

Ditching ones own creation is hard, maybe too hard. I hope Oliver Fürniß (@curioustimes) from CuriousTimes finds a better way for his Mr. Reader. I will share with you what such a way could look like this week. Until then, lets take the shortcut to the finish line of this article.

To conclude, for the way I work within iOS, the current state of inter-app communication is superb, but not sufficient for my particular needs. The best solution for power-users are the kind of apps we will hopefully see more more of in the future. Those which will function as a bridge between the x-callback-url protocol and existing native integrations. This way we can use the best of both worlds.

I depend on hubs – be it Launch Center Pro or Drafts, both are in my 3-app dock on the iPhone and provide the convenience I seek for to send files to remote locations, to launch a set of actions or provide me with a menu of different choices when I’m not yet decided where to put the data in question. Powerful and versatile apps will always have a place on my phone and I’m still glad if a developer add support for url schemes. X-callback-url apps are not dying, they are just getting old like the rest of us. Let’s grow old in dignity together.