When iOS 8 came out, I thought I'd stop using URL schemes altogether. Until two years ago1, my attempts at working on iOS had focused on overcoming the lack of inter-app communication with URL scheme automation, as our old coverage here at MacStories can attest. iOS 8 showed a new way to get things done on the iPhone and iPad thanks to extensions, eschewing the limited functionality (and security concerns) of URL schemes for a native, integrated foundation.
Two years later, I've largely reappraised my usage of URL schemes, but, unlike I first imagined, they haven't disappeared completely from my iOS computing life. iOS automation has taken on a different form since 2014: thanks to its action extension, Workflow has brought deeply integrated automation to every app, while Pythonista remains the most powerful environment for those who prefer to dabble with Python scripting and advanced tasks (also while taking advantage of an action extension to be activated from apps).
Today, URL schemes are being used by developers and users who want to go beyond the limitations of system extensions: apps like Drafts and Workflow use URL schemes to invoke specific apps directly (which extensions can't do – see Airmail and its custom app actions) and to link more complex chains of automated actions. URL schemes are also the best way to set up templates and import workflows for dedicated functionalities – a good example being The Omni Group with their latest automation options for template generation in OmniFocus.
While Apple's goal with iOS 8 might have been to "kill" URL schemes by turning them into a niche technology mostly supplanted by extensions, that niche has continued to quietly thrive. iOS automation is drastically better (and more secure) today because of extensions, but, for many, URL schemes still are the backbone of app shortcuts and complex workflows. Where extensions can't go, there's a good chance a URL scheme will do the trick.
It's in this modern iOS automation landscape that Launcher, first released in 2014, is graduating to version 2.0 with a focus on what it does best: standalone app shortcuts. Launcher 2.0 offers more control than its predecessor over widget customization and activation, with new features and settings that have pushed me to reconsider how I use Notification Center widgets on both my iPhone and iPad Pro.
Agile Tortoise's Greg Pierce has an explanation of the changes coming to iOS 9 for apps that want to launch URL schemes:
There are two URL-related methods available to apps on iOS that are effected: canOpenURL and openURL. These are not new methods and the methods themselves are not changing. As you might expect from the names, “canOpenURL” returns a yes or no answer after checking if there is any apps installed on the device that know how to handle a given URL. “openURL” is used to actually launch the URL, which will typically leave the app and open the URL in another app.
Up until iOS 9, apps have been able to call these methods on any arbitrary URLs. Starting on iOS 9, apps will have to declare what URL schemes they would like to be able to check for and open in the configuration files of the app as it is submitted to Apple. This is essentially a whitelist that can only be changed or added to by submitting an update to Apple. It appears that certain common URLs handled by system apps, like “http”, “https”, do not need to be explicitly whitelisted.
In short, Apple wants to prevent apps from being able to scan a user's device and know which apps are installed. Notably, this change comes a few months after Twitter started scanning user devices to see installed apps and deliver “a more personal Twitter experience”.
As Greg notes, Apple is doing this to protect customers' privacy. Companies like Twitter had found a loophole to gather data about user devices that iOS doesn't normally expose, and it makes sense for Apple to prevent this from happening in the future. The problem is that this system based on whitelists and limited number of URLs could be a serious threat to automation apps like Launch Center Pro and Launcher, which depend on launching any URL.
Since last year, various iOS teams have made an effort to obviate the need for URL schemes through extensions. This year, they're going one step further. I agree with the underlying privacy concerns and I also believe that more developers should embrace extensions – how ironic that Twitter still doesn't support them and they're likely causing this change – but it's important to note that some automation apps are based on the idea of launching URLs, not showing share sheets for extensions.
As Greg notes, there's some confusion in this first beta of iOS 9. Hopefully Apple and developers will be able to work out a decent compromise by the final release.
I recently tweeted about a change in the Spotify app for iOS – which I've been using to listen to music every day1 – that broke my shortcut to search for songs and artists from my Launch Center Pro action grid. I've been trying to identify the culprit and I've read documentation about Spotify's URL scheme and integration with the web app, but I haven't been able to figure out how to make searches typed in Launch Center Pro work with Spotify again. Therefore, I've tweaked my Spotify action setup and settled on a compromise that's (kind of) working for now.
My Launch Center Pro home screen and Utilities folder.
Earlier this month, I wrote that Launch Center Pro 2.3 extended iOS automation by integrating with IFTTT and bridging the gap between iOS apps and web services. Launch Center Pro 2.3.1, released today and seemingly a minor update, is packed with major changes for advanced users who want to build complex URL actions in the app.
If you’ve struggled to build actions that connect multiple apps in Launch Center Pro before, you’ll want to check out the new version and read through the full documentation on Contrast’s website. We’re still working on a big update to our Launch Center Pro guide, but, in the meantime, I’m going to give you an overview of what’s possible to achieve with Launch Center Pro 2.3.1.
Released today on the App Store, Launch Center Pro 2.3 is a major update to Contrast's app launcher and automation tool for iOS that further enhances integration with online services, improves how actions are built and triggered, and that refines several aspects of an app that's become a key piece of my workflow.
I've been covering Launch Center Pro since its humble Pro-less beginnings, and the app has changed dramatically over the years. What started as a simple launcher for apps graduated into a full-blown automation utility for URL schemes and native iOS features, which allowed us to create a complete guide to get started with the app on your iPhone and iPad.1
Launch Center Pro 2.3 brings important improvements that make the app an even better companion for common tasks and advanced workflows. The update is packed with features -- David Barnard wasn't joking when he said that it feels like a 3.0 release -- and I believe that Contrast did a great job in integrating them with the rest of the app.
In my review of Editorial 1.1, I covered the app's new support for x-callback-url and how it improves inter-app communication. In hindsight, I left out a fairly obvious demonstration of the feature: the possibility to create workflows that send multiple items in a row to other apps. For this post, I'm going to use Fantastical as an example.
Developed by Samir Ghobril, Mingle for iPhone combines aspects of the iOS Contacts app and action launchers such as Drafts and Launch Center Pro to let you quickly launch actions for individual contacts through a swipe gesture.
When I'm writing on my iPad at home, there's a chance I have my MacBook on my desk with either iTunes open (to check for app updates or playing music from iTunes Match/Radio) or MailMate running (because I've been having issues with Mail on the beta of iOS 7.1). It's not uncommon for me to use a dual-monitor setup when writing, relying on my MacBook for Google searches and other reference material – effectively, I use it as a secondary display to my iPad when I'm working on articles that require a fair amount of research.
Since the release of Command-C, I've been using Danilo Torrisi's utility to quickly beam text and URLs across all my devices, using Launch Center Pro actions to speed up the process. Command-C has excellent support for URL schemes – a boon to iPad users who fiddle with automation tricks to save time when working on iOS. I recently realized, however, that most of the content I share with Command-C is made of URLs from Safari, therefore I asked myself whether I could put together a solution to send URLs with one click from Safari without using an external app or keyboard shortcut. It was pretty clear from the beginning that I would end up with a bookmarklet, but I have to thank Danilo for providing the necessary guidance I needed to achieve the kind of workflow I wanted.
The bookmarklet is part made for myself, part proof of concept (as always) for others to iterate upon. It doesn't only send URLs from Safari on another device with Command-C – it sends the webpage you're currently viewing in Safari to another app on another device with Command-C.
Joseph Schmitt, writing in response to Greg Pierce's hack to simulate x-callback-url support in Chrome:
However, Greg's technique depends on loading a full-screen iframe on the page and overlaying a back button on top to trigger the x-success url. That gets the job done, but I really prefer how Chrome handles this: make the last page jump to the previous app. I brainstormed for a bit and figured I could probably replicate Chrome's behavior's using Greg's idea, and I was right: xsuc.es was born.
To build actions with xsuc.es, see the URL parameters in Joseph's blog post. The format is easy to understand if you're already familiar with URL schemes; here's a demo action to launch a Google search in Safari based on xsuc.es from Launch Center Pro.