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.
Speaking of Greg Pierce, I'm intrigued by the workaround he found to mimic support for x-callback-url in Safari for iOS:
For those not familiar, it is possible to use x-callback-url support in Google Chrome on iOS to open a URL from another app, and have Chrome present a “Back” button to return to the app you opened the URL from. Safari does not offer this level of integration.
Here's what I did: I downloaded Greg's HTML file on my Mac, put it in my Public folder in Dropbox, and got the direct link that can be accessed by any web browser. With that, I edited the Drafts action Greg made and now I have a custom “callback page” that I can integrate with Safari and actions from Drafts, Launch Center Pro, Editorial, or Mr. Reader. I'm thinking of how I could take advantage of this solution in my workflows – the nice part: you can navigate across pages inside the frame – but I believe I will mostly use it to quickly check a webpage in Safari and go back to the previous app quickly.
It's an interesting workaround, but still a hack. For instance, it's not possible to dynamically generate a callback address from the address that's currently loaded in the frame. Still, if you want to put together a basic alternative to Chrome's excellent x-callback-URL support, check it out.