> I haven't followed the scene closely, but isn't it the same behavior as Apple? Can you even do background tasks in iOS?

This is about OEMs breaking the guarantees of the OS. Yes, Apple restricts your background processing time, but it will still reliably deliver APNS push notifications or keep your running if it's actively providing turn-by-turn nav, background calls or something that API deliberately allows you to do.

With Android, the issue is that OEMs listed on that site break guarantees that Android API gives you. Your app suddently stops receiveing push notifications because it's not on the whitelisted "golden set" - breaking smaller messengers like Signal. Or the OEM "battery saver" kills off Google Maps while it's running turn-by-turn during your drive. Issues like that, which are significantly different than having Doze mode save your battery. Or you schedule a sync job once per day on Wifi (which JobScheduler API gives you the ability to do) and Huawei decides to just break the API and not run it.

As a developer, you are aware of the limitations so that you can work with them. E.g. when your app is closing down you have X ms to wrap your work up. But you can also request a longer task, or request the app to work in the background in certain scenarios. And as there is only 'one iOS', it will always work as 'agreed on'.

It seems like in Android the developer just assumes their app will be able to run in the background, except some versions just decides to kill it based on their own agendas.

You can, for certain classes of application, and for certain types of tasks (like background downloads). It’s entirely managed by the OS, and is often reduced or suspended entirely under Low Power mode. But Apple allows for other kinds of wake notifications and is usually pretty good with Push Notifications due to carrier partnerships. That said, Apple does intentionally make certain apps a lot harder: https://stackoverflow.com/questions/35388086/is-there-a-way-... And... well, it rarely allows apps that duplicate built-in functionality on the App Store. So most iOS users stick to default apps. But at least one app takes advantage of Apple allowing the microphone in the background to create a “smart” alarm clock which Apple has featured as the App of the Day: Sleep Cycle alarm clock http://www.sleepcycle.com

In iOS, you have a few narrow cases where you're allowed to run in the background; some of which are specified to only maybe run.

In Android, you're technically allowed to run whenever you feel like it, but starting with Android 6, Google started limits, but I don't think apps get much feedback about when they might run, or if they can access the network when they do run. And the multitude of OEMs that are all dieing to make their product stick out means it's really a crapshoot; some oems were trying to do this before Google's release of the feature, some enable Google's version, but very aggressively, etc.

I understand the intent of these features, but there really needs to be a better way. Some apps do real, useful, work in the background, and it's not great for users when that can't happen. Many apps should probably only run when they're in the foreground. Either way, the app should be informed, so it can do the best it can, including informing users why it's not working and being able to direct users to where they can fix it, if desired.

Apple is actually more aggressive in terms of what's allowed in the background AFAIR.

But they have an arguably better push notification system which seems to use less battery and work better with sleeping apps.

The apps are not allowed to do background process. But can register a callback to be called when is in background. But there is no guarantee it will be called for sure.

You don’t need to, most of the time.

For example, push notifications are handled by one system process, and will only open the relevant app when the user clicks it.