Example 2 should work fine with the background mode declared [2]
Both these APIs are pretty old... is there something I'm missing?
[1] https://developer.apple.com/documentation/uikit/core_app/man...
[2] https://developer.apple.com/documentation/foundation/url_loa...
2. no, it does not work for background uploads, here are screenshots of Dropbox's configuration and Dropbox is not alone in doing this ;-)
Step 1: https://www.dropbox.com/s/b7vylhljg2fwtb8/2019-01-14%2015.02...
Step 2: https://www.dropbox.com/s/c9knz2zz6zs28l5/2019-01-14%2015.04...
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.
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.
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.
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.
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
I just don't think it's reasonable to expect the average use to "get" that.
There you go: bug turned into a feature.
"It's user error" is a weak excuse if any kind of significant number of users are doing it.
If I force quit an app on my computer, it no longer runs and does things.
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.