Automators 27: Shortcuts in iOS 13 - Diving into the Deep End!

1 Like

PSA: Just remember the usual advice folks…

http://shouldiinstallios13publicbeta.com/

:joy:

2 Likes

The requirement for user input to run time and location shortcuts severely limits their usefulness and is not true automation. Compared to something like Tasker on Android or Keyboard Maestro on the Mac, Apple choosing to artificially limit Shortcuts is a big disappointment. You can already use Launch Center Pro for location and time notifications to run shortcuts.

You can somewhat work around it by running a shortcut that runs on every app open - for example, if the battery is less than 50%, turn on low power mode - but that still requires actively using the device.

I can follow the first part of this, but what is it you think of as “true automation”? Do you mean something like unattended automation?

Why is the limitation artificial? Could it simply be that it is a security consideration or even something that is not yet delivered through the beta channels?

I’d be happy to be proven wrong and for the functionality to appear in later betas, but there seems to be an intentional separation between automations based on direct user input, and contextual inputs like time and location. Automations such as running a shortcut when opening an app offer an “Ask when run” toggle that can allow the user to choose whether run without directly tapping on a notification.

“True automation” is allowing the computer to fulfil tasks and duties on a user’s behalf without input, similar to a cronjob — this is possible on all other platforms, apart from iOS. If automatons can run in the background with indirect user input now (such as the previous example of running on every app open), I don’t see any differences in security considerations as long as the user is aware and in full control.

That sounds like unattended process triggering and perhaps branching, but do keep in mind automation in general terms is actually anything whereby a system does something on behalf of a person and without interaction once a trigger condition is met; which in many cases is a manual trigger. Most of my keyboard Maestro automations for example are triggered by me pressing a key combination.

Whilst I certainly appreciate the sentiment and the gist, I think the broad stroke regarding time based automations against platforms is perhaps too simplistic. There are many platforms that don’t allow for this, and even ones that do may be secured so the only those with appropriate levels of access can do so. But again, I do follow and agree with your assertion that it would be beneficial to have the option on iOS.

I’m wondering on this one. Would the fact that the trigger is, as you term, indirect make it such that the user has in fact interacted with the device at that point; such that it is unlocked, decrypted, and primed for processing user interaction. Whereas the alternative would not be the case.

I’ve no inside knowledge, but could this not still be a security consideration?

What I would say is that from my personal interactions some time ago with the Workflow team who later went on to from a core part of the Siri team, they came across as considerate and capable developers. I would be surprised if they would hold something back without a good reason to. They’re literally the ones who kind of pried off he lock on the iOS Pandora’s box for automation; though I dare say that URL schemes might have been the crowbar. I just can’t see anything but a valid reason holding them back.

In the current betas, an automation can run when dismissing or snoozing an alarm — this still runs when the device is locked (and even when the alarm is dismissed from an Apple Watch), so I don’t think there’s a technical requirement that the device be unlocked or in active use in order to run shortcuts.

Those examples are even less direct than the previous one then.

Unfortunately, I’m not touching the 13 beta until it is much more stable and I understand the Shortcuts migration and/or coexistence path is solid. I’ve too much to lose on even the public beta right now.

As such I’m not clear on if there are any limitations beyond the manual interactive elements when using the locked device triggers you referenced above.

Do you know if there any limitations over and above the interactive elements for when the device is locked vs. unlocked?

I’m just trying to tease out what, if any, other factors could be at work here that we can potentially get a handle on.

1 Like

Some kinds of unattended automation would be extremely useful for things such as “At 11pm every night, set the HomeKit scene that makes sure both of my garage doors are closed.”

Since there’s no way to automate the pathetic Home app on the Mac, using iOS would be easy, if there is a way to do it, ideally without me having to get involved at all.

Whilst not automating the app directly, perhaps a scripting plugin and HomeBridge could fulfill any burning requirements you might have?

Attended time based automations is only a limitation of Shortcuts, not Home Automations.

You can do time based unattended automations from Home app in ios without Shortcuts already, (of course you need an iPad, or a HomePod to act as a hub)

With Shortcuts you can also add some shortcut commands to Home Automations by using Home Automation > TIme Of Day > Add time conditions > Add Accessory t Scroll to bottom of Add Accessories and using add shortcut.

Oh really? I must have missed that. I’ll have to check it out when I get home (currently visiting my mom). We do have a HomePod we use for a hub, so that shouldn’t be a problem.

Thanks!