News: BackgroundTasks are coming to iOS

[atulmy]

Available for following:

• iOS 13.0+Beta
• UIKit for Mac 13.0+Beta
• tvOS 13.0+Beta

BackgroundTasks
Request the system to launch your app in the background to run tasks.

Overview
Use the BackgroundTasks framework to keep your app content up to date and run tasks requiring minutes to complete while your app is in the background. Longer tasks can optionally require a powered device and network connectivity.

Register launch handlers for tasks when the app launches and schedule them as required. The system will launch your app in the background and execute the tasks.

Read more:
https://developer.apple.com/documentation/backgroundtasks

[christocracy]

Thanks, looks interesting. This will definitely be implemented.

[christocracy]

It looks similar to Android’s JobScheduler. It’s a replacement for the iOS background-fetch api — fetch is disabled when this new api is implemented.

[cristianoccazinsp]

That is amazing news.

[whalemare]

We waiting, thank you

[Dexwell]

Would absolutely love this—please keep us posted!

[christocracy]

@Dexwell start watching this Github repo for updates.

[aniciom]

That would be amazing

[DartMen]

May I assume this implementation will find its way into flutter_background_fetch as well?

[christocracy]

@DartMen React Native, Cordova and Flutter all share the same native libraries (TSBackgroundFetch.framework for iOS; tsbackgroundfetch.aar for Android).

So yes. When it works for one, it works for all.

[cesarve77]

2 questions (thanks in advance)

is possible to run background fetch for IOS while the app is terminated?
Headless is just for android, right?

[christocracy]

is possible to run background fetch for IOS while the app is terminated?

If the OS terminated the app, fetch continues to run. If user terminates the iOS app, fetch events halt.

Headless is just for android, right?

Yes. iOS has no such concept of "Headless", nor will it ever.

[cristianoccazinsp]

@christocracy Do you anticipate a complicated API change for this? Most importantly, support for both iOS 13 and iOS < 13?

iPhone 11 is now out, and iOS 13 is rolling out to most phones already, so I believe this is going to be come more important shortly.

Lastly, I read somewhere a long time ago that background time was getting reduced from 3 minutes to 30 seconds, does this impact the library anyhow? Is this something you are aware of?

[christocracy]

Do you anticipate a complicated API change for this?

No. background-fetch continues to work fine in iOS 13, it's just deprecated.

iPhone 11 is now out, and iOS 13 is rolling out to most phones already,

I have an iPhone 11 Pro for a week now and I've been testing iOS 13 beta for over a month. Background Fetch continues to operate fine.

Lastly, I read somewhere a long time ago that background time was getting reduced from 3 minutes to 30 seconds

Background fetch events have always been 30s. beginBackgroundTaskWithExpirationHandler has been reduced to 30s from 180s (once upon a time it was 10min), but that has nothing to do with background-fetch.

The new background-tasks will be added to this plugin in the future. The iOS background-fetch API isn't to go away for at least 2 years, probably much longer.

[cesarve77]

If the app is terminated for the user the fetch events halt, thats clear.
But Im wondering how do you do in react-native-background-geolocation for restart the process and continue sending the info to the server.

Is it allowed only for geolocalization services?

Thanks in advance

[christocracy]

The background-geolocation plugin uses two iOS api that continue to operate in spite of app terminate / device reboot: significant location changes (SLC) and geofencing. The plugin monitors a geofence around the last known position. When the device exits that geofence, iOS relaunches your app to service the event.

[cesarve77]

Thanks. One last question. Is possible to achieve this just using motion or healthkit.? I mean background fetch with a terminated app? Thanks again. El dom., 20 de octubre de 2019 9:02 a. m., Chris Scott < notifications@github.com> escribió:

…

The plugin uses two iOS api that continue to operate in spite of app terminate / device reboot: significant location changes (SLC) and a geofencing. The plugin monitors a geofence around the last known position. When the device exits that geofence, iOS relaunches your app to service the event. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#159?email_source=notifications&email_token=AA6JPJ5F5HJOW2OIGKROMVLQPOG2BA5CNFSM4HSZOEUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBX6L7Q#issuecomment-544204286>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6JPJ7HWQ2KMTORSFEYCOTQPOG2BANCNFSM4HSZOEUA> .

[christocracy]

No.

[cesarve77]

thanks El dom., 20 oct. 2019 a las 22:32, Chris Scott (<notifications@github.com>) escribió:

…

No. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#159?email_source=notifications&email_token=AA6JPJ37QQTOVDED64HRX5TQPRFUBA5CNFSM4HSZOEUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYJB5A#issuecomment-544248052>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6JPJ4SIR4HYXOPB3A3JFDQPRFUBANCNFSM4HSZOEUA> .

[cristianoccazinsp]

Hey, I'm wondering if there has been any progress with background tasks. iOS 13 has been catching up, and the new 30 seconds limit is awful.

I also wonder if background tasks for iOS should even be it's own library, does it make sense to make it part of this one?

[christocracy]

No progress. What are you hoping that background-tasks is going to give you? It still has a 30s limit.

The deprecated background-fetch api will probably work for at least 2 more years.

Yes, it makes sense to be part of this one.

[cristianoccazinsp]

Are you sure that background tasks use the same 30s limit? What's the point of it then? It's the same as requesting background time to the OS in that case. Does it just provide a better "scheduling" than background-fetch? I guess I didn't do my research yet

[christocracy]

It’s only an expanded scheduling system.

[cristianoccazinsp]

Does it provide a more robust or precise scheduling? We know that background-fetch is extremely random. Still 30s run time at precise scheduled intervals is definitely better than not running at all.

[christocracy]

Does it provide a more robust or precise scheduling?

No. It’s still going to be subject to a wide grey area.

[cristianoccazinsp]

That's awful. So iOS 13 is a loss, there's no way around it. And trying to hack it with location based events will probably just ban your app from the store.

Basically, we have a large queue of items to upload to a server, and it needs to run in background, but 30s is definitely not enough, and background-fetch is not frequent enough to upload the queue efficiently. It is also not a location or music based app, so no background capabilities at all...

[christocracy]

DropBox lives under the same constraints.

[Dexwell]

Also very much looking forward to the iOS 13 implementation; do you have any idea at all of an ETA? Much appreciated.

[Dexwell]

@christocracy No pressure, just curious about the ETA on this? Thanks so much.

[christocracy]

I'm working on this for the past few weeks. It's almost done.

[olczake]

@christocracy Thanks for providing us with this awesome library!

Will we be able to execute functions in the application when the application is killed? (not running in the background)

Do you have an ETA for the implementation of BackgroundTasks?

[christocracy]

You should watch this repo. 2.8.0 was released yesterday. You’ll want to have a good read of the README as several things changed, particularly iOS Setup.

For Android, all the usual headless mechanism operates as normal.

For iOS, the new method #scheduleTask only works when device is plugged into power. Maybe Apple will change this in the future, but currently, you should assume that scheduled background-tasks only fire when device is powered.

[cristianoccazinsp]

@christocracy nice update! Would you comment a bit on the difference between using just the "fetch" event for iOS vs using scheduleTask with a high delay (e.g., 1 hour) and periodic=true ? Would the scheduled task fire more often when plugged in as opposed to background fetch that fires quite randomly? Does it even make sense to have both fetch and scheduleTask configured at the same time when using periodic=true ?

Also, what would happen with Android when the above is configured? Would we end up with 1 background fetch event every X minutes and another scheduled task event every Y minutes?

Lastly, how one would stop a periodic scheduled task? I see no method to do so.

[christocracy]

using just the "fetch" event for iOS vs using scheduleTask with a high delay (e.g., 1 hour) and periodic=true

on iOS, the regular fetch event fires even when device is not powered. #scheduleTask seems only to fire when device is powered. On iOS, fetch is far more reliable than #scheduleTask. #scheduleTask is almost useless on iOS for anything other than menial tasks, like clearing old entries from a database. You're not going to want to write mission-critical stuff using #scheduleTask.

Also, what would happen with Android when the above is configured? Would we end up with 1 background fetch event every X minutes and another scheduled task event every Y minutes?

Pretty much. On Android, fetch_task == scheduleTask with periodic: true.

Lastly, how one would stop a periodic scheduled task? I see no method to do so.

BackgroundFetch.stop('your_task_id')

[cristianoccazinsp]

Thanks @christocracy . I will be giving this a try in the following weeks. For iOS, I find fetch to be almost useless as well and not reliable, I don't imagine scheduleTask being worse than that! If I could manage to get the two to work somehow together (fetch while not powered, task when powered) to at least achieve one execution a day, I would be more than happy. Right now fetch doesn't even seem to run once a day; extremely random behaviour, and lots of logs from our reporting tool from users not even allowing it to run (some devices seem to have fetch disabled by default).

This is the log I'm referring to:

[christocracy]

@cristianoccazinsp There are significant changes to the iOS setup

[cristianoccazinsp]

@christocracy I did see those changes; however, I have not updated yet (the above is from the previous configuration and I've assumed is related to users not allowing fetch to be turned on).

It may take a few weeks until I can fully test the update, but it's good to know the changes and differences.

[christocracy]

Error handling will need more work.

[jplandry908]

I tried to implement the new scheduleTask using the following example (after the config)

BackgroundFetch.scheduleTask({
taskId: "com.foo.customtask",
forceAlarmManager: true,
periodic: true,
delay: 300000 // <-- milliseconds
});

And receiving the following error

Possible Unhandled Promise Rejection (id: 0):
TypeError: RNBackgroundFetch.scheduleTask is not a function. (In 'RNBackgroundFetch.scheduleTask(config, success, failure)', 'RNBackgroundFetch.scheduleTask' is undefined)

I am using v2.8.0.

[christocracy]

iOS or Android?

[jplandry908]

iOS

[christocracy]

Run pod install

[jplandry908]

No joy.

This is the line I have in my pod file
pod 'RNBackgroundFetch', :path => '../node_modules/react-native-background-fetch'

I reran pod install and received this ...
pod install
Analyzing dependencies
Downloading dependencies
Generating Pods project
Integrating client project
Pod installation complete! There are 44 dependencies from the Podfile and 42 total pods installed.

Same error. BTW, thank you for your assistance. :)

[christocracy]

I’m on the road until next week.

rm your Podfile.lock and re-run pod install. It will print the pod versions being installed.

[jplandry908]

I deleted the pod lock file and pod folder and reinstalled. It confirmed version

Installing RNBackgroundFetch (2.8.0)

However, I'm still receiving that same error on app startup. I'll keep working on it and let you know if I figure it out. Safe travels.

[christocracy]

With your app open in XCode, find RNBackgroundFetch.m: search for method scheduleTask

[jplandry908]

I'm not finding that method in RNBackgroundFetch.m. It appears to be the same version that is current on github (where I cannot find it either).

https://github.com/transistorsoft/react-native-background-fetch/blob/master/ios/RNBackgroundFetch/RNBackgroundFetch.m

[christocracy]

Seems I’ve pushed this out too much in a hurry. Don’t use 2.8.0 until I return.

[mikehardy]

Just a note, as a fellow maintainer who has regretted a release (we are all human...) you can unpublish on npmjs.org, and then re-do as "next-major"beta1 or similar. Saved me repetitive bugs and user pain while I fixed up the release. Cheers Chris

[christocracy]

I think you have to email them now after that fiasco a few years back where that guy yanked his package that thousands of others relied upon but I’ll look into it.

The recent support requests are due to necessity in bggeo auto-linking instructions to yarn add react-native-background-fetch (since RN doesn’t auto-link dependencies). That needs to have appended @2.7.1 in setup instructions.

Releasing fetch as 3.0.0 won’t help in this case.

I’m on the road until Monday.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You may also mark this issue as a "discussion" and I will leave this open.

[atulmy]

Un-stale.

[christocracy]

This is already implemented.