[untog]

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.

[jmull]

I see. I can see the issue.

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

[untog]

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.

[jmull]

I agree the users shouldn’t be the ones worrying about the subtlties. It’s we developers.

[vxNsr]

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.

There you go: bug turned into a feature.

[untog]

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.

[madeofpalk]

If a user 'force quits' an app, don't they expect that it won't be running in the background receiving app content updates?

If I force quit an app on my computer, it no longer runs and does things.

[untog]

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.

[panopticon]

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.

[vxNsr]

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.