Note: The following is a complete update of our original Launch Center Pro guide published in April 2014. It has been rewritten and updated for the latest 2.3 and 2.3.1 versions of Launch Center Pro with new sections, actions, videos, and more.

Released in December of 2011, Launch Center (the predecessor to Launch Center Pro) was one of the first apps to put the spotlight on URL schemes and actions. Promising the ability to launch “actions” instead of just apps, Launch Center leveraged URL actions to minimize the number of taps it took to complete common tasks on a variety of iOS apps.

In those days, URL schemes were a fairly obscure facet of iOS, and few apps supported them. App Cubby (the developers of Launch Center and Launch Center Pro, now known as Contrast) wanted to change that. With Launch Center 1.2, they introduced the “Supported Apps” list: a list of apps supporting URL schemes with quick links to load actions from those schemes into Launch Center.

A few months later, in June of 2012, App Cubby released Launch Center Pro. The evolution of Launch Center, Launch Center Pro substituted the old list view for a 3x4 grid of large, easily tappable actions.

Where Launch Center had clearly been a utility, Launch Center Pro was a second home screen. Tapping icons in a grid is natural to every iOS user, and LCP took advantage of that to feel instantly familiar. As the slick new app made waves in the tech community, awareness and support of URL schemes began to grow. Launch Center Pro was the spark that would ignite the fire for URL schemes and iOS automation.

In the following months the iOS automation landscape grew as new players entered. Pythonista brought powerful Python scripting to iOS, and Greg Pierce’s x-callback-url specification was gaining steam among third-party apps. In January, 2013, Pierce released Drafts 2.5 (Drafts for iPad 1.5), adding custom URL actions via an action menu and powerful support for x-callback-url. This placed Drafts among the front runners for the most powerful iOS automation and inter-app communication possible on iOS. The rest of 2013 would not slow down the pace. Drafts, Launch Center Pro, and Pythonista continued to iterate and improve.

August 2013 brought Editorial, a new app by the same developer behind Pythonista, which revolutionized the field all over again. Not to be defeated, Agile Tortoise answered with Drafts 3.5, and App Cubby became Contrast as they released Launch Center Pro 2.0 and (soon after) Launch Center Pro for iPad. In May of 2014, Editorial 1.1 made waves once again, and was quickly followed by the huge Launch Center Pro 2.3 update (more on that later). Right now we have the next update to Drafts to look forward to, hopefully including the intriguing new action builder Greg Pierce has teased on Twitter.

Watching these developers fight it out has been an awesome experience. The intense, unceasing competition has brought iOS automation incredibly far in a ridiculously short amount of time. The power of these apps, the increasing support of URL schemes from third party developers and the attention from many independent websites such as MacStories, Unapologetic (my personal website), Geeks With Juniors, I Miss My Mac and many others which latched onto the idea and fostered it in the early days, have grown the field from a ridiculed thought (no one can do real work on an iPad!) to a subject often discussed in the tech press. Moreover, after this year’s WWDC, the new Extensions coming in iOS 8 could redefine the field once again, and I can’t wait to see how these developers will evolve their apps to compete in this impending new era of iOS automation.

Today, Launch Center Pro (or “LCP”) has come incredibly far from its rudimentary beginnings. Once a simple app launcher held back by the lack of support for more advanced actions from third party developers, the expanding interest in URL schemes have let Contrast focus on beefing up LCP’s internal functionalities. While on the surface it looks deceptively simple, and no more than a reskin of its original design from June 2012, 2014’s Launch Center Pro is brimming with hidden power and advanced capabilities.

Since no single resource has previously existed to bring you up to speed from a total beginner to a Launch Center Pro power user, my goal is to provide one for you here. Whether you had never even heard of Launch Center Pro until reading this, or you’re a seasoned veteran of the app, this article will familiarize you with LCP’s full feature set.

Download Launch Center Pro

Table of Contents

URL Schemes and Actions

Launch Center Pro and Drafts, the automation app with the most similar feature set, both seem to have fairly simple visions. Drafts seeks to be the central place for text input and output on your iOS device. If you want to type something up and are going to send it somewhere, be that Dropbox, Evernote, email, iMessage, a social network or any one of many third-party apps, you start with Drafts.

Launch Center Pro (left) and Drafts (right).

Launch Center Pro seeks to be like a speed dial for the common tasks you perform on your iOS devices. If you want to launch an app and immediately perform some sort of basic function within it, there’s a good chance Launch Center Pro can help you achieve that task quicker and with fewer taps. While these visions may seem separate, there is a key concept in the way in which they are each achieved that leaves them deeply intertwined: URL schemes.

I’ve already written extensively about URL schemes in my guide to URL schemes and Drafts actions, and if you’re unsure about what URL schemes are or how they work then I encourage you to read through that before going into the more advanced sections of this guide. Regardless, I’ll give a quick overview here, as understanding the concept is key.

On iOS, Apple has implemented a method of security known as “sandboxing”. Each and every iOS app lives in its own “sandboxed” environment. Apps cannot reach outside of their sandboxes and into others to send or receive information from one another. This feature is good for security, as it’s impossible for malicious apps which might slip through the App Store review process to spread harmful files or steal or track data from other apps.

However, in regard to automation, sandboxing means that even well-intentioned apps cannot send and receive good files or pass commands back and forth to collaborate and make use of their individual strengths. This would make automation of tasks between more than a single app almost impossible, but thankfully we were left with a few small loopholes which clever developers have learned to work with.

There are two official ways for iOS apps to communicate with each other: the “Open In” menu, and URL schemes. The Open In menu simply duplicates files from one app’s sandbox into another’s, and in general is not very helpful for automation purposes. That leaves the second way to escape the sandbox: URL schemes.

URL schemes are foundations that can be built into apps which allow the app to be launched, and often various functions within it to be triggered, automatically via URLs. These URLs look very similar to the standard URLs which everyone who has used a web browser understands, except they start with an app name instead of “http”. So instead of launching a website by typing “http://” into your browser, you could launch, say, Drafts by typing “drafts://” into the browser.

Every app has a unique scheme, so Launch Center Pro is launched by “launchpro://”, Tweetbot by “tweetbot://”, etc. By adding more onto the end of the URL, you can move further into the foundation that developers have built into their apps, launching into specific windows or calling specific functions. In Tweetbot, for instance, you can call “tweetbot://compose” to launch Tweetbot and be immediately taken to the compose view to type a tweet. If you pass text in with the URL, such as “tweetbot://compose?text=Hello%20World”, you will launch Tweetbot into the compose view and it will be automatically filled with the text “Hello World” (in the URL the text has to be percent encoded, but the app will decode this when it receives the text). This works because Tweetbot’s URL scheme has been set up such that “/compose” is mapped to the compose view. Adding “/compose” to any other app’s URL will likely do nothing, because every URL scheme is different depending on how the developer decided to build it.

So URL schemes and URL “actions”, as the actual URLs which launch apps and call functions are referred to as, can save you a lot of time by skipping unnecessary taps through complex app hierarchies. This is powerful on its own, but it wasn’t enough for Greg Pierce, the developer of Drafts. Pierce created the protocol known as x-callback-url, which allows you to add parameters into your URL actions that launch a second URL action after the first is successfully completed. This means that we can chain together multiple URL actions to build complex automated workflows, all using the simple plain text URLs which can slip beneath the iOS sandbox barrier.

Drafts and Launch Center Pro

As stated before, the backbones of both Drafts and Launch Center Pro are URL schemes. Or more specifically, URL actions which utilize the URL schemes built into hundreds of third party apps, and even some first party Apple apps.

Drafts has a specialized “action list”, which is basically a long list of custom URL actions which you can launch to send the text you’ve written in a draft to… well, almost anywhere. Since you build most of the URL actions in your Drafts action list yourself, you can make use of Drafts’ powerful variable tags to send all of your text, or only specific lines or sections, to any app or service that is supported by Drafts or has implemented a URL scheme.

Launch Center Pro, however, is different. Where Drafts is focused on text and uses URL actions as an optional supplement to the text input functionality, Launch Center Pro is focused on actions and uses text as an optional supplement. Due to this, instead of Launch Center Pro opening to a text input field and requiring extra taps to run actions on it, it opens to a grid of actions, and depending on the action you choose to run you may or may not be required to type text into an input prompt before it is launched. This fundamental difference is the main separator between Drafts and Launch Center Pro, and this is why both apps fit together and can be used in tandem rather than requiring you to pick a favorite and only use that one.

While Launch Center Pro may have a fairly simple vision, and does its best to be accessible to everyone, URL schemes are by no means simple, and thus, most apps which revolve around them become complex by default. The goal of this article is to get you comfortable with that complexity.

Before we begin, I’ll reiterate once more that if you’re still completely confused by URL schemes after that basic overview, I highly recommend you take the time to read my afore-linked guide to URL schemes and Drafts actions before jumping into this, as all higher level Launch Center Pro functionalities will be far easier to comprehend if you understand the URL actions that they’re built upon.

If you’re confident in your knowledge of URL actions, or if you only want to take LCP to a beginner level and just learn the basic functionality for now, then read on: here’s my comprehensive guide to Launch Center Pro.

The Basics

The first time you open Launch Center Pro, you’ll see an introduction screen consisting of three cards. The first of these describes Launch Center Pro “Actions” as “one-tap shortcuts to quickly perform everyday tasks.” This, in essence, is what Launch Center Pro is all about. The app probably won’t help you do anything that you can’t already do manually, but rather, its core functionality is reducing the time it takes for your most common tasks. After a little preliminary setup, Launch Center Pro centralizes the starting point for your daily workflows, reducing friction and increasing efficiency.

After dismissing the introduction, you will see the Launch Center Pro home screen. This is a three-by-five (four-by-six on iPads and three-by-four on 3.5 inch screened iPhones) grid of rectangles, and the central UI element for the entire app. Within each box on the grid is an icon, and beneath each icon is a description.

There are only two possible types of grid items: actions and groups. Action icons are familiar rounded rectangles, and can be app icons, custom color/icon combinations, photos, or web clips. Every “action” has a URL action attached to it, and tapping the action’s icon in the grid will cause its URL action to be triggered. Group icons are white circles with grey borders and thin, iOS 7-inspired grey icons inside of them. Groups are basically folders filled with more actions. Tapping and holding on one will open it, replacing the actions and groups on the main grid with actions you have placed in the group. To launch one of these actions, simply drag your finger from the group icon across the grid to the action you want to run, then let go. If you let go while your finger is still hovering on the group’s icon, the group will close and the main grid will be restored. This method of interaction is what makes Launch Center Pro such an excellent app.

If you want to launch an action, no matter where the action is, you can get to it by either a single tap, or a tap-swipe. That’s a maximum of two hundred and ten completely different actions, all accessible from the same place without lifting your finger twice.

If this is your first time opening Launch Center Pro, your grid will be pre-populated with default actions and groups. You can play around with these if you’d like, but generally you’ll want to customize your LCP home screen entirely for you, so feel free to delete them all immediately. You can also pick a different theme for your grid if you don’t like the default white theme. Dark and Classic themes are available in the settings pane (found in the top left corner of the LCP main screen).

All adding, deleting, and moving of actions is done by tapping the small pencil icon in the top right corner of the app. This puts your grid into edit mode, where every action and group gets a small “x” button on its top left corner, and every unused box gets a large plus button directly in the center. You can tap the “x” buttons to delete actions or groups (be careful deleting groups, as every action inside of them will also be deleted), or tap the plus buttons to add new ones. While in edit mode you can also drag actions or groups around to rearrange your grid.

If you tap a group while in edit mode, it will open, changing the grid view to display the grid of actions for that group. This sub-grid can be edited and manipulated in the same way as the main grid, but any new actions added from this view will only appear when you tap and slide from the group’s icon.

Furthermore, since Launch Center Pro only supports going one group deep, you cannot create a group within a group, and the plus button in a sub-grid immediately creates a new action instead of prompting you to choose either an action or a group. When editing a group’s grid, the “x” button on the group’s icon turns into a small “i”, and you can also tap that to change the name or the icon for the group, or delete it entirely. To return to editing the main grid, just tap the group icon again to close it.

The final aspect of edit mode is editing your actual actions, which can be done by simply tapping the square for any action on the main grid or in the sub-grid of a group. This opens the action editor (also opened when tapping the plus button and choosing to create an action), which is the place you will go to add or edit every action you ever create in Launch Center Pro.

The Action Editor

The action editor window slides up from the bottom of the screen when you choose to add or edit an action. The editor consists of nine rows (ten if you are editing an existing action, as it adds another button at the bottom to delete the action), the first two are for the name and URL of your action. These two rows are editable text fields, and tapping in them will allow you to manually type a name and a custom URL action. This is very important for getting a more advanced functionality out of Launch Center Pro, but many basic actions are available without being typed manually. These preexisting actions are accessed from the “Action Composer”, the button in the third row of the action editor.

The Action Composer

The Action Composer is one of the most impressive parts of Launch Center Pro. The guys at Contrast have pursued the arduous task of manually building a huge library of URL actions for hundreds of different apps. The entire library is available via the Action Composer, where it is broken down into six different sections.

The first option, “System Actions”, displays a list of actions which are either Launch Center Pro specific actions, or iOS system level actions not necessarily tied to a particular app.

The second option, “Installed Apps”, lists every action from the Launch Center Pro action library for which the corresponding app is installed on your device. These first two sections will likely be the ones you use the most, but the last four can be useful as well. The “All Supported Apps” section is a great place to go if you want to check out the URL scheme for an app you have heard about or are considering downloading.

Since this library has been built manually, you should take the absence of your app being listed with a grain of salt, as it could just mean that the Contrast developers haven’t gotten around to adding it or haven’t yet heard about it. If your app is available though, it can be useful to view its section in the Action Composer and see whether it includes a variety of different actions, signifying a powerful scheme. Once again though, sometimes apps are added with their basic launch URL but without some of their more advanced action capabilities.

The “Featured Apps” section is a great place to look if you’re trying to find some great new apps. Apps in here are generally pretty high caliber, and all of them have some sort of URL scheme.

The “Featured Actions” section is new in LCP 2.3, and includes a list of actions which Contrast has deemed interesting enough to feature more prominently. These are generally more complicated actions which would require advanced knowledge of the app for users to make on their own. As of now this list is pretty small; perhaps in the hustle to get 2.3 out the door Contrast forgot to fill this list with more actions, so I’m hoping it gets more attention soon. I would also love to see an option somewhere in the app to submit actions to Contrast for consideration of being added to the list. A feature like that could give more people greater incentive to make cool actions, as well as creating a central place for others to find these actions. Both of those would be huge benefits to all Launch Center Pro users. If Contrast made more use of this section, and curated it with powerful actions submitted from many different users, I could see this becoming one of the most used sections in the Action Composer.

Finally, the “Recently Added” section is composed of the most recent additions to the action library. I have never found this section to be of great use, but maybe you will find a reason to utilize it.

In any of the last three sections, if you see an app in the list that you don’t have installed, but would like to download, you can tap the download icon on the right side of every app to be redirected to the App Store page to download it.

Within the Action Composer, tapping any of the section buttons will slide the Composer to the left to reveal a list of available apps (the one exception being the System Actions section, which just displays a list of actions since they are not tied to apps). Tap an app to see a list of supported actions for it. From there you can tap any of the actions to choose one of them to be sent to the action editor.

Many of these actions have options for customization, while others are more simple. Flashlight, for instance, found in System Actions, has no need to be customized, so choosing the Flashlight action will immediately dismiss the Action Composer and return you to the main action editor. After choosing an action, the name and URL will be automatically filled into the action editor’s “Name” and “URL” rows. In this case, the name would be “Flashlight” and the URL would be launch://light . If you were to pick a different action, such as Bookmark, you would be directed to another pane to fill in the Name and website URL for the website to open. After entering those and pressing done, the Action Composer would auto-fill the top two sections of your new action in the editor with the given name and website URL.

Everything done in the Action Composer can be done manually by typing the URL actions yourself, but the function of the Composer is to stop you from needing to remember the URL schemes of every app on your iOS device. Since this is the largest, most accessible and best organized library of URL actions that I am aware of, I have found it useful even when building actions for Drafts or Editorial, as I can consult Launch Center Pro’s library any time I want to remember the scheme or syntax of a particular app that I am using in a workflow.

Keyboard Prompts and Other Variables

When customizing actions in Launch Center Pro, be it within the options of an action in the Action Composer, or while manually editing a URL in the main editor, an extra row of icons will appear at the top of your keyboard. The first is the keyboard prompt icon, and tapping it will pop up a list with three options: Keyboard Prompt, Number Pad, and List 1. We’ll get to List later, but if you choose one of the first two options, you will be faced with that type of keyboard and a prompt box each time you run your action. Whatever text you type into the box will be automatically encoded and inserted into the URL action before it is launched.

As discussed at the beginning, Launch Center Pro is an action based application instead of a text based one, so you don’t get presented with a text box unless you ask for it. Keyboard prompts are the way you ask for it. Any action that you want to send text through requires you to either hard code text into it (very limited use cases there), or use a keyboard prompt.

Whichever type of prompt you choose will cause some text wrapped in square brackets to be placed in your action URL. This will be in the format of [keyboard-type:prompt-title] , where “keyboard-type” is the option you chose from the list (for the system keyboard this will simply be “prompt”, for number pad it will be “prompt-num”. Other hidden special keyboards will be discussed later on, and each has its own identifying string as well.) and “prompt-title” is a title to display at the top of the prompt box that will appear each time you run the action.

Here’s an example of putting all of this together. If you wanted to build an action which uses Launch Center Pro’s in-app messaging actions to send a message, you would tap the pencil button to enter edit mode, find an empty slot in your action grid where you want the action to be placed, tap the plus button in this empty slot to bring up the action editor, tap the “Action Composer” button in the third row, choose “System Actions” in the Action Composer, choose “In-App Messaging” from the list of available actions, and finally tap “Send Message to Group” from the list of action options.

This will bring up a menu with three text boxes for you to fill in. The first is a title, which you can leave as the default “Send Message”, or change to anything you desire. The second text box can optionally be filled in to choose a certain contact or group of contacts for the message to be sent to. If you want to choose who to send it to by yourself each time you run the action, leave this box blank. The final option is for the Body of your text, and tapping this field will bring up the keyboard with the custom icon row at the top. Tap the first icon and choose “Keyboard Prompt”. This will place the text [prompt:Body] in the third text box. Now tap done.

Back in the action editor, the name of your action has now been changed to “Send Message” (unless you picked a different name), and the URL for the action will be this: launch://messaging?body=[prompt:Body] .

Here’s a quick breakdown of the action:

launch:// is the top level of the URL scheme for Launch Center Pro. In-app messaging is a built in action, so Launch Center Pro is going to start by calling itself.

is the top level of the URL scheme for Launch Center Pro. In-app messaging is a built in action, so Launch Center Pro is going to start by calling itself. messaging? tells Launch Center Pro that you are calling its in-app messaging function.

tells Launch Center Pro that you are calling its in-app messaging function. body= tells Launch Center Pro to fill in the body of the message with whatever comes after the question mark.

tells Launch Center Pro to fill in the body of the message with whatever comes after the question mark. [prompt:Body] tells Launch Center Pro to display a prompt box, labeled “Body” and using the standard LCP keyboard for input. Whatever text is typed into this box will be percent encoded and and then substituted into the action in place of the prompt text. If you typed “Hello, World!” into the box and hit Done, the actual action that would be launched would look like this: launch://messaging?body=Hello%2C%20World%21 , and this action would bring up the in-app messaging window in Launch Center Pro with the body already filled in with the text “Hello, World!”. All you need to do from there is enter the recipient and hit send.

The second icon on the extended keyboard is the contacts button. Tapping this will give you two options: Choose Contact Now or Ask Each Time. Picking the former brings up a window with all of your iOS contacts. From there you can pick a contact’s phone number or email address and it will be filled into your action.

This is how you pick recipients when you want to make actions specifically hard coded for particular people. Recalling the above example for in-app messaging, you would use the contacts icon if you wanted to fill in the “To” section as well as the “Body” section, which would mean that when you run the action and type in your body, the in-app messaging window will pop up with the recipients already filled in, so all you have to do is hit send. The URL action for this will look largely the same, but with an added “to” parameter which is given the value of the number of the contact you chose. If your contact’s phone number were “520-123-4567”, your action would look like this:

launch://messaging?to=5201234567&body=[prompt:Body]

If you pick the Ask Each Time option, that will insert the [contact] tag into your action. New in 2.3, this tag will automatically call up the contact picker every time the action is run. This seems like a small feature, but it’s actually quite useful. Personally, I prefer typing all of my messages in the actual iOS Messages app rather than in the Launch Center Pro prompt boxes or the in-app messaging windows. As such, most of my messaging actions use Apple’s URL scheme for Messages: sms: . Following the colon in each action is the phone number for one of my friends or family members which I text regularly. Thus, when I run one of the actions, it opens Messages.app directly to my conversation with the corresponding contact. This saves me tons of time searching through list items in the Messaging app to find the friend I want to message, a particular annoyance if they are somewhere far down the list of conversations.

The problem I’ve always had with this workflow is that any time I want to send a message to a contact who I don’t text regularly, and thus does not warrant their own action in my LCP group, I have to do it manually in Messages, which requires a lot more taps than my LCP shortcut (open Messages, swipe back to exit open thread, tap Compose button, start typing contact name, choose contact, tap text box, start typing message versus open LCP, tap-swipe to correct action which automatically switches me to Messages.app in the proper thread, start typing message).

Thanks to the new [contact] tag, I can now go to LCP first no matter who I want to text and still be switched to Messages.app in order to type. The URL action for this is one of the simplest you’ll see: sms:[contact] . With this action, I can open LCP, tap-swipe to my “other contact” action (which automatically brings up the contact picker), slide the picker to the proper letter for the contact I’m looking for and choose that contact’s number, then automatically be sent to Messages.app with the cursor in the text box ready to type. In practice, this may only be a few taps less (although every tap counts for iOS automation enthusiasts, so that alone would be a good reason to use this), but the key is that I can now start in Launch Center Pro every time I want to send a message to someone (replying to messages not counting, as I of course just swipe the notification and go straight to the app), and the swipe to start typing or pick a contact is almost exactly the same no matter who I intend to message. This coalescence of similar tasks into one central place is one of Launch Center Pro’s biggest advantages.

The third icon on the extra keyboard inserts the clipboard variable. Similar to the prompt variables, this is represented by the word clipboard inside of square brackets ( [clipboard] ). Wherever this is used in an action, the variable will be replaced by the encoded contents of whatever is on your clipboard at the time you launch the action.

The fourth icon is for Dropbox. Specifically, for generating Dropbox links.2 If you include the [dropbox] variable inside of your actions, you will see a dialogue pop up revealing the contents of your Dropbox every time you run your action. Choose a file from the Dropbox dialogue and the link to that file will be encoded and sent along with your action.

As a simple example, you could use this in email actions to quickly generate and send links to files in your Dropbox over email. For something like that you would pick “In-App Email” from the System Actions list, then choose “Email with Body & Subject”, and then fill in the necessary parameters from there.

To access your Dropbox files, add the [dropbox] variable somewhere in the subject area for the action. Remember, you can mix multiple input variables to get your actions how you want them. It’s likely in this case that you’ll want to add a few lines of text describing the file you’re sending a link to, so first add a [prompt:Body] variable, then a couple newlines (encoded as %0A in URL actions) for readability, then the [dropbox] variable. You might also want an input prompt for the subject, [prompt:Subject] .

The code for the resulting action would look like this:

launch://email?subject=[prompt:Subject]&body=[prompt:Body]%0A%0A[dropbox]

Running the action would first give you a popup asking for a subject, then another requesting a body, and finally display a window showing all of your Dropbox files. Pick a file to dismiss the dialogue, and finally the in-app email dialogue will pop up with the subject and body filled in, the body including a link to your Dropbox file located two lines below the end of the main text. From there just choose the recipients and press send to finish.

The final extended keyboard icon shown when editing or building actions is the TextExpander snippet icon. If you use this in your action, whatever shortcut you type within the brackets after the colon ( [textexpander:SHORTCUT] ) will be expanded before the action is run, and the text from the expanded snippet will be sent in the action. Don’t forget that each time you change your snippets you need to go to settings in LCP (and any other apps that you use with TextExpander) and choose “Update TextExpander Snippets”.

Icons

The fourth and fifth rows in the action editor are labeled “Icon” and “Schedule”, respectively. The Icon section is particularly important, as this is where you will choose the faces of your actions on your action grid. The Icon section provides three main options: Default, Custom, and Photo. The “Default” option will pull the app icon of whichever app your action pertains to from Launch Center Pro’s database. If your action is a bookmark, it will use the favicon from the bookmark’s website.

The “Custom” option allows you to choose an icon, background color, and background style for your actions. Launch Center Pro has a wide variety of icons to choose from, and those combined with the twelve different colors and six different background styles for your icons gives you more than enough choices to have unique icons for every action you build.

The final icon option, “Photo”, allows you to either take a photo or choose a photo from your photo library to be used as the action’s icon. I find this particularly useful when picking icons for iMessage or phone call actions assigned to specific friends or family members. Finding a picture of your friend’s face among the other icons is much easier than picking a default icon that somehow defines them or reading the text of every name in order to pick them out. Eventually most of your actions will be dealt with by muscle memory, but it’s still nice to be able to use photos. If you want to, you can even add a small frame around the border of your photo icon.

Scheduling actions is another useful feature that Launch Center Pro provides. This section allows you to schedule an alert for a specific date and time. A notification will pop up at the time of the alert, and tapping the notification will automatically run the action attached to it. You can schedule repeating alerts as well, so if you have a certain task that you want to complete every day at a particular time, such as a Day One journal entry, you can use Launch Center Pro to get a notification which will launch you directly into Day One at the specified time and on the specified interval (you can choose hourly, daily, week daily, weekly, monthly or yearly).

Location Triggers

The next two option in the Action Editor are Location Triggers and Notification Sounds. Notification sounds are pretty self explanatory: you can choose to assign one of several sounds to an action and any time a notification for that action is triggered your device will emit the sound that you pick from this list. Location triggers are more interesting.

With location triggers, you can now set up geofences or iBeacons to trigger action notifications on your devices when you enter or leave specific locations. I don’t have any iBeacons to test that functionality with, but I’ve been testing the geofences with a simple action which I’ve found quite useful.

I do most of my work from my local Starbucks, and thus go there almost every day to write or pursue other side projects. I also use Begin to keep a simple list of tasks which I need to get done every day. To test LCP’s location triggers, I’ve been using a geofence to give me a notification every time I enter Starbucks. Swiping the notification automatically launches Begin so I can review the list of tasks I’m planning on getting done before I leave. Furthermore, LCP provides me with the same action notification when I leave Starbucks, so I always remember to launch Begin again and check off all of the tasks I successfully completed during my stay. Another thoughtful addition within this feature is the ability to set multiple locations for the same action. There are two Starbucks locations fairly close to my house, both of which I visit fairly frequently. Since I don’t have a particular schedule for which one I’m working at on a given day, I can easily just set my Begin action to trigger when I arrive at and leave from either of these locations.

That is a very simple example of what LCP’s location triggers can do. You can launch any action with them, from opening an app to performing an entire chain of actions across multiple apps and services. Beyond arriving and leaving, LCP can also filter when location triggers are called by time of day and day of week. If you trigger a notification whenever you go to work, but you only work on weekdays, you can tell LCP to never trigger that notification on Saturdays or Sundays. Furthermore, if you always arrive at work between 8 AM and 10 AM, you can tell LCP to only trigger a notification between those time periods. That way if you leave for lunch, when you come back you won’t be bothered with the same location based notification at a time when you don’t want it. Another way to avoid duplicate notifications is through the useful “suppress duplicates” setting. This parameter allows you to suppress any duplicate notifications for a specified amount of hours/minutes, with a max of just under 24 hours. The default is 30 minutes, so if, for instance, you have an action set to trigger when you leave your house, but you forget something at home and have to return and get it before leaving again, you will only be notified once upon leaving instead of twice.

Location triggers are a great addition to Launch Center Pro, adding versatility to the old “scheduled actions” function which has been around since day one, but which I never found particularly useful, as my schedule Is not very regular.

Moving and Sharing

The final two rows of the action editor allow you to move or share your action. The move option seems a bit out of place to me, as it should really be somehow available in edit mode while you’re editing the rest of your grid, but as it is, this enables a special moving mode in which you can move the selected action into or out of groups. In the standard editing mode, you can move actions and groups around, but there is no way to get an action that is already inside a group out of it, or vice versa. The move option is good to have around, but will hopefully be better integrated with the rest of the editing mode at some point in the future.

The Share Action button can be very useful for sharing your action with others in an easy way. Unlike the Drafts share button, which creates an often massive direct import URL and copies it to your clipboard, the Launch Center Pro share button redirects you to the launchcenterpro.com website, where Contrast provides a service to save actions at individual webpages.

After you tap the share button, the title and URL of your action will be filled in automatically, but you can also optionally type in a description of your action for others to read. When everything is ready, tap “Create”, and a unique webpage will be created for your action, displaying the title, description and URL for it above an “Install” button. You can send the link to this webpage to others, and they can follow it to install your action on their own Launch Center Pro grids.

The advantage this implementation holds over that of Drafts is that a website URL is short enough to be included in a Tweet, so you can tweet your Launch Center Pro actions, solving a problem that many of us have wrestled with in the past when trying to share import links for Drafts actions. If you do want a direct import link, you can tap and hold on the Install button on your action’s webpage and copy the link, which itself is a direct import link. I use this method to include Launch Center Pro import links on my website without having to redirect people to another page first.

Advanced Techniques

Launch Center Pro can be a powerful tool even if you only use it for basic functions. Launching apps or calling simple actions, like iMessage or phone call actions for specific contacts, all from the same place can speed up many daily tasks. This functionality, however, is only the tip of the iceberg for what Launch Center Pro is capable of. Using x-callback-url, LC Callback, IFTTT and Giphy integration, hidden prompt types, headless and recursive actions, Drafts or Pythonista URLs and more, we can take Launch Center Pro to another level of powerful automation.

Manually Building Actions

The Action Composer is a great tool, and does wonders to simplify and speed up the process of building URL actions, but when writing more advanced actions we generally want to see all of the code at all times, and have full control. Due to this, I encourage you to build all of your advanced URL actions either in a text editor like Drafts, or directly in the URL section of Launch Center Pro’s action editor. If you do choose to create your actions in Drafts, you can use install my import action, and run it to import your code directly into LCP after writing it in Drafts.

The Launch Center Pro URL Scheme

You’re in the advanced section now, so I’ll assume you have some amount of knowledge about the basics of URL schemes. The Launch Center Pro URL scheme is much larger than any other I’ve seen, but every path will still start by calling the primary Launch Center Pro “domain name”, launch:// . From here you have a variety of different options, and each one will call a different function within Launch Center Pro:

launch://brightness – Set or toggle the brightness level on your device.

– Set or toggle the brightness level on your device. launch://messaging – Activate the LCP in-app messaging function.

– Activate the LCP in-app messaging function. launch://email – Activate the LCP in-app email function.

– Activate the LCP in-app email function. launch://dropbox – Activate the LCP in-app Dropbox function.

– Activate the LCP in-app Dropbox function. launch://clipboard – Call one of the LCP clipboard functions (generally used to add text or a photo to the clipboard).

– Call one of the LCP clipboard functions (generally used to add text or a photo to the clipboard). launch://define – Define a word using the system dictionary.

– Define a word using the system dictionary. launch://speak – Read text out loud to you.

– Read text out loud to you. launch://facebook – Open the LCP in-app Facebook post dialogue.

– Open the LCP in-app Facebook post dialogue. launch://tweet – Open the LCP in-app tweet dialogue.

– Open the LCP in-app tweet dialogue. launch://sinaweibo – Open the LCP in-app Sina Weibo post dialogue (this feature only works in regions where Sina Weibo is accessible).

– Open the LCP in-app Sina Weibo post dialogue (this feature only works in regions where Sina Weibo is accessible). launch://sharesheet – Open the iOS system share sheet.

– Open the iOS system share sheet. launch://dial – Open the LCP in-app contacts viewer where you can pick a contact and immediately dial their number.

– Open the LCP in-app contacts viewer where you can pick a contact and immediately dial their number. launch://light – Turn on the flash on your device. 3

– Turn on the flash on your device. launch://qr – Activate Launch Center Pro’s built in QR code scanner.

– Activate Launch Center Pro’s built in QR code scanner. launch://ifttt – We’ll get to this later.

Most of these schemes go a bit further, allowing you to add text, photos and more automatically via the URL, but I encourage you to just use the Action Composer so that you don’t have to remember the proper syntax for every one of these paths.

Also worth mentioning is that Launch Center Pro has registered a few other top-level URL schemes besides the one shown above, the main example being launchpro:// .

Multiple registered URL schemes work the same way as having extra website URLs which redirect to a main one, except they don’t actually need to redirect. launch:// and launchpro:// are completely interchangeable beginnings to any LCP URL action. I mention this because launchpro:// was registered before the simpler launch:// , so many people who have been building LCP URL actions for a long time (myself included) are used to and continue to use the launchpro:// scheme. Many older actions posted online might also contain this and other deprecated top-level schemes (in-app actions used to require their own special schemes, so launchpro-clipboard:// , launchpro-messaging:// , launchpro-email:// and more are all registered to the app as well, but thankfully we no longer need to differentiate our actions like this) so if you run into them just remember that they now mean exactly the same thing as launch:// and the small differences can be ignored.

Launch Center Pro x-callback-url Support

Unlike many other apps, Launch Center Pro only supports x-callback-url for a few types of actions. Since LCP’s URL scheme is so far-reaching, x-callback functionality would not make sense on some of its actions (such as turning on the flashlight), but I do wish the list extended a bit further.

As it is, Launch Center Pro supports x-callback-url in its URL schemes for brightness, messaging, email, Dropbox, clipboard, defining, and speaking. It lacks this support in its URL schemes for tweeting, posting to Facebook and calling the iOS share sheet, three actions with which I could see chaining as useful.

For the actions x-callback-url is supported in, simply add x-callback-url/ between launch:// and the chosen path. So if you were going to use x-callback-url to chain a second action to an in-app messaging action, your URL would start like this:

launch://x-callback-url/messaging

From there, the x-callback-url syntax is standard. Add &x-success= after your first action, then add your second action onto the end of that to get them to chain. The second action needs to be percent-encoded, but Launch Center Pro supports the same format for easy encoding as Drafts does: just wrap your second action in {{curly brackets}}.

Here’s an example of an action to send your last photo to a friend, then chain back and email it to another:

launch://x-callback-url/messaging?to=555-555-1212&attach=lastphoto&x-success={{launch://email?to={{johnny@appleseed.com}}&subject=Photo&body={{Here's a photo I took!}}&attach=lastphoto}}

And here’s the breakdown for that action:

Before even running the action, LCP will first parse it for special identifiers such as input prompts and curly bracket encoders. There aren’t any prompts in this action, but there are encoders. LCP will find the portions of the action surrounded by double curly brackets, remove them, and percent-encode those sections of the action before running it from the beginning.

launch:// tells LCP that we are running one of its actions, and enables all the possible paths of in-app actions that we could follow;

tells LCP that we are running one of its actions, and enables all the possible paths of in-app actions that we could follow; x-callback-url/ enables the x-callback-url protocol, telling LCP to start searching for x-callback parameters throughout the rest of the action;

enables the x-callback-url protocol, telling LCP to start searching for x-callback parameters throughout the rest of the action; messaging? narrows the focus to the LCP in-app messaging actions. Since many extra parameters such as the “to” or “body” parameters are the same for multiple types of LCP actions, we have to first tell it which type of action they are applying to before we can use them;

narrows the focus to the LCP in-app messaging actions. Since many extra parameters such as the “to” or “body” parameters are the same for multiple types of LCP actions, we have to first tell it which type of action they are applying to before we can use them; to=555-555-1212 tells LCP that we are sending this message to the phone number “555-555-1212”. Obviously this is a fake number, but when you build this action yourself you will use the contact button on the extended keyboard here to pick the contact you’re actually sending the message to, and it will automatically fill the space after the “to=” parameter with that phone number or email address;

tells LCP that we are sending this message to the phone number “555-555-1212”. Obviously this is a fake number, but when you build this action yourself you will use the contact button on the extended keyboard here to pick the contact you’re actually sending the message to, and it will automatically fill the space after the “to=” parameter with that phone number or email address; &attach=lastphoto is a special parameter available for LCP actions which, not surprisingly, attaches the most recent photo that has been placed on your camera roll. In this case, since we’re in a messaging action, your message will pop up with that last photo automatically placed inside the body and ready to send;

is a special parameter available for LCP actions which, not surprisingly, attaches the most recent photo that has been placed on your camera roll. In this case, since we’re in a messaging action, your message will pop up with that last photo automatically placed inside the body and ready to send; &x-success= is an x-callback-url parameter which is triggered after the successful completion of the preceding action. In this case, once you press send on the messaging dialogue that pops up with the most recent photo attached, x-success is triggered and the next portion of your action, the part that we initially encoded in curly brackets, is decoded and run as normal.

With proper final encoding, the second action will look like this when it is run:

launch://email?to=johnny%40appleseed.com&subject=Photo&body=Here%27s%20a%20photo%20I%20took%21&attach=lastphoto

Here’s that breakdown:

launch:// calls LCP again, informing it that it is running one of its own actions;

calls LCP again, informing it that it is running one of its own actions; email? tells LCP that it’s now running an email action, as opposed to a messaging action like the first one was;

tells LCP that it’s now running an email action, as opposed to a messaging action like the first one was; to=johnny%40appleseed.com sets the recipient of the email to “johnny@appleseed.com”;

sets the recipient of the email to “johnny@appleseed.com”; &subject=Photo sets the subject of the email to “Photo”;

sets the subject of the email to “Photo”; &body=Here%27s%20a%20photo%20I%20took%21 adds “Here’s a photo I took!” to the beginning of the body of the email;

adds “Here’s a photo I took!” to the beginning of the body of the email; &attach=lastphoto attaches the most recent photo from your camera roll, the same photo you just attached to the message you sent in the previous action, to the email.

Now all that’s left is to hit send on the in-app email dialogue that just popped up with everything specified in your action filled in and you’re done. Since all of these parameters were pre-specified in the code of your action, that entire process will happen within just a fraction of a second, pausing only to wait for you to hit send on the message box and then the email box.

Fun With Prompts

Launch Center Pro also comes equipped with a few extra options for input prompts which can’t be found on the menu from the extended keyboard. Similar to how you can use [prompt-num] to bring up the number pad keyboard for your input method, you can also use a few other keywords after “prompt-” to access even more keyboards:

[prompt-twitter] calls up the system keyboard designed for tweeting, which gives easy access to the “@” and “#” symbols.

calls up the system keyboard designed for tweeting, which gives easy access to the “@” and “#” symbols. [prompt-url] puts the “.com” and “/” keys front and center.

puts the “.com” and “/” keys front and center. [prompt-phonepad] gives special phone characters.

gives special phone characters. [prompt-namephonepad] uses the standard keyboard for the first layer, but replaces the number layer with a full number pad.

uses the standard keyboard for the first layer, but replaces the number layer with a full number pad. [prompt-emailaddress] limits the keyboard to valid email characters and gives quick access to the “@” symbol.

limits the keyboard to valid email characters and gives quick access to the “@” symbol. [prompt-numbersandpunctuation] immediately shows the “123” keyboard. It also doesn’t switch back to the “ABC” keyboard when you press the space bar. I’ve found this prompt useful when I want to type in times, as there is no prompt to bring up the iOS system date picker to input times or dates.

immediately shows the “123” keyboard. It also doesn’t switch back to the “ABC” keyboard when you press the space bar. I’ve found this prompt useful when I want to type in times, as there is no prompt to bring up the iOS system date picker to input times or dates. [prompt-return] gives you a return key. The standard prompt box replaces the return key with a “launch” key that dismisses the prompt and sends whatever text you have typed. If you want to be able to include line breaks in your text, use this prompt type.

gives you a return key. The standard prompt box replaces the return key with a “launch” key that dismisses the prompt and sends whatever text you have typed. If you want to be able to include line breaks in your text, use this prompt type. [prompt-list] also replaces the launch key with a return key, but when pressed, instead of inserting a line break it will insert (by default) a comma. Some task apps can receive comma separated lists via URLs and convert them into individual tasks, etc. and the prompt list feature can make things like that easier. As of Launch Center Pro 2.3.1, the list feature has even more abilities. You can override the default functionality to insert any character, or string of characters, instead of a comma. This is done by adding your chosen characters in parentheses before the closing bracket. For example, [prompt-list(, )] will insert a comma followed by a space into your prompt box every time you hit return, resulting in more readable lists if you want to use them for something besides sending data to task apps. You can place any character or string between the parentheses, and the ability to turn the return button into anything you want it to be could have great time saving benefits.

Beyond choosing different prompt types to present yourself with the most useful keyboard for a given task, Launch Center Pro 2.3.1 has also added the ability to include default text inside of your prompts, and even choose a position within the default text to start your cursor. When a prompt which has default text is activated, the text will automatically appear inside of the prompt box. If you’ve set a cursor position, your cursor will appear in that position with the rest of the default text displayed on either side of it.

This feature doesn’t add much that we couldn’t do before by simply hard coding text into our actions on either side of a prompt, but it can be nice for making that hard coded text more explicit so you never forget what it says, or in case you need to tweak it sometimes before running an action. To include default text, simply add an equals sign after your specified prompt type, but before the closing bracket of the prompt, and then type the default text after the equal sign. If you want your cursor to appear somewhere other than at the end of the default text, include a backslash followed by a pipe symbol ( \| ) within the default text, and when you run the action those symbols will be removed and the cursor will be where they were.

LCP 2.3 also introduced the ability to place prompts inside of prompts. Thanks to other behind the scenes improvements, this feature is completely intuitive: simply place another bracketed prompt inside of a first one. Paired with the default text features from 2.3.1, this results in some interesting new possibilities.

This summer I’m working as an intern at my church. Among other things, I’m collaborating with a small team to rebrand the church and redesign its website. For a large, old organization, this is a long process, and it requires that I go to a lot of meetings. Previously I was using a basic LCP action to manually type the details of each meeting and send them to Fantastical to be parsed, but I’ve now designed a neat action which combines the new nested prompt and default text features to make the process quicker and easier. Here’s the action:

fantastical2://x-callback-url/parse?sentence=[prompt:Review=Meeting[prompt:Attendees= With ] at [prompt-NumbersAndPunctuation:Time] on [prompt:Day] ]&add=1&x-success={{launch:}}

This is a pretty straightforward action which launches Fantastical, sends it a sentence to be parsed, automatically imports the sentence, and returns to LCP when finished. The one part you may find nebulous is the mass of prompts which make up the sentence we want Fantastical to parse. Here they are pulled out of the action:

[prompt:Review=Meeting[prompt:Attendees= With ] at [prompt-NumbersAndPunctuation:Time] on [prompt:Day] ]

This is actually just a single prompt, but with a few nested prompts within it. The outside, parent prompt is titled “Review”, and all of the nested variables are part of its default text. Launch Center Pro will parse these chronologically before it parses the parent prompt. So when the action is run, the first thing you will see is a prompt titled “Attendees” which has the default text ” With ” already present in the text box. This is of course where you would type the attendees of the meeting. When that’s done, tap the Next button to get another prompt, this one titled “Time” and with the “123” keyboard being shown instead of the standard “ABC” keyboard. Type in the time of your meeting and press Next again. The next prompt is labeled “Day”, and you should type the day of the week of your meeting into it. Now that all of the nested variables have been resolved, you will see the parent prompt title “Review”. The prompt box will have the contents of everything you’ve typed thus far, so it will be something along the lines of “Meeting With John at 11:30 on Thursday “. This prompt box serves two purposes. If in this particular instance you want to add more information, such as a more descriptive title for the meeting or a date (in case the meeting is not in the current week), the cursor is already positioned with a space after the day of the week, so you can immediately type “July 31”, or whatever your date is to be, and launch your action from there. If you want to edit a different part of the prompt, just tap where you want to type and go from there.

The parent prompt’s second purpose is to give you a chance to review your sentence and correct any mistakes before sending it. The &add=1 parameter tells Fantastical to automatically parse your prompt and return to LCP without you needing to interact with it. This is nice in the sense that it saves you an extra tap after waiting for the delay of swapping to and loading another app, but less nice in that once you launch your action you can’t check to make sure everything has been parsed properly. The last prompt box provides you an opportunity to quickly glance over your sentence and make sure you didn’t have any typos before it is sent for parsing.

Default text and nested input variables allow you to add a new level of finesse to your actions which was previously impossible. These aren’t groundbreaking new features, but they can be used to make our actions clearer and easier to deal with or share with others.

Other than prompts, there are also a few other useful input tags for you to try out. We already discussed the [dropbox] tag, but there are a few variations to draw some more functionality out of it as well.

[dropbox-text] will bring up the Dropbox file picker just like the normal Dropbox tag, but this time when you choose a file, the full text contents will be inserted into the action instead of just a link to the file in your Dropbox.

will bring up the Dropbox file picker just like the normal Dropbox tag, but this time when you choose a file, the full text contents will be inserted into the action instead of just a link to the file in your Dropbox. [dropbox-direct] will insert the direct link to your Dropbox file rather than the link to the share page as the standard tag does.

will insert the direct link to your Dropbox file rather than the link to the share page as the standard tag does. Adding a colon and a file path after the prompt type can open the Dropbox picker directly to a folder. For instance, [dropbox:Apps/Launch Center Pro] will open the Dropbox picker directly into your “/Apps/Launch Center Pro” folder. This method works with [dropbox-text] and [dropbox-direct] input tags as well.

Launch Center Pro 2.3 also brought integration with the popular GIF aggregation service Giphy. GIFs can now be sent as attachments in LCP’s messaging and email actions, or added into any action by inserting a GIF’s direct link. You can programmatically access Giphy’s trending section, search for GIFs with a keyword via hard coded text or input prompt, or use a URL to attach a specific GIF. GIFs can be downloaded and attached with the photo:gif command, but use the [gif] input tag to send their direct links instead.

There are three variations of the [gif] tag:

The standard [gif] with nothing added on will open up the built in Giphy browser to the Trending GIF page. Choose a GIF to have its direct link placed inside of your action.

with nothing added on will open up the built in Giphy browser to the Trending GIF page. Choose a GIF to have its direct link placed inside of your action. [gif:search term] will open the Giphy browser with a predefined search for whatever you put in place of “search term”.

will open the Giphy browser with a predefined search for whatever you put in place of “search term”. [gif-id:ZHbgdNcM9Tv4Q] will directly link to the GIF with whatever ID you use after the colon.

There’s an important distinction to be made between attaching a GIF and linking to a GIF. First off, only a few actions even support actually attaching media, and not all of these work with GIFs. An attachment actually sends the file itself, while linking just sends a link to the file which is hosted somewhere online. Since URL actions only allow the transfer of text, the only actions which can support true attachments are those which Launch Center Pro includes built in support for (or uses an iOS system level functionality for). Thus, messaging, email, and Dropbox actions can include attachments, as can the Tweet, Facebook, and Share Sheet actions which use the iOS integration with Twitter and Facebook 4 and the iOS system Share Sheet. All other actions will require you to just send links to photos or GIFs rather than actually attaching them.

Attaching photos or GIFs is done with a slightly different syntax than standard input tags. Rather than using brackets, attachments are specified by parameters in URLs for actions which support them. Here’s a list of photo attachment parameters and their functions:

?attach=photo brings up a menu of options for where to get the photo. This allows you to choose where to get your photo each time. The more specific attachment types below are shortcuts to the options which will pop up on this list each time, as well as a few which can only be accessed by explicitly defining them and will not present on the list.

brings up a menu of options for where to get the photo. This allows you to choose where to get your photo each time. The more specific attachment types below are shortcuts to the options which will pop up on this list each time, as well as a few which can only be accessed by explicitly defining them and will not present on the list. ?attach=photo:last attaches the last photo on your camera roll.

attaches the last photo on your camera roll. ?attach=photo:camera brings up a camera for you to take a new photo.

brings up a camera for you to take a new photo. ?attach=photo:frontcamera same as camera except this defaults to the front facing camera. Perfect for quickly snapping selfies.

same as except this defaults to the front facing camera. Perfect for quickly snapping selfies. ?attach=photo:library brings up the photo picker for your entire library.

brings up the photo picker for your entire library. ?attach=photo:cameraroll brings up the photo picker with your camera roll already open.

brings up the photo picker with your camera roll already open. ?attach=photo:dropbox allows you to pick a photo from Dropbox.

allows you to pick a photo from Dropbox. ?attach=photo:clipboard uses the photo on your clipboard.

uses the photo on your clipboard. ?attach=photo:gif brings up the Giphy browser in the trending GIFs section.

brings up the Giphy browser in the trending GIFs section. ?attach=photo:gif&gif-search=search-term brings up the Giphy browser with a predefined search of whatever you put in place of “search-term”.

brings up the Giphy browser with a predefined search of whatever you put in place of “search-term”. ?attach=photo:gif&gif-id=ZHbgdNcM9Tv4Q automatically downloads and attaches the GIF with whatever ID you place in the ID parameter.

Here’s an action to attach the last photo added to your camera role to an email:

launch://email?attach=photo:last

And an action to attach a GIF from Giphy’s trending section to a new message:

launch://messaging?attach=photo:gif

That will bring up the trending section, from which you can choose a GIF, and then automatically place that GIF inside of a message. From there you can manually type the recipient and content of the message and send it.

Next, here’s a somewhat more interesting action which will allow you to search for a GIF and then send it via text message or email, or tweet a link to it:

[[list:Share GIF Via...|Message=launch://messaging?attach=photo:gif&gif-search=[prompt:Search for GIF]|Twitter=launch://?url={{launch://tweet?text=[gif:[prompt:Search For GIF]]}}|Email=launch://email?attach=photo:gif&gif-search=[prompt:Search for GIF]]]

Direct Import Link for Email Last Photo action

Direct Import Link for Message Trending GIF action

Direct Import Link for Share GIF action

There is one final input type for Launch Center Pro, and this one opens up a whole new realm of possibilities: lists.

Lists allow you to build a menu of options that will pop up each time you launch an action. You can specify titles for the options and give each title a value, or just use the values as the titles. When you pick an option from the list, the feature acts just like the standard input prompts, replacing the list variable inside of your action with the value of the option you chose. With lists you can build versatile and powerful multiple choice decisions into your actions. Thus, running the same action can do a few different things depending on the situation.

The basic syntax for lists looks something like this:

[list:Title|Option 1|Option 2|Option 3]

If you placed that exact list inside of an action and ran it, you would be faced with a pop up menu titled “Title” with four buttons labeled “Option 1”, “Option 2”, “Option 3” and “Cancel”. When you press one of the buttons it will swap out the list variable in the action with the text of the button you pressed, percent-encoded (except the Cancel button, which just cancels the entire action).

You can add as many options into your list as you want; if they extend off of the screen then the list of buttons becomes scrollable to reach lower options. In your code, just make sure to separate each option you add with a pipe (“|”) symbol. The title parameter is technically optional, but I encourage you to always use it, as it makes actions more understandable and shareable.

Here’s an example of using a list to build a Tweetbot search action with hard-coded parameters:

tweetbot:///search?query=[list:Search Query|MacStories.net|Unapologetic.io|Launch Center Pro|Apple]

Running this action from LCP will pop up a menu with the four options from the list as buttons, and a fifth “Cancel” button. When you select an option, that text will be swapped into the Tweetbot URL and then the action will be run as normal. If you run the action as is above, then choose “Launch Center Pro” from the list, the entire list variable will be replaced by the percent-encode text “Launch%20Center%20Pro”, so the actual action that LCP runs will look like this:

tweetbot:///search?query=Launch%20Center%20Pro

All the swapping happens instantaneously in the background of course, so you won’t see the swap or the new URL, you’ll just be redirected to Tweetbot where the search box will pop up with “Launch Center Pro” already plugged in.

While these most basic lists can be useful in and of themselves, they become even more powerful with their ability to attach different text to the parameters than that which is displayed on the buttons. By adding “=” after the text of each option, we can change the option into just a title for the button, and selecting the title will add different text into the action. In the above example we could use this to make the exact function of our buttons a little clearer, so you understand exactly what tapping each button will do:

tweetbot:///search?query=[list:Search Query|Search Tweetbot for "MacStories.net"=MacStories.net|Search Tweetbot for "Unapologetic.io"=Unapologetic.io|Search Tweetbot for "Launch Center Pro"=Launch Center Pro|Search Tweetbot for "Apple"=Apple]

Running this code would display a menu that performs the exact same function as the first one did, but the buttons now show more descriptive titles.

With Launch Center Pro 2.3, Contrast introduced a new UI for building lists. As I mentioned before, when you tap the input tag button on the custom keyboard while making an LCP action, it has a third option, “List”. Choosing this option brings up a new window for building lists without manually typing them out. The UI has an input box for the list’s title and a section to type in any amount of list items, each with a title and output. When you’re finished, tap “Done”, and your list will be created automatically and inserted into the code wherever you had been typing. After you have pressed Done there is no way to recall the list builder window, so you should still be able to understand list syntax if you’re going to use them, but this definitely makes the original building of lists significantly easier.

Lists can be nested as well, just like prompts. We can use a list to make the New Meeting action a little simpler. The third nested prompt is for the day of the week, but since there are only seven days in a week, that makes a perfect time to use a list of options and avoid having to type out the day manually. Nesting a list is as easy as nesting a prompt, you just place the list inside the brackets of the parent prompt, where you want the text to appear. Here’s the action using a list:

fantastical2://x-callback-url/parse?sentence=[prompt:Review=Meeting[prompt:Attendees= With ] at [prompt-NumbersAndPunctuation:Time] on [list:Day|Sunday|Monday|Tuesday|Wednesday|Thursday|Friday|Saturday|Undefined Day=] ]&add=1&x-success={{launch:}}

I added an eighth option for “Undefined Day” as well, so that you don’t have to cancel the whole action if you don’t want to define a day in your sentence (for instance, if the meeting is later in the same day that you are creating the event). Run the action and you will now be presented with a list of options for your third variable, and whichever option you choose will show up in the final parent prompt for you to review before parsing.

Direct Import Link for New Meeting action

The power of Lists does not stop here. Adding hard coded text into your actions is great, but this is the advanced section, so lets dig deeper into the higher level capabilities that we can drag out of LCP lists. Previously these advanced actions required a lot of percent-encoding and a strong grasp on how Launch Center Pro handled URL actions, but new changes in Launch Center Pro 2.3 (which we’ll get to in more detail momentarily) have rendered that knowledge less integral to building most actions.

That said, I still think it’s important to understand everything 2.3 is doing behind the scenes, as it will help you grasp where you need to place your curly bracket encoders and how many you need to use, as well as making it easier to debug an action if you have an error with your encoders. Furthermore, no other app besides Launch Center Pro has implemented such far reaching techniques to simplify the writing of URL actions, so if you’re trying to build a complex URL action in Drafts, Editorial or another app, or dealing with any pre-2.3 LCP actions, you will still need to know the details of encoding.

Percent-Encoding

Percent-encoding a piece of text or code will take most of the special, non-alphanumeric characters and encode them into two-character strings of numbers and capital letters, each string prefixed with a single “%” sign (hence the name “percent encoding”). This is often also referred to as “URL encoding”, because any URL, be it a URL action or just a standard web URL, must have these characters encoded in order to function.

Here are the values for a few of the most common characters to need encoding in iOS URL actions:

” ” (single space): %20

“

” (newline, represents hitting the return key): %0A

”:”: %3A

”/”: %2F

”?”: %3F

”=”: %3D

”[“: %5B

”]”: %5D

”%”: %25

So a very basic URL action, such as launchpro:// , which simply launches Launch Center Pro, would be percent encoded to launchpro%3A%2F%2F . This might look complex, but just break it down between each percent sign: “%3A” represents a colon, “:”, and two “%2F” strings represent two forward slashes, “//”. The complex looking string after “launchpro” is still just the same “://” that we started with. Not too hard, right? This is really as complex as percent encoding ever gets, it simply takes whatever special characters are found in a string and swaps them out for their corresponding two-character string with a percent sign in front of it.

Take a glance at this slightly longer percent encoded URL action:

launchpro%3A%2F%2Fclipboard%3Ftext%3DHello%2C%20world%21

Breaking the action up at percent signs, we see mostly familiar characters: “%3A%2F%2F”, as we already saw above, translates to “://”. “%3F” translates to “?”, %3D to “=”, and “%20” to a blank space. I didn’t list “%2C” or “%21” above, but they are “,” and “!”, respectively. So altogether this action decodes to:

launchpro://clipboard?text=Hello, world!

That’s just a simple action to copy “Hello, world!” to your clipboard!

Of course, regardless of whether you know the percent values for basic characters, manually encoding a URL action would be incredibly tedious work. That’s why we have methods to do it for us automatically such as wrapping code fragments in {{double curly brackets}} (works in Drafts and Launch Center Pro) or running actions to encode the contents of the clipboard so we can copy normal actions and paste their encoded versions where we need them. Still, it’s smart to at least be able to understand these encoded values so that you are not intimidated when you see an encoded action. It’s exactly the same as the actions you already can build and understand, simply with the special characters changed a bit.

So what happens if we need to double encode a string? Well in the first round of encoding, all the special characters were already swapped out with their percent values. This means the only remaining special characters are the percent signs from the originally encoded values.

Our simple launch:// action looks like this when double encoded:

launch%253A%252F%252F

This may look unreadable at first, but remember, every percent encoded character is a string of exactly two characters, prefixed with “%”. So break the action up at the percent signs and decode each two-character string that follows: “%253A” is not a four-character percent encoded value, it’s an encoded “%25” followed by the regular characters “3A”. Decode the encoded value, which itself is a percent sign, and you’re left with “%3A”. Do the same for the two “%252F” strings and you get “%2F%2F”. Since this was originally double encoded, you’ve now dropped down a layer and are left with the single encode launchpro%3A%2F%2F . Decode those values and we’re back to our unencoded launchpro:// .

I’m not going to break down any more complex examples than the easy double encoded one above because it’s not necessary, you should already see the pattern: every level of encoding after the first one is just encoding a bunch of percent signs as “%25” and sticking that in front of the previous two-character strings. A triple encoded colon just encodes another percent sign: “%25253A”. Decode it one level to “%253A”, another to “%3A”, and one more to be back to “:”. Even if you encoded a colon one hundred times, it would just result in a percent sign followed by ninety-nine “25”s in a row, and finally a “3A”. The value of every multi-encoded character lies in the last two characters in the string.

It’s highly unlikely that you’ll ever need to encode a string by hand at all, much less more than a single time. The only reason I’ve ever even single encoded an action manually is when it was a very simple one like launchpro:// and I didn’t feel like copying it and leaving my text field to find a clipboard converter action when I could just type out “%3A%2F%2F”. Even if you never have to do this yourself, in the next section we’ll be playing with double and triple encoded actions, and while they don’t look nearly as bad as they used to before LCP 2.3, if you don’t have a full grasp of their encoding needs then understanding all of the brackets and debugging actions will be very difficult.

The Launch Center Pro URL Handler

Now you understand encoding and decoding URL actions, but it’s also useful to know exactly how an app deals with a URL action when it receives one, particularly when you’re talking about a launcher app like LCP or Drafts. These apps include special variables, encoders, and other advanced features that need to be resolved to encoded text before the URL can be run, and each app might handle this in a different manner.

For Launch Center Pro, the special values in quesiton are [input variables] and {{double curly bracket encoders}}. We’ll refer to both of these together as the “special identifiers” available in LCP URLs. Input variables, as we discussed above, can be keyboard [prompt]s of varying types, [dropbox] link generators, multiple choice [list]s, [TextExpander] snippets, or [clipboard] variables. Finally, any text that you wrap in double curly brackets will be percent-encoded a single time for each set of brackets it is surrounded by.

Remember, URL actions can only be run if every single character that needs to be is properly percent encoded. Thus, if you try to run an action with “[prompt]” stuck in the middle of it, you will get an error because the brackets are not encoded. Same goes for greater than and less than signs and curly brackets. The reason special identifiers are allowed in our LCP actions is because Launch Center Pro’s URL handler parses every URL before running, searching for these items. When it finds one, it resolves it before continuing. In the case of input prompts, “resolving” them means throwing up a prompt box for us to type into. Whatever text that we type is percent encoded and swapped out with the prompt identifier in the action.

For lists, the list identifier, including all its option parameters, is swapped out for the text attached to the button we pick. TextExpander snippets are expanded in the background to their encoded value without requiring user input. Any text wrapped in curly brackets is completely encoded and the brackets are removed. If the text was already encoded one or more levels, it is encoded again.

For most simple actions, thinking about the order of operations of these resolutions and how LCP goes about running a URL is unnecessary, but as we start to demand more from our actions, we can run into confusion.

With Launch Center Pro 2.3 and 2.3.1, Contrast made some major changes to the LCP URL handler. Previously, the first thing LCP would do when you ran an action was to validate that the URL could actually be run by the system. It did this by looking at the “domain” of your action and making sure that your device had the app which the domain applied to installed. Failing that step would cause your action to get an error before it even started.

As of 2.3, LCP no longer requires URLs to be validated before it parses them for identifiers. I’m not certain if this step was completely removed or just pushed somewhere back in the order of operations. Regardless, it doesn’t particularly matter because if you run an action for an uninstalled app it’s not going to work anyway whether LCP stops the action first or not. The most important note about this change is that we can now begin our URL actions with special identifiers without needing to use the old launch://?url= hack. Action menus (list variables in which each option expands to an entire action instead of just a word) can begin immediately with [list... , removing an entire level of unnecessary and confusing encoding and making these menus much easier to build.

Since validation is no longer necessary, LCP now parses your action for special identifiers immediately after you launch it. However, this step has been altered from its old version as well. Pre-2.3, LCP parsed the URL chronologically, resolving each individual special identifier as it went. If any identifiers were nested inside of the identifier that it found first, it would often result in errors or completely ignoring the nested identifiers. Post-2.3, the URL handler now searches for the nested identifiers first, then expands out to the parents. This new method has huge implications for advanced actions. Since Launch Center Pro can look inside of identifiers before trying to resolve them, we can now use nested prompts and lists or nested curly bracket encoders without needing to jump through the insanely complex hoops that we used pre-2.3. Building URL actions is now completely intuitive: if you want to double encode something just wrap it in two sets of encoders. If you want to have a prompt come up after choosing an option in a list, just place a [prompt] inside of a [list] . Lists in lists or prompts in prompts? It’s all possible, and extremely easy, after Launch Center Pro 2.3.

With the new URL handler, Contrast wants to make the lives of action builders easier by reducing the amount of work we need to do to get advanced actions working. To do this they’ve built a basic level of intelligence into the way the handler parses URL actions. Now LCP looks at the whole action before resolving variables in order to determine which ones actually need to be resolved and which don’t.

For instance, as I stated above, LCP usually parses any nested variables before the parent variables. However, there are exceptions to this rule depending on what your action looks like and which type of variable you are dealing with. If you nest a prompt inside of a list option, you probably don’t want that prompt to pop up before the list does in case you pick a different option which doesn’t call the prompt. LCP knows this, so in this situation it will resolve the parent variable, the list, and then only resolve the nested prompt if you pick the list option which contains it. LCP 2.3 and 2.3.1 are filled with various special cases like this in which the handler tries to intelligently guess what we want, and in my testing Contrast has done a fantastic job with this implementation.

That said, the handler can’t always guess what we’re thinking, particularly when we’re dealing with higher level actions and trying to push the app to its limits. Thankfully, with 2.3.1, Contrast has provided us with a variety of “special operators” which we can use as tools to manually override any incorrect guesses the URL handler might make when parsing our actions. These single character operators are placed directly after the first hard bracket beginning a variable in LCP, and can be used on any type of variable. Before we get into the particular uses of these manual overrides, we need to go a little more in depth with how the URL handler treats input variables in LCP 2.3.1.

First off, with 2.3.1, there is no longer a need to explicitly define whether or not to encode a variable. In previous versions we would surround variables with either one or two sets of hard brackets. A [[double hard bracketed]] variable would leave the contents unencoded after being resolved while a [single hard bracketed] variable would encode the contents after resolving. Now all variables are encoded based on their context within the URL, so single and double hard bracketed variables are treated exactly the same. Furthermore, variables are no longer affected by curly bracket encoders. Use encoders to make sure that any plain text is encoded to the proper level, but any encoding of input variables should happen automatically, or if it fails for some reason then we will fix it with the new special operators instead of with curly bracket encoders.

The basic gist of the way LCP decides how to encode input variables is that if a URL action begins with a variable, or if the variable lies somewhere within the action’s path instead of in a parameter value, then the result will not be encoded. A parameter value is generally anything after an equal sign, the custom data which you are sending via your URL.

For example, take a basic Drafts URL action: drafts://x-callback-url/create?text=Hello%20World&action=Copy%20to%20Clipboard . This action includes two parameters, text and action . In the action the values for those parameters are Hello%20World for the text parameter and Copy%20to%20Clipboard for the action parameter. As in any URL action, these parameter values need to be encoded while the rest of the action should not be encoded. Every piece of the action besides the encoded parameter values is part of the action’s “path”. Just like a standard folder path or a website URL path, a URL action path tells the app in question where you want to navigate within its URL scheme, and the parameter values will be used by the app to complete whatever task you are calling within it.

A lot of advanced Launch Center Pro actions dynamically manipulate the path of a URL instead of simply filling in parameters. Action menus fill in entire URL action paths and launch them, while other types of actions may allow users to switch between different actions within the same app by mixing and matching smaller pieces of the action path. In almost all of the cases where you are manipulating the action itself instead of only its parameters, you don’t want to encode the results of your variables because that will break your action. As such, LCP 2.3 and higher checks the context of your input variables and determines whether they are in the path or in a parameter. If a variable is found to be in the path, it is left unencoded. If it is found to be in a parameter, it is encoded. This method works in almost every situation, but as with almost anything related to URL schemes, there are special edge cases which will break that rule.

A notable example is the 1Password URL scheme. For some reason the developers chose to make the 1Password search terms a part of each 1Password URL action’s path instead of setting them as parameters. A 1Password URL action to search for Twitter logins would look like this: onepassword://search/Twitter . There are no parameters: 1Password just puts your search term inside of the path. As such, if the rules stopped at path versus parameter, and you searched for a term which had a URL unsafe character in it via an LCP prompt, the prompt would not be encoded and your action would break. Thankfully, Contrast found a clever way around edge cases like these: if a variable is located within a path then when you send the text to resolve the variable to, LCP will first check that text for any URL unsafe characters (such as a space). If any are found, the text will be encoded before the action is run. This solves the problem presented by URL schemes like 1Password’s in almost every situation. If you’re finding that you have an edge case which breaks these rules, you can manually override the functionality with the special operators mentioned before in order to make it work. Unfortunately (or maybe fortunately) I can’t show any examples of that because not one of my actions, even the most complicated ones, have managed to break the rules and cause an error.

There are also new rules related to x-success variables for chained actions. These are pretty basic: if you have an unencoded variable which is located within an x-success action, it will not be resolved until that x-success action is being run. So when the URL handler makes its first pass of a chained action, it is only looking to resolve variables in the first action and ignoring anything in the chained second action. This prevents annoying problems we used to face in which every input variable from both chained actions would need to be resolved before anything was actually run. In the first version of this guide I used an example of an action which let you first type an in-app text message and then chain back and type the subject and body for an in-app email. The problem with the basic version of the action was that it would give you all three prompt boxes first, then go back and run the action. Thus you would type the message, then type the email, then send the message, then send the email. This order was disruptive and annoying because it forced you to keep switching back and forth between the message and the email. Pre-2.3, we had to jump through a long and complicated series of hoops in order to properly time delay those prompts so they came up in the correct order. Post-2.3 that order happens automatically. With zero additional coding, the prompts are prompted in the proper order: first you type the message prompt, then you send the message, then you type the email prompts, then you send the email. The code for this action looks just like you would expect:

launch://x-callback-url/messaging?body=[prompt-return:Message Body]&x-success={{launch://email?subject=[prompt:Email Subject]&body=[prompt-return:Email Body]}}

Before LCP 2.3, to get that action with that order, we had to write this code:

launch://x-callback-url/messaging?body=[prompt-return:Message Body]&x-success={{launch://?url=launch%3A%2F%2Femail%3Fsubject%3D%5Bprompt%3AEmail%20Subject%5D%26body%3D%5Bprompt-return%3AEmail%20Body%5D}}

Another benefit to this new x-success rule is that you don’t need to worry about encoding prompts multiple times when chaining more than two actions. All of the prompts which are deeper down the chain will be ignored until the action in which they reside is up to bat to be run, then they will be resolved at a time when they only need to be encoded once, and LCP handles that automatically. One less thing for us to think about when building complex actions.

Altogether, these new rules have successfully solved nearly every potential problem I’ve thrown at LCP 2.3.1. In general you won’t even need to worry about them, because their purpose is to work in the background and make your actions just work without extra effort. Sometimes there will be issues though, and that’s why Contrast has added in manual overrides. Here’s a list of all the special operators and what they do (“input” is substituted for the type of input variable, such as “prompt” or “list”):

[+input] increases the auto-calculated encoding level by one for each “+” placed in front of the variable type. The word “auto-calculated” is important here. Putting a “+” operator in your variable does not mean that it will be encoded only once. Rather, it means it will be encoded one more time than LCP was going to automatically encode it. If LCP was not planning to encode it, then the plus would cause it to be encoded once. If it was planning to encode it, a plus would result in encoding the result twice. For example, if you were to run this action: launch://clipboard?text=[+prompt] and then type in “This is a test” when the prompt box appears, the result would encode the text an extra time and copy “This%20is%20a%20test” to your clipboard. If you did the same thing, but used two pluses ( [++prompt] ), the result would copy “This%2520is%2520a%2520test” to your clipboard.

[-input] decreases the auto-calculated encoding level by one for each “-” placed in front of the variable type. If you use this operator in a prompt which was not going to be encoded anyway, it will have no effect. Otherwise, you can use it to fix any issues with LCP over-encoding variables. I haven’t actually found any instance of that occurring, but keep this tool in mind if you do run into one.

[~input] overrides any automatic encoding, keeping the resolved variable unencoded. You can add any number of pluses after the “~” but before the variable type to manually set an exact level of encoding (e.g., [~++prompt] will double encode whatever you type into your prompt regardless of what context the variable is in).

[^input] will delay the resolution of the variable by one scan of the URL handler for each “^” placed in front of the variable type. One small possible use for this is to pass the literal identifier into an action instead of resolving it. For instance, running drafts://x-callback-url/create?text=[^clipboard] from LCP would create a new draft in Drafts which actually consists of the text “[clipboard]” instead of being filled in by the clipboard contents.

[!input] will force the resolution of the variable on the URL handler’s first pass. This works even when the variable is in a chained x-success action, so one use for it is to revert LCP to the old model of resolving variables. As an example, if for some reason you wanted to take the messaging and email action from above and revert it to the old functionality (where you fill in all of the input prompts before sending the message or the email) you can do that simply by adding exclamation mark operators into the variables in the second action, like so:

launch://x-callback-url/messaging?body=[prompt-return:Message Body]&x-success={{launch://email?subject=[!prompt:Email Subject]&body=[!prompt-return:Email Body]}}

That action will prompt you first for the “Message Body”, then for the “Email Subject”, then for the “Email Body”. Only after you have filled all of those in will the in-app messaging window pop up with the text from your first prompt. Once sent, the in-app email window will pop up with the subject and body filled in with your second and third prompts, respectively. In this case that change is largely useless, and probably even detrimental to the action, but there may be a different action in which you want to force all of the prompts to pop up first before anything else actually happens. If you do build an action like that, keep in mind that the exclamation point operator can make it work the way you want it to.

Another display of the new URL handler’s enhanced abilities: when you place prompts inside of list options, you no longer have to encode them like you did with the old version of LCP. You can leave them unencoded and the handler will know to only resolve the ones located in the list option you end up picking. In the case of the Tweetbot search action we built earlier, we can tweak the action to add a fifth option, an input prompt, by changing the code to this:

tweetbot:///search?query=[list:Search Query|Search Tweetbot for "MacStories.net"=MacStories.net|Search Tweetbot for "Unapologetic.io"=Unapologetic.io|Search Tweetbot for "Launch Center Pro"=Launch Center Pro|Search Tweetbot for "Apple"=Apple|Prompt for Search Term=[prompt:Search Term]]

Note that since you no longer need to encode any input variables to make them work in lists, you also don’t need to encode anything else in the list options. In previous version of LCP, if we added in a prompt it often required us to wrap all of the list options in curly brackets or manually encode them. In the new versions you have to be careful, because wrapping list options in curly brackets will now actually break the list. With all of the new changes, Contrast has done a fantastic job at maintaining backwards compatibility with old actions, but this is one place in which they were unable to do so. As such, if any of your old list actions are suddenly not working in the new versions of LCP, just remove the curly brackets and make sure your variables aren’t manually encoded and your problem should be taken care of.

Another old problem that the changes to the URL handler have solved is overzealous clipboard resolution. Before 2.3, if you chained an action in which the first action in the chain saved something to the clipboard, and the second action then called the clipboard (often referred to as a “clipboard hack”), the clipboard variable in the second action would be resolved before the first action was run. The result was that your second action would use whatever text was on your clipboard before you ran the action, which could literally be anything. Since the new versions of LCP changed the rules so that variables in chained actions are not resolved until the actions before them have been run, clipboard variables in situations like this will not resolve until after you have saved what you want to the clipboard. In the old version of this guide we used a clipboard hack in order to type text a single time into a prompt box and then use that same text to first send a message and then send an email. Here is the code that used to be required to make that action work:

launch://x-callback-url/clipboard?text=[prompt-return:Text]&x-success={{launch://?url=launch%3A%2F%2Fx-callback-url%2Fmessaging%3Fbody%3D%5Bclipboard%5D%26x-success%3D%7B%7Blaunch%3A%2F%2Fx-callback-url%2Femail%3Fbody%3D%5Bclipboard%5D%7D%7D}}

With the changes to the URL handler, here is how that same action can be produced today:

launch://x-callback-url/clipboard?text=[prompt-return:Text]&x-success={{launch://x-callback-url/messaging?body=[clipboard]&x-success={{launch://x-callback-url/email?body=[clipboard]}}}}

Direct Import Link for Message Then Email action

As you can see, not only is the action shorter, but it’s also far more readable and easy to understand. This optimization of code for complex URL actions is a hallmark feature of Launch Center Pro 2.3 and 2.3.1. These improvements make many of our old methods for building advanced actions look rudimentary. Most notably, the old way of achieving recursive (looping) actions, which now no longer requires extremely complex clipboard hacks due to the powerful new [action] tag.

The [action:ID] Tag

As of Launch Center Pro 2.3, every action you add to your grid is assigned it’s own individual Action ID. The ID, as far as I can tell, is simply a chronological counter based on how many actions you have. If you have fifty actions and then add a new one, it’s action ID will be “51”. Don’t worry though, you don’t need to memorize how many actions you have and mentally keep counting every time you create another one; you can find the action ID for every action by tapping it in edit mode and scrolling to the very bottom of the options in the Action Editor.

Once you have an action’s ID, you can now call that action from any other action in your grid using the action ID tag.