BGTaskScheduler Terminated due to memory issue

However, when opening Safari & scrolling through some webpages, the App is killed because of "Terminated due to memory issue". I profiled the App & followed advice when it comes to reducing the memory footprint of the App. Are there any additional steps I can take to prevent the App being killed?

To be honest, I think you're looking at this issue the wrong way. Terminating suspended apps to free memory is part of the system’s normal architecture, not necessarily a bug or problem. Similarly, reducing your memory usage is certainly valuable and appreciated, but it isn't really possible to reduce it to the point where the system will NEVER terminate your app. That's just not how the system works.

Are there any recommendations for periodically scheduled Tasks when it comes to the Interval? Do more frequent Tasks (30min compared to one or two hours) have any impact? I tried many different schedules but none seem to make a difference.

I wouldn't expect this to make much difference.

That leads to here:

Any hints, suggestions or recommendations are highly appreciated!

My big question is what problem are you actually having? Our background APIs are generally designed so that apps can be launched into the background again "later", so it shouldn't really matter that the system terminated your app.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Dear Kevin,

thanks a lot for getting back so quickly & your detailed response! The problem I'm trying to solve is to reliable sync data from a BLE peripheral in Background over a longer period of time — either during the day or the night — between our user opening the App. However, once the app is killed, the task is no longer scheduled in the Background until the App is reopened, the Task resubmitted & re-scheduled.

So I'm looking for a way to rerun the Task even though the App was killed. Is there any way to launch the App into Background "later" as you mentioned other than having to open the App again?

Thanks a lot for getting back so quickly & your detailed response! The problem I'm trying to solve is to reliably sync data from a BLE peripheral in the background over a longer period of time — either during the day or the night — between our user opening the app.

There's a mix of technologies which can make this work. First, and foremost, CoreBluetooth has its own background architecture. That background architecture is extremely powerful, including support for relaunching the app into the background. That actually leads to another question, namely, what is your app actually doing when it's terminated? The system has a complex system for determining with which process it should terminate, but I'd generally expect it to avoid terminating apps that are engaged in active Bluetooth communication. More to the point, assuming your app is engaged in active Bluetooth communication, I wouldn't really expect to have even suspended, a Bluetooth exchange generally happens fast enough that the system never suspends you.

In terms of other system support, I see a few different options:

1. If the user is initiating the transfer, then BGContinuedProcessingTask would let you extend foreground runtime for several minutes.

2. For longer, user-initiated, transfers, you could use a Live Activity to provide custom feedback about what's going on while also extending your run time.

3. If you specifically want the transfer to be a "background" transfer that doesn't disrupt the user, then using BGProcessingTaskRequest to "start" the transfer window might work reasonably well. The processing task itself will give "a few minutes" of run time; however, the other point is that the processing task time window is specifically chosen to minimize the possibility of the user interacting with their device AT ALL. In practice, I'd expect that to GREATLY reduce the likelihood of your app being terminated due to memory, as the device is unlikely to be generating the same kind of memory contention and "spikes" normal user usage does.

I think the biggest question here is how much time you actually need, as the more time you need to complete the work, the harder it's going to be to "guarantee" that time, particularly if the work can't be done progressively but must be completed in a single session. If you specifically need a large chunk of continuous runtime, then the best approach is to do with the user’s involvement (1 or 2).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware