On Android we have some code that, if some request...

# ios

[John O'Reilly]

On Android we have some code that, if some request fails while say offline, kicks off Worker to run as soon as network connection available (and that will run whether app is in foreground or background). I know you can setup background tasks on iOS but doesn't see to offer quite same functionality (and very undeterministic when task will actually run!). Is anyone using any particular approach on iOS for this?

[Daniel Seither]

There's no reliable way of running background work on iOS at a specified time (but the last I know, there isn't one on Android either, given the drastic energy saving rules that most device manufacturers add to their fork of Android by default, unless the user opts your app out of that).

For the specific case of HTTP requests, you might get away with background URL sessions, even though those are designed for doing file downloads. But yeah, the most general way of doing background work is setting up background tasks and embracing the indeterminism. It generally works well unless the device is in low energy mode or the user decides to kill your app manually in the app switcher.

[John O'Reilly]

The other difference is that the Android Worker will run when it detects network connectivity even if app is still in foreground....I could be missing something obvious but don't believe iOS background tasks will run while app is still in foreground

[Daniel Seither]

If you want the app to react to connectivity, you can either use waitsForConnectivity to allow a request to wait if there's no connectivity instead of failing immediately. If you just want to monitor connectivity, NWPathMonitor is the tool of choice.

[John O'Reilly]

The connectivity part is fine I think.....it's more about fact that we could be in foreground or background at that point

[Pearce Keesling]

I believe you can specify requirements for background task akin to work manager (like network). I'm mobile ATM so I can't look up the specifics, but there is a experimental library by the people behind store5 called meeseeks that abstracts to a common kmp interface so I'll bet you could find it in their source code. Or apple docs probably mention it if you're doing it in swift

[F]

@John O'Reilly here you go: https://github.com/matt-ramotar/meeseeks. On Ios it falls back to BGTaskScheduler. Big thanks to @Matthew Ramotar for the hard work.

[John O'Reilly]

Thanks, will take a look

[John O'Reilly]

It looks like that still uses BGTaskScheduler under the hood

[John O'Reilly]

which is still needed of course for actual background work on iOS....I guess I'm trying to get my head around how this can be combined with executing deferred work if in foreground or background (in scenario for example where we're waiting for network connection)

[curioustechizen]

I'm also looking for an answer to the original question. Consider a simple scenario of syncing some data to my server.

With WorkManager, I can create a worker and schedule it such that
• The sync happens immediately if there is network connectivity
• If the sync starts and the app enters the background, the sync operation continues
• If there is no network connectivity right now, and the user continues using my app, when network connectivity is restored, the sync operation runs (even if my app is still in the foreground)
• If there is no network connectivity right now and the my app enters the background, sometime later when network connectivity is restored, the sync operation runs (even if my app is in the background or the device is restarted).

[John O'Reilly]

@curioustechizen I have exactly the same requirement

[curioustechizen]

On iOS I think all of this is possible (maybe) but not with a single API. For example
• the second bullet point can be accomplished with beginBackgroundTask or some combination of NSURLSession or whatever.
• Only the last bullet point can be achieved with BGTaskScheduler
So you need to use a combination of several approaches to achieve the same goal.

[John O'Reilly]

I've been combing the 2 of those elsewhere but don't think it fully solves this issue....at least in terms of when the background task gets executed. You'd need to do something where you separately monitor network connectivity and background state of app......if in foreground when connected then just run necessary logic (along probably with use of beginBackgroundTask) .....if in background then schedule background task (but no guarantees as to when that will run!)

[curioustechizen]

Exactly.

[Matthew Ramotar]

Hey all - Meeseeks + Store should effectively address these requirements. This RFC has details https://github.com/MobileNativeFoundation/Store/pull/697

[Matthew Ramotar]

Not sure where Meeseeks will ultimately live. Still early, but would love feedback/requests/contributions. Definitely let me know if I am not understanding what you need

[John O'Reilly]

Thanks @Matthew Ramotar.....I'm still a little unclear on how implementing scheme mentioned above would work in practice but will definitely keep a close eye on this!