Creating small Helper Shortcuts

Has anyone tried making small helper shortcuts for the Shortcuts app?

I just made one to help me get input and act on it. It’s possible to do this normally, but the helper shortcut keeps the main shortcut simpler, and it’s reusable.

If any else has tried/had success with this sort of thing, I’d love to know.

Player shortcut:

Helper:

Note: empty keys in the dictionary are ignored in the list options, which is handy for reuse ability

Personally for turning text into a list I just split it by new lines and then choose from list, but I do have a few function workflows!

One of them is Epoch Time Converter which I use for adding seconds to Epoch time to convert it to normal time - this is handy when dealing with APIs such as Dark Sky.

2 Likes

Oh, that’s simple, and neat!
I was fixed on finding a workaround to avoid bulky menus when setting variables and missed the split-text route entirely.

2 Likes

I’d think that it will be slower to use a helper in a separate shortcut than to include it in a single one. I don’t have any metrics but Shortcuts isn’t particularly fast and seems especially slower when you need to transition out of a running shortcut to call another shortcut or app or read a file.

Better than Workflow was though.

While it might be marginally slower if you have the same logic to include in many shortcuts then I think this route is definitely worth considering. Anything more than a few steps at any rate. Plus then if you need to update it you just do so once.

2 Likes

Is it slower? I don’t think it is. I moved a few things from my “going home” shortcut into separate shortcuts and didn’t see any change in speed.

This was an interesting question and one which, anecdotally, I’d seen no particular performance hit on either Workflow or Shortcuts. Incidentally, I’ve been calling out in this way since before Workflow had an action to call other workflows in order to breakdown/simplify and re-use components sets of actions.

I’ve been running a few tests and whilst I would not put them forward as empirical proof, I think there’s something to sharing some real data and observations from that.

There’s quite a bit in here, so just exapnd any sections you want to read.

The Testing Shortcuts

Here are the links for four Shortcuts custom shortcuts.


Timing Test 1

This is a primary shortcut. It runs two loops of a predetermined number of repetitions. The first loop rotates the previously selected latest image 90° that number of times. The second does the same, but by calling the ‘Timing Test 2’ shortcut. At the end it displays the number of repetitions carried out and the timing of the processing in this shortcut only (Internal Time) and in the processing carried out by calling out to the second shortcut (External Time).

Timing Test 2

This is a secondary shortcut and simply rotates the input image by 90°

Timing Test 1a

This is a primary shortcut. It runs two loops of a predetermined number of repetitions. The first loop selects and rotates the latest image 90° that number of times. The second does the same, but by calling the ‘Timing Test 2a’ shortcut. At the end it displays the number of repetitions carried out and the timing of the processing in this shortcut only (Internal Time) and in the processing carried out by calling out to the second shortcut (External Time).

Timing Test 2a

This is a secondary shortcut and simply selects the latest image and rotates it by 90°


The Testing

Each of the primary shortcuts were run on the same device with the same latest image, both without and with the show second shortcut as running option enabled, and both from the Shortcuts app home screen list of shortcuts and the editing screen for the primary shortcut. Each was also run through three times.


Primary Shortcut = 1
Display Secondary Shortcut  Whilst Running = No
Run From = Home Screen
Repetitions = 250
Internal Time = 66 seconds | 66 seconds | 66 seconds
External Time = 69 seconds | 70 seconds | 69 seconds

Primary Shortcut = 1
Display Secondary Shortcut  Whilst Running = No
Run From = Editing Screen
Repetitions = 250
Internal Time = 69 seconds | 69 seconds | 69 seconds
External Time = 71 seconds | 71 seconds | 72 seconds

Primary Shortcut = 1
Display Secondary Shortcut  Whilst Running = Yes
Run From = Home Screen
Repetitions = 250
Internal Time = 68 seconds | 69 seconds | 69 seconds
External Time = 372 seconds | 379 seconds | 387 seconds

Primary Shortcut = 1
Display Secondary Shortcut  Whilst Running = Yes
Run From = Editing Screen
Repetitions = 250
Internal Time = 65 seconds | 65 seconds | 64 seconds
External Time = 390 seconds | 388 seconds | 412 seconds

Primary Shortcut = 1a
Display Secondary Shortcut  Whilst Running = No
Run From = Home Screen
Repetitions = 250
Internal Time = 87 seconds | 87 seconds | 87 seconds
External Time = 91 seconds | 92 seconds | 91 seconds

Primary Shortcut = 1a
Display Secondary Shortcut  Whilst Running = No
Run From = Editing Screen
Repetitions = 250
Internal Time = 122 seconds | 119 seconds | 106 seconds
External Time = 111 seconds | 93 seconds | 94 seconds

Primary Shortcut = 1a
Display Secondary Shortcut  Whilst Running = Yes
Run From = Home Screen
Repetitions = 250
Internal Time = 87 seconds | 87 seconds | 87 seconds
External Time = 393 seconds | 394 seconds | 395 seconds

Primary Shortcut = 1a
Display Secondary Shortcut  Whilst Running = Yes
Run From = Editing Screen
Repetitions = 250
Internal Time = 86 seconds | 106 seconds | 119 seconds
External Time = 346 seconds | 412 seconds | 423 seconds

The Results

If you look though the figures above, the results were a little mixed in places, but here’s a few takeaways from my very limited testing and sample size … but I suspect it may well be indicative of how things run generally.

  • Shortcuts may run faster when not calling out to a secondary shortcut, but unless you have a high call out rate, you are unlikely to abbe able to identify any overhead. If you do however and speed is important, you should consolidate into a single custom shortcut.
  • Running from the list of shortcuts on the app home page is potentially a bit faster than running it from the shortcut’s editing page.
  • Showing a secondary shortcut is slower than not showing a secondary shortcut when it is called.
  • If you are showing a secondary shortcut whilst running, it is faster to run the shortcut from the primary shortcut’s editing page.
  • If you are not showing a secondary shortcut whilst running, it is faster to run the shortcut from the list of shortcuts on the app home page.

The amount of screen updating taking place is certainly a factor and as far as possible that should be minimised for maximum performance. Certainly enabling the show whilst running on the call for another shortcut should be set to off unless debugging.

Just to reiterate. The sample size here is very small as is the range of workflows tested. I haven’t compared any affects of how the shortcut is triggered beyond the two specified (I could have included from the Siri screen, from a URL call/home screen link), and I haven’t varied the devices. The information here does support what one might expect, but it is just a handful of data points at the end of the day.

My Personal View

I do use ‘helper’ shortcuts. If nothing else, they help with my re-use of certain sets of actions and they also make my more complex custom shortcuts easier to manage and maintain by abstracting out some of the complexity into smaller chunks. It’s entirely analogous to typical good practices in programming.

Anecdotally I have never seen any significant slow down from using them. I did a smaller but similar test back in the Workflow app on timing when the action step to run a Workflow was introduced and there was only a fractional slow down on that.

I would recommend adopting the practice unless you have a time/performance critical shortcut, or you need to share your solution and it is too complex/risky to share it to your target audience as multiple shortcuts.

Hope folks find the above helpful.

3 Likes