5 ms·

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

Mailtemi 8y ago
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.
- guzik 8y ago
  For some cases, there is a 100% guarantee, especially for Bluetooth. I think we never lost a >sample< in the background so far (where I can't say the same for the Android).
rjzzleep 8y ago
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.
toast0 8y ago
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.
- izacus 8y ago
  > 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. This is why Android allows you to still run unrestricted if you show a persistent notification (as long as there's enough RAM). The whole point of the link you're commenting on is that some OEMs break this API.
wingerlang 8y ago
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.
- izacus 8y ago
  > 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. That hasn't been true for some versions now. Yes, there's a mode where apps can run in the background without restrictions, but that hasn't been true for most apps for years now.
lstamour 8y ago
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-to-wakeup-suspended-app-in-ios-without-user-or-server-interventio 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 http://www.sleepcycle.com
- scarface74 8y ago
  And... well, it rarely allows apps that duplicate built-in functionality on the App Store. This is such an old meme and there are plenty of existence proofs that it isn’t true. There are third party apps for every single app on iOS including navigation, podcasts, mail, music players, calendars, password managers (with integration APIs specifically for them as of iOS 12), weather, notes, etc.
  - lstamour 8y ago
    There are rules: Unacceptable: https://developer.apple.com/app-store/review/guidelines/#unacceptable https://developer.apple.com/app-store/review/guidelines/#una... Spam: https://developer.apple.com/app-store/review/guidelines/#spam https://developer.apple.com/app-store/review/guidelines/#spa... Copycats: https://developer.apple.com/app-store/review/guidelines/#copycats https://developer.apple.com/app-store/review/guidelines/#cop... You can't make your own App Store, you can't ship your own browser -- https://developer.apple.com/app-store/review/guidelines/#software-requirements https://developer.apple.com/app-store/review/guidelines/#sof... -- you have to use HLS, you can't use background features except for approved categories: "VoIP, audio playback, location, task completion, local notifications". "Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected." I'm not saying the rules aren't much improved from what they used to be -- it's been years since the simple advice was "don't ship something we ship," but ... at its core, it's still somewhat true. You have to ship an original app -- and all of the app categories you mentioned have truly original apps on the App Store already.
izacus 8y ago
> 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.
the_gipsy 8y ago
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.

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.

guzik 8y ago
For some cases, there is a 100% guarantee, especially for Bluetooth. I think we never lost a >sample< in the background so far (where I can't say the same for the Android).

rjzzleep 8y ago

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.

toast0 8y ago

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.

izacus 8y ago
> 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. This is why Android allows you to still run unrestricted if you show a persistent notification (as long as there's enough RAM). The whole point of the link you're commenting on is that some OEMs break this API.

wingerlang 8y ago

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.

izacus 8y ago
> 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. That hasn't been true for some versions now. Yes, there's a mode where apps can run in the background without restrictions, but that hasn't been true for most apps for years now.

lstamour 8y ago

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-to-wakeup-suspended-app-in-ios-without-user-or-server-interventio 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 http://www.sleepcycle.com

scarface74 8y ago
And... well, it rarely allows apps that duplicate built-in functionality on the App Store. This is such an old meme and there are plenty of existence proofs that it isn’t true. There are third party apps for every single app on iOS including navigation, podcasts, mail, music players, calendars, password managers (with integration APIs specifically for them as of iOS 12), weather, notes, etc.
- lstamour 8y ago
  There are rules: Unacceptable: https://developer.apple.com/app-store/review/guidelines/#unacceptable https://developer.apple.com/app-store/review/guidelines/#una... Spam: https://developer.apple.com/app-store/review/guidelines/#spam https://developer.apple.com/app-store/review/guidelines/#spa... Copycats: https://developer.apple.com/app-store/review/guidelines/#copycats https://developer.apple.com/app-store/review/guidelines/#cop... You can't make your own App Store, you can't ship your own browser -- https://developer.apple.com/app-store/review/guidelines/#software-requirements https://developer.apple.com/app-store/review/guidelines/#sof... -- you have to use HLS, you can't use background features except for approved categories: "VoIP, audio playback, location, task completion, local notifications". "Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected." I'm not saying the rules aren't much improved from what they used to be -- it's been years since the simple advice was "don't ship something we ship," but ... at its core, it's still somewhat true. You have to ship an original app -- and all of the app categories you mentioned have truly original apps on the App Store already.

izacus 8y ago

> 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.

the_gipsy 8y ago

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.