iOS 13 Automatic running of shortcuts require clicking run still?

I was very excited about the new automation tab to schedule stuff in iOS 13. Well excitement is dying, just tried to send myself a message on a certain time just for fun, well I still need to click that damn “run” in notification. I thought I was supposed to do this in the backround in iOS 13, even dimming my screen while connecting airpods shows that “run” notification. Why have time based automation if it DOES NOT RUN? I understand with messages since you probably would not want people to become spam machines but dimming the screen??!! really!!

Very disapointed, in the end this is just reminders for shortcuts not real automation.

There should be the option to toggle that off, however if your shortcut requires input you can’t do that.

Yeah I should wait before I rant (but I get very excited by the potential possibilities.)

It is probably buggy right now since I got the option you/Rosemary mentioned when I create an automation with just “send message” and “When open app” as trigger, then it works. With bluetooth as a trigger it does not work, nor does “when I arrive/leave”. So at the moment it seems limited to triggers where you are currently logged into your phone. I hope that will not be the only option for automatic running of shortcuts.

Ok really got my teeth into this now. So here is the thing - no trigger will currently run in the background without the user being logged in/authenticated against the phone/device.

So for “when opening app” trigger it will work because you are authenticated and infront of the phone. But for any other trigger like bluetooth, time of day etc no, you will get the usual notification. So there dreams crushed, Apples obsession with security.

I dont think they will allow anything else in the official release, this is on purpose and not a bug.

2 Likes

:thinking: that doesn’t quite match to what I’ve seen discussed elsewhere.

For example.

Also, this is very first release of the developer beta. Expectations may not be met yet, but that is a very long way from saying they won’t. There are certainly many revision iterations ahead and a great many things could change between now and the master release.

Of course, what might be useful is noting the radars for any deficiencies you might have recognised and reported as part of your beta testing so that other beta testers can likewise support them and improve the chances that Apple will recognise them as as issues to be addressed.

1 Like

That is because you have authenticated, you picked up the phone and you turned of the alarm. Find a use case where the user has not interacted with the phone and a shortcut has run, you wont find any because it will not be allowed, not now not after the release. This is how it was implemented.

Are you sure you have to authenticate to a device to turn the alarm off?

1 Like

Good point but you have interacted with your device. I will keep my fingers crossed but i dont think its random that no other trigger works except two and both require user interaction. I can imagine this not being a security issue rather running backround processes issue.

It seems, so, that there’s nothing new under the sun.

Bummer.

I’ve playing with the beta and I can confirm this. User input is always needed, one way or another.

I suspect this is due to power consumption. To have a daemon in the background always running will drain the battery to much. They took the route then you wake your phone it will check if there are any valid shortcuts available. It sucks, maybe they will make a low power daemon in the future, but I don’t think they will this release.

Sorry, but I really don’t believe that this is the reason. Cron daemon itself is very efficient in resource usage. What can drain battery is running shortcuts that are resource-intensive very frequently, or having lots of shortcuts. But these are a user’s choice.

iOS is more than you see as an end user, but let’s just take reminders as an example for a moment. It can remind you of something at a specific time, or at a specific place. The OS must therefore be polling time and location.

If Shortcuts does in fact not do this in iOS13, and I would reiterate this is beta 1 and there is a feedback mechanism so you should be feeding this stuff back as part of taking part in the beta testing, then it wouldn’t be because of power consumption as the OS is already doing that stuff.

Security is always a consideration, and it may well be that this is a wider constraint the developers are working to. Then again. Maybe it isn’t. Maybe they just haven’t fully developed this aspect of the system yet.

1 Like

If its only job is to schedule stuff to do on a certain time then yes. We are in another ball park here, to have the device constantly listen for nfc input, bluetooth input, location changes, wifi changes. This daemon has to tap into all those services. It can be done sure, but when I think about how iOS currently works, no apps except perhaps IFTTT does anything in the backround, it is limited for a reason and that reason is power consumption.

If they choose to implement this it they will probably ship shortcuts along with making it a part of the list that shows what apps are drawing power from your phone. the more I think about it I do not think this will happen in this release.

Except we are not talking about only location. We are talking about bluetooth, location, wi-fi, nfc. Those triggers are 10% the other 90% comes after and that is actually making a flow execute something in an app. This spells trouble and I really dont think it is possible they way iOS works right now. Just to automaticly open a closed app while the phone is off is not possible right now, it ties into background Refresh and alot of complexity.

Maybe they figured all this out in iOS13 and it will show up in later beta, but the more I think about it the more I doubt it.

Modern i*OS devices contain Bluetooth LE (low energy) chips. Power drain is minimal. When you turn on a paired device it auto connects to the device. There is already Bluetooth polling going on whenever you have Bluetooth enabled.

Location is covered by both GPS and WiFi (GPS assist (as well as cellular location when available to a device) has been in place for most of the life of the iPhone). Reminders already can remind at location. Known wifi networks are automatically connected to. There is already location and WiFi based polling going on.

Background NFC polling was introduced in the last round of iPhone. Older models with NFC have to be set to actively poll because of the configuration, and I think I recall reading something relating to the particular chipset. NFC polling in the background is therefore also already going on.

Even if one of these wasn’t “a thing”, it would not preclude the others. They may all be in a bucket of triggers, but there’s no basis to take it that they cannot all be treated differently. You can absolutely have something that checks for X and Y, but not X; even though X, Y, and Z are all broadly in the same category.

If there is no authentication, wouldn’t someone nefarious will run some shortcuts unknown to you and cause harm? I think it is more of a security concern, not a battery concerns.

Well my point was not that those services does not exist I know they do since I use them. My point was also not that this is impossible, it is. My point being building a daemon/app that listens to all those services and execute operations in other applications has power implications. Especially if you let the user control this on a schedule with no limits. They solved this by limiting it to making it reminders with shortcuts. They wont make this run in the backround but maybe I will eat my own words…

https://developer.apple.com/library/archive/documentation/Performance/Conceptual/EnergyGuide-iOS/NotificationBestPractices.html#//apple_ref/doc/uid/TP40015243-CH26-SW1

They covered that by “allow untrusted shortcuts”

And my point would be that these periodic queries are already happening at the OS level rather than the app level, and that Shortcuts is now hooked directly in at the OS level. On that basis no new apps, daemons or services would necessarily be required if the OS level operations can be leveraged in the right way.