4 ms·
>> "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 whit
by bad_user 8y ago
>> "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.
- sudhirj 8y agoExample 1 has been solved with Background App Refresh a long time ago [1] 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/managing_your_app_s_life_cycle/preparing_your_app_to_run_in_the_background/updating_your_app_with_background_app_refresh https://developer.apple.com/documentation/uikit/core_app/man... [2] https://developer.apple.com/documentation/foundation/url_loading_system/downloading_files_in_the_background https://developer.apple.com/documentation/foundation/url_loa...
- bad_user 8y ago1. no, does not work — email clients warn users that if the app gets killed then notifications will stop and yes, I tested this quite recently 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.34.png?dl=0 https://www.dropbox.com/s/b7vylhljg2fwtb8/2019-01-14%2015.02... Step 2: https://www.dropbox.com/s/c9knz2zz6zs28l5/2019-01-14%2015.04.32.png?dl=0 https://www.dropbox.com/s/c9knz2zz6zs28l5/2019-01-14%2015.04...
- ajross 8y agoIsn'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.
- AnthonyMouse 8y ago> 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.
- ajross 8y ago> 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.
- AnthonyMouse 8y agoCan 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.
- 8y ago
- alliecat 8y agoBackground App Refresh has been a thing for ages - It took them a while, but Apple solved this problem in a super user-friendly manner.
- bad_user 8y agoNo, they haven't solved it.
- jmull 8y agoI’m curious: why doesn’t background refresh solve the problem?
- untog 8y agoBackground 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.
- vxNsr 8y agoSounds 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. There you go: bug turned into a feature.
- untog 8y agoHow 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.