This message was deleted.

# multiplatform

[Slackbot]

This message was deleted.

[Pablichjenkov]

What do you call 5 seconds grace period? Are you using stateIn(...)

[Valeriy O.]

"when an iOS app enters the background, it has about 5 seconds to finish tasks before being suspended" - that's what I found

[Pablichjenkov]

Oh I see, I got you.
In such a case it seems is not the operating system. The reason is you might be using a coroutine scope tied to the lifecycle of the screen. So as soon as the screen goes to sleep, that scope will be cancelled.
If you want the request to be decoupled from the screen lifecycle, you would have to use viewModelScope or other custom coroutine scope tied to the Application lifecycle.

[Pablichjenkov]

If you share some code would be helpful to understand the situation better

[Moussa]

I agree with @Pablichjenkov this might be the issue. But we need to see some code to better help you.

It might also be a simple issue in iOS. In order to have any service run in the background you need to open the xcode and go to Signing and Capabilities page and enable the Background Fetch and Background processing. But again, it depend on how you are using the coroutines.

[Valeriy O.]

Thanks, for responding - it got me thinking, and I realized that the CancellationException was a red herring - because the network call was inside a collectLatest and one of the state flows was changing in response to app going into background. So this cancellation is expected and intentional.

[Valeriy O.]

The problem seemed to be related to an extra delay due to debouncing logic.... once the app is backgrounded, there was an unnecessary delay (1 second), which made the outgoing call "freeze" when iOS suspended the app. Once I removed the delay, now the call goes out more reliably. For now, this is good. I may see if I need to extend the background time...

[Valeriy O.]

BTW, it appears that the app is suspended in background in 2-3 seconds, not 5 - maybe that's the simulator, not sure.