Apple Reimbursing Customers Who Recently Purchased Now-Acquired App Workflow

Jailbreak is your friend

No it's not. It may allow you to do more with the device, but it also opens it up to severe security concerns.

So much potential with this app. Unfortunately, two of the immediate work flows I thought of in an effort to eliminate taps, can't be done.

* Turn on low power mode
* Close all open apps

I would hope that with the acquisition maybe a deeper integration w/ iOS would occur but I suppose if that were the case then Apple would just build these features right into iOS.

*and before anyone starts harping on me about why open apps don't matter, I don't care, I like them closed

Anyone got some good workflows to share?

Check out the archive at MacStories ('http://macstories.net'). Federico Viticci is one of the best sources anywhere on Workflow. There's more in the Club MacStories premium site, but plenty of free stuff too. And check out their Canvas podcast ('https://www.macstories.net/linked/canvas-episode-29-workflow-magic-variables/').

Ok very nice on them.

This thread is strangely devoid of hate.

My point is, I've seen no evidence that you can actually stop a background process that is permitted by iOS by deleting its saved state, but I've certainly seen evidence that you can't. Further any background task that iOS does allow should be terminable in the app itself. However, it can be useful to delete the saved state of an app that is stuck. I've seen that a few times.

There's definitely scenarios where people have been dealing with various apps that way. Sometimes Facebook or WhatsApp or some mapping/navigation apps can do things in the background and people would close them out to stop that activity. Certainly something that has come up before in various discussions about this kind of thing and various apps (again, Facebook probably being one of the more famous/notorious ones in relation to that, at least for some people).

I'd already read most of this and noted that it does not refer to the recent apps list at all. In fact it says that even a "terminated" app (how this is defined I am not sure) is woken and placed in the background if it needs to receive a location service. It says, "iOS supports the delivery of location events to apps that are suspended or no longer running." Even without being totally certain of the distinction between "terminated" and "no longer running" (if any), it's pretty clear that apps are allowed to process events when as far as the user knows the app is inactive. The user does have the option of disabling background event handling either specifically for an app or globally but I find nothing to suggest that they can do it any other way.
[doublepost=1491431713][/doublepost]

Apple doesn't make this as clear as they could to the user. This leads to a lot of speculation about how much control the user has over OS functions and how much they need to intervene to optimize performance. Apple's clear philosophy is "we took care of that, don't worry about it."

Right, with the user not allowing Background App refresh enabled for a particular app or in general then an app is only able to perform something if it's in foreground or background (suspended or not), but not if it's actually closed/terminated.

All this also only applies to this one particular location service aspect of it, while there are other ones related to VoIP, audio playback, and a few others that can allow apps to perform tasks in the background if they have been used at some point and are simply in background (suspended or otherwise), but not if they are completely closed (either haven't been launched or have been closed/terminated).

Basically that is to say that there are certainly circumstances where removing the app from the recent apps list to actually fully close/terminate it can have an effect of stopping it from doing something in the background which it otherwise might be doing.

"Note: If your app is terminated either by a user or by the system, the system doesn’t automatically restart your app when new location updates arrive. A user must explicitly relaunch your app before the delivery of location updates resumes. The only way to have your app relaunched automatically is to use region monitoring or the significant-change location service.

However, when a user disables the Background App Refresh setting either globally or specifically for your app, the system doesn’t relaunch your app for any location events, including significant-change or region monitoring events. Further, while Background App Refresh is off your app won’t receive significant-change or region monitoring events even when it's in the foreground. When a user reenables Background App Refresh for your app, Core Location restores all background services, including any previously registered regions."

Well, what I'm saying is that there are certain system level services and apps that are simply part of the device itself inherent to built-in functionalities of the device and iOS (functionalities like phone, contacts, messages, mail, calendar, and a number of others) that are essentially more or less part of the OS itself and thus have different privileges and ways of running compared to pretty much any other app, and in particular to essentially any third party app.

In the case of third party apps, they can perform various functions in the background if they have been opened before but not might be currently used, either directly through background service abilities (that various VoIP, location, music/audio, and some other apps can take advantage of) or through what Background App Refresh can allow for. However, if those apps are "closed" (basically either haven't been running since the last time the device restarted or have been cleared away from the recent apps list) then they can't make use of those background privileges at that time.

I'm not a coder but from what I have read, apps that take advantage of the defined background services in iOS are all treated the same way. They can use those background services for specifically allowed purposes, and are suspended when that service is completed. I am not sure but I suppose it is possible that some apps using a background service while otherwise suspended might cancel that usage if the saved state is deleted (though I know some definitely do not). Even if that is the case I still don't see any point in routinely deleting those saved states. This mythological maintenance method is based on the misapprehension that these apps are "running" otherwise.

It's difficult to test this easily with many apps, but it can be done with Mail at least. Delete Mail's suspended state then send yourself a push email from another device. The last time I tried this myself the email notification displayed on the iOS device the same as if I hadn't deleted the saved state. You could try this in Messages too I suppose or any app that includes a notification widget.

Well, Mail and realistically even Messages are more along the lines of built-in system services/apps, so they are in a somewhat different category that most other apps when it comes to this kind of thing. Furthermore, notifications come through ANPS, which is a system service for push notifications, and that doesn't rely on an app running or being suspended or anything like that.

*and before anyone starts harping on me about why open apps don't matter, I don't care, I like them closed

"open" apps seem to use more ram. on my 5s in safari the "dictation"-microphone often went greyed out - force-closing a few apps in the task viewer remedied that. i guess this is no more the case with ios 10 but that doesn't mean those suspended apps don't use any ram.