Broken Shortcut fixed with... Quick Look?

Well, this one goes in the “mildly infuriating” category.

I have a pretty complicated set of shortcuts I use to generate templates for journalling. They work perfectly fine on my iPhone, and last I checked (months ago, probably), they worked on my iPad Pro.

Now that I have a fancy new magic keyboard, I wanted to do this journalling on my iPad again. So, I ran the shortcut this morning—only to find that it crashed, every time, persisting after a reboot.

Confused, I ran it on my iPhone. It worked like a charm.

So, I set about to find and squash whatever bug caused it to fail on my iPad Pro. Naturally, I put a few Quick Look actions in to see what kind of inputs were being passed through the various actions… and suddenly it worked, up until the point that I stopped Quick Look-ing.

So I add a few more Quick Look actions and suddenly the whole Shortcut works perfectly. Wtf?

The worst part: I remove them and it breaks again!

Meanwhile they still work on the iPhone.

Damned computers. Has anyone else experienced something like this? I worry that a delete-and-restore of all my shortcuts is in order…

I don’t know if this is correct or just plain wrong, but I think that it may be the cause.

Maybe Shortcuts does some things asynchronously, meaning in another thread or even process so the main thread is not blocked by the operation (and for example freezes the UI). Maybe there is some operation that is done like that and finishes its job before the main thread accesses the result and everything works as expected. But there may be cases where the operation hasn’t finished and the main thread accesses the result, but finds an empty value. And from there things start rolling. It tries to use the empty result, but fails, does something else wrong, and the next thing wrong and so on until the process crashes/freezes/needs too much memory and iOS says “nope, I’m going to close you now”.

So in short, it is probably a race condition that fails without the QuickLook and succeeds with the QuickLook because the main thread waits for it.

To fix this you could try to reinstall the app. Resetting the shortcuts database alone wouldn’t really help probably. If this doesn’t help, then you are stuck with the QuickLooks in the shortcut.

1 Like

Interesting theory. The iPad’s faster processor would explain why it only fails on that device.

Maybe I could use Wait actions in lieu of Quick Look.

Odd, though, that it used to work on the same iPad and now it doesn’t. It’s possible that I haven’t used these since iPadOS 13, so perhaps Shortcuts got faster with that update.

The two devices have different hardware, and different operating systems. It could be you are hitting an OS/app bug, an issue with the hardware (timings, utilisation bug, etc.), or some local corruption of something Shortcuts is utilising.

Here are several things you could try, that may or may not achieve an increased level of insight, a workaround, or a deeper understanding of how frustrating technology can be.

  • Try rebooting the iPad.
    • Always reboot when something odd happens.
  • Check you are running the latest public OS releases on both devices.
    • How often do we really know every fix that’s gone into an OS release?
  • Check if other shortcuts are affected.
    • This could help you towards identifying if the shortcut, app/OS or device is the source.
  • Check if modifying the shortcut on different devices changes the behaviour.
    • Maybe it isn’t a run bug so much as a bug introduced through editing?
  • Share the shortcut by URL, delete it in the app, re-add it, re-try it.
    • If something is locally corrupt, this could provide a cleaner refresh than just editing it.
  • Try adding other non-invasive actions as a workaround.
    • Try something other than QuickLook such as a get content or location or a wait.
    • Does that affect the behaviour too?
    • If so, it could lend some credence to the timing/race condition hypothesis.
  • Try splitting your shortcut into smaller, simpler parts.
    • One aspect to this is that you can test these independently.
    • Smaller chunks are easier to maintain - ask any developer.
    • Rebuilding in this way may even workaround whatever the underlying issue is.
  • Try rebuilding your shortcut.
    • I realise it is long and complex, but I’ve seen numerous accounts from people that this has resolved strange behaviour with shortcuts and I’ve had an experience once where this was the case.
    • Build it a bit at a time.

I hope that gives you some ideas for ways forward.


Thanks @sylumer. That is a great general approach to Shortcuts troubleshooting. I hope you have it saved to text expansion or published to your blog!

I have continued to troubleshoot this. A few Wait 1 second... actions seem to prevent it from crashing if I run the shortcut from Shortcuts. If I run it from the homescreen widget, though, it still crashes. Again, it’s odd that this previously worked on this iPad and continues to work on the iPhone. Such a curious case.

I am tempted to try the backup, delete, and re-add route. However, I have made this shortcut a little object-oriented already… the main shortcut references about 3-4 others, each of which also reference 2-3 others. Anyone have any experience with restoring these kinds of shortcuts? How does the import process deal with these shortcut method/subroutine calls? I imagine I will have to remember what went where and manually re-stitch it back together.

About the shortcut dependencies: I don’t know how it works in iOS 13, but in iOS 12 it remembered the shortcut name. If it couldn’t find one with the saved name, it didn’t display it, but after installing/renaming a shortcut to the missing one, the action again displayed the referenced shortcut. This has worked as long as the field in the action wasn’t changed.

1 Like

Ah, now that you mention it, I remember seeing the same behaviour once before. Thanks for the response!

Great. That means that you can backup and delete a bunch of shortcuts that reference one another, and the order you restore them in doesn’t matter as long as the names all stay the same.

I shall try this when I get a moment!

You may have already fixed it - but I had a similar experience with some of my more complicated shortcuts. They were working fine, but just started crashing one day (maybe it was after an update - but I don’t recall).

For me, running the shortcut without displaying the actions seemed to fix it. That is, opening the shortcut where I can see the actions, and running it would cause it to crash, but running the shortcut from the main ‘My Shortcuts’ and not displaying the actions would work. Similarly, when using one shortcut to open another, I had better success in turning off the ‘Show While Running’ feature. The correlation seemed to be, the longer the shortcut takes to run, the more likely it was to crash.

Even now, the same shortcuts crash when pressing the ‘play button’ inside the shortcut, but will run successfully when tapping the tile in ‘My Shortcuts’.

Interesting. Mine works when I run it from the widget, but not from within Shortcuts (whether I have the shortcut in question open or I just tap the “play” button).

Weird behaviour. It’s probably just a bug that’ll eventually get fixed…