>> "Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks"
iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does.
_Example 1:_ fetch email (without push) for any non-Apple email app will not work reliably, because the app can get killed. You have to rely on Apple's built-in notification support, but this means that a server-side connection needs to be maintained.
As a result, if you want reliable mail delivery without using Apple's Mail, you have no way but to share your username and password with third-party app servers which you don't trust. For example: Airmail or Canary Mail.
Of course, Apple's own Mail has no such restrictions because it is a special part of the OS. This is no surprise however, since Apple has been actively hostile to alternatives for their own apps.
_Example 2:_ backing up photos and videos (with Dropbox, Google Drive, etc).
There's no way to ensure that your photos get backed up without making an effort to keep the app active, in the foreground, with the screen on, or without the app developer abusing the location API, which Dropbox has been doing.
Isn't that the same kind of excuse-making you're dinging the Android world for? "OK, fine, the experience sucks by default but it works fine if you just do this and this and this". Android has all those sorts of features too.
It's just a hard problem. App developers are bad, and do bad things. OSes can't protect against all bad behavior. Phone manufacturers do have a vested interest in protecting their users from bad apps. Users do actually benefit from this on balance.
Users don't benefit from lazy ham-fisted hacks. There is no benefit to killing an app without notifying it in any way, or killing a background app that is using 0.2% of available memory and 0.0% of CPU just because it has been open for a long time.
> There is no benefit to killing an app without notifying it in any way
Sigh. There can be on balance. Bad apps get killed, users don't see as many dead phones. A few false positives get killed too, to great annoyance of their authors (and potentially users, but it's mostly the app authors upset here, be honest).
Whether that's worth it or not depends on the numbers involved, not your personal definition for "ham-fisted" or the existence of a better solution.
All I'm saying is that app vendors aren't the only parties involved here, and that the problem being addressed is real, and quite important.
Can you explain the advantage in killing the app without notifying it? You're going to kill the app because it's consuming 500MB of memory, fine, send it SIGTERM or equivalent and then give it two minutes to orderly shut down before you send SIGKILL. Not doing it that way has a cost and no apparent benefit to "balance" it with.
> Can you explain the advantage in killing the app without notifying it?
Um.. "The app uses less energy." Is that a serious question?
Again you seem to be arguing that there are better ways to solve this problem. There no doubt are. That doesn't mean the existing solution doesn't have value.
> Um.. "The app uses less energy." Is that a serious question?
For the two minutes between when you ask it to shut down and when you kill it? Even assuming that's a meaningful amount of energy savings (probably not), you could just kill it at the same time as you would have regardless but ask it to shut down two minutes before that.
> Again you seem to be arguing that there are better ways to solve this problem. There no doubt are. That doesn't mean the existing solution doesn't have value.
All value is relative. You can make anything sound good by comparing it to something arbitrarily worse, but that doesn't prove anything. Riding a donkey is better than walking on foot but I wouldn't want to have to travel from New York to LA on one.
The question is whether it's better than the good known existing alternatives, not whether it's better than the bad ones.
Background refresh doesn't work if the user "force closes" the app, i.e. they go to the task manager and swipe it away. Anecdotally, it's super common for people to do this as they have read somewhere that it helps battery life (not untrue, but also not really effective). So if you were writing an e-mail app you wouldn't be able to guarantee that you'll actually deliver e-mail to users, which feels kind of important.
But it comes down to this: if a user explicitly kills an app, should it keep running in the background?
If the answer is "yes", then what you're really saying is users shouldn't be able to kill apps if the app doesn't want to be killed.
I get that some users don't know what killing an app means but do it anyway for some reason.
But that's not a problem with background refresh. E.g., maybe iOS could warn/explain about the implications of killing an app (with a checkbox so you can opt-out of further warnings).
Edit: just realized I left the word “not” out just above, which reverses it’s meaning
The problem is that nothing is self-evident. An app that sends remote notifications to notify you of an e-mail looks exactly the same as one that locally generates a notification as a result of background processing. But the former will work after being swiped away from the app switcher and the latter won't.
I just don't think it's reasonable to expect the average use to "get" that.
Sounds like user error at that point, I would popup a message after the next force quit saying that doing so will pause email notification until the app is reopened.
How on earth would that be a feature? If you have to show a popup on launch for something like that then it's a user experience failure, no matter if it's your fault or Apple's. Either way, it means the user has to treat your app differently to every other app on their phone. That is bad.
"It's user error" is a weak excuse if any kind of significant number of users are doing it.
An app that has been force quit can still receive remote notifications just fine. I don't think the average users knowledge is so nuanced that they understand the distinction between a remotely-sent notification that always appears and a locally generated one that's the result of a background process that doesn't.
I think most users expect to receive notifications from apps (especially communication apps) even if the app doesn't appear in the App Switcher carousel. What people expect from their phones and computers are wildly different here.
The feature in my mind was an easy way to temp silence an app without going into settings.
I still think of it as user error if they force quit an app but still expect it to run in the background. Why force quit it?
I could see how it could be a UX failure for the OS but I don't think we can blame the dev for that. Apple should clarify what force quit does. I think the advent of webapps that don't really exist on your phone at all also causes confusion: the app has been updated with more content each time you use it, even if it's not running in the background, but to the user that's indistinguishable from the app running in the background.
iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does.
_Example 1:_ fetch email (without push) for any non-Apple email app will not work reliably, because the app can get killed. You have to rely on Apple's built-in notification support, but this means that a server-side connection needs to be maintained.
As a result, if you want reliable mail delivery without using Apple's Mail, you have no way but to share your username and password with third-party app servers which you don't trust. For example: Airmail or Canary Mail.
Of course, Apple's own Mail has no such restrictions because it is a special part of the OS. This is no surprise however, since Apple has been actively hostile to alternatives for their own apps.
_Example 2:_ backing up photos and videos (with Dropbox, Google Drive, etc).
There's no way to ensure that your photos get backed up without making an effort to keep the app active, in the foreground, with the screen on, or without the app developer abusing the location API, which Dropbox has been doing.