Adding Shortcuts to Launch Center Pro

As many of you are probably aware, with the release of Launch Center Pro 3, Contrast created a Shortcuts custom shortcut to make adding shortcuts to Launch Center Pro that much easier. For those interested, the shortcut is below; and it is worth taking note that it was the addition of being able to specify the clipboard contents as an icon that made this a particularly cool feature.

I decided to make a few revisions to this custom shortcut in an effort to enhance it for my own needs. It doesn’t appear to have obviously broken anything, so I thought I might share it here in case anyone else might find it of use too.

The name may look a little odd at first, but I’ll come back to that below as I describe the revisions I’ve made.

TL;DR Version of revisions
  1. Enables ‘invisible’ run of shortcuts via self or very shortcut call shortcut.
  2. Option to return to Launch Center Pro at end of shortcut.
  3. Sort & filter options for selection of shortcut.

Launch Method

When the shortcut is run (directly), it will display several menus to the user to build up the framework for the shortcut launching. It begins by prompting the user to select a launch method.

I added this to speed up my shortcuts. When version 3 of Launch Center Pro launched, I was really impressed by the speed of start-up and launch and when running shortcuts, it was actually feeling slowed down. Apart from clever algorithms and generally reducing the number of actions in a shortcut, another way to speed up a shortcut is to run it ‘invisibly’. By this I mean call one shortcut from another with the Run Shortcut action, and the option to show while running turned off. Because Shortcuts doesn’t have to animate and redraw the page, it can run the shortcut more efficiently. For more long/complex shortcuts this can make a huge difference.

So what does this first menu actually do?

Well the first option for “Direct call of shortcut” will set the basic approach of the shortcut to do just the same as the original shortcut. It will put a URL into Launch Center Pro that triggers the shortcut and it will run that shortcut ‘visibly’.

The second and third options both provide ways for indirect running of a shortcut such that it will be run ‘invisibly’ as described above.

“Indirect call via ‘LCP Run Shortcut’ shortcut” will actually use itself to instigate this behaviour. If you look at the steps in the shortcut, you’ll see it immediately captures any parameter coming in and if there is one, it will attempt to run it as a shortcut. Failing that, it will begin running through the installation procedure. It’s for this reason I named the shortcut as I have. If the name of a shortcut is passed into this shortcut as a text parameter, it will be captured and run ‘invisibly’.

The final option of “Indirect call via ‘Quick Run’ shortcut” works in just the same way as for the “LCP Run Shortcut”. The difference is that the shortcut that it uses has no checking for if the parameter exists, working on the premise that it always will. It is also so short on the page, that it will never scroll during execution. In practical terms I’ve not seen any notable difference in speed between the two shortcuts, but not everyone on every device may necessarily have the same experience. Plus I already had Quick Run Shortcut in place and in use.

Here’s the “Quick Run” shortcut

Post Launch

The next menu is a choice of post launch action. That are hopefully fairly obvious as to their purpose.


The first, “Stay in shortcuts” will simply execute the shortcut and things will finish there. This onec again is as per the original shortcut released with Launch Center Pro.

The second, “Return to LCP” will append some extra parameters to the launch URL to be stored in Launch Center Pro. These parameters will return the user back to Launch Center Pro once the shortcut has completed execution.

I added this option as I found I would often be doing one thing from Launch Center Pro, and then want to follow that up with something else. Being returned automatically just reduced a bit of the friction.

Sorted Shortcut Selection

The final menu provides several options for displaying the list of shortcuts that is presented to the user to select from.

The first two options will return all shortcuts whilst the last two will return a sub-set based on the name of the shortcut containing text entered by the user.

Alphabetical sorting selections will sort on the name, whereas the ‘latest first’ ones will sort reverse chronologically. I used last modified date, but creation date worked just the same for me. I had expected to be able to distinguish between the two, but it didn’t seem to work like that in practice.

Having these options lets me find the shortcut I want much more quickly than not applying any filtering/ordering. I have hundreds of shortcuts so there would otherwise be a lot of scrolling up and down involved to find just the right shortcut.

One thing to note is that the filtering is case sensitive.
i.e. PhotophotoPHOTO

Expand this for some thoughts on tackling case sensitive filtering in Shortcuts

I’ve implemented case insensitive filtering in Shortcuts before, but it was more than I needed for this one. If anyone wants to take it on and roll their own revision, I’ll just note a couple of things.

1. Iteration
Iterating through all the shortcuts individually is very slow when you have a large library of shortcuts, but lowercasing everything and matching against that, then building your list from that could be one way.

2. Concatenated Filters
Concatenating multiple filtered sets (think filters base on OR) should be much faster than iterating.

The trick is to apply the right filters. Think uppercase, lowercase and , capitalisation as your minimum set.

What happens then if you wanted say “iPhone”? None of the above would match it and if the user had typed it into the app in a mismatching case too … well, things can be inadvertently omitted.

It can also lead to duplication so some consideration to deduplication should be given, though for most, this may be something that would not occur or could be put up with.

Beyond the elements above, if you compare the revised custom shortcut to the original you’ll also see some differences in the way I’ve structured the building of the import URL, but this was just to make it easier for people to follow what was going on overall as I added some extra complexity overall to have the URL is built.

That should pretty much cover the differences. It’s working for me … so far, but there’s always a chance I’ve missed something, or that it will have difficulty coping with an unusual shortcut name, etc.

Hopefully some of you will find this, or at least elements of this, useful and/or interesting.