BGAppRefreshTask expires after few seconds (2-5 seconds).

I can see a number of events in our error logging service where we track expired BGAppRefreshTask. We use BGAppRefreshTask to update metadata. By looking into those events I can see most of reported expired tasks expired around 2-5 seconds after the app was launched.

How exactly does your task submission logic work? In particular, when exactly do you submit your new task requests?

I haven't seen this exact case before, but this sounds similar to cases I have seen where task submission is done immediately at launch. What then ends up happening is:

• System launches app to run task
• As part of that launch sequence, the app submit a new task.
• That new task replaces the original task (the one the app was launched to run) and is scheduled "in the future", so the system suspends the app.

Is there any heuristic that affects how much time the app gets?

No. More broadly, we generally treat 30s as standard "minimum" for execution time. I may have overlooked something, but I can't think of any case where we don't allow an app at least 30s. What happening here is caused by something your app is doing, NOT the system restricting your time.

Is there a way to tell if the app was launched due to the background refresh task? If we have this information we can optimize what the app does during those 5 seconds.

I don't think so but it shouldn't really matter. The solution here is to get your app a reasonable amount to time.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you for the quick reply. The app schedules background fetch in func applicationDidEnterBackground(_: UIApplication).

However I can see the code also re-schedules the background task in the launchHandler: @escaping (BGTask). I now think it should re-schedule the task in expiration handler or when the tasks is finished. I wonder now how it worked so far, because those errors started appearing recently, before they were very rare. Anyway thank you again for the reply it helped spotting the problem in the code.

I just went through Apple docs again. And I can see that the code matches the logic from https://developer.apple.com/documentation/uikit/using-background-tasks-to-update-your-app example.

So now I'm again lost. The code from the documentation also schedules app refresh directly from handleAppRefresh like our app does.

func handleAppRefresh(task: BGAppRefreshTask) {
   // Schedule a new refresh task.
   scheduleAppRefresh()


   // Create an operation that performs the main part of the background task.
   let operation = RefreshAppContentsOperation()
   
   // Provide the background task with an expiration handler that cancels the operation.
   task.expirationHandler = {
      operation.cancel()
   }


   // Inform the system that the background task is complete
   // when the operation completes.
   operation.completionBlock = {
      task.setTaskCompleted(success: !operation.isCancelled)
   }


   // Start the operation.
   operationQueue.addOperation(operation)
 }

Is the documentation incorrect?

So now I'm again lost. The code from the documentation also schedules app refresh directly from handleAppRefresh like our app does.

...

Is the documentation incorrect?

No, but what matters here are the exact details of what you do. Our sample code schedules it's app refresh task in exactly two places:

1. In "handleAppRefresh", as your code above shows. That call submits the next app refresh call as part of processing the current one.

2. In "applicationDidEnterBackground". This both submits the "first" request (since handleAppRefresh won't be called until a task is submitted from "somewhere" else) and throttles app refresh tasks (if your app was just closed, you don't need an app refresh task "now").

That second call is where many developer make mistakes. The standard case is the one I outlined in my previous message- if you move that submit into "applicationDidFinishLaunching", then you'll start submitting before your task starts, making your own task unreliable.

If that's not the issue, then here are a few more things I'd look at:

• Test what happens if you unlock your phone immediately after your refresh task starts. I don't think this happens with refresh tasks, but we do expire processing tasks if the phone unlocks (processing tasks should only run when the device is idle). The easy way to test this case is to have you app post a local notification when it enters "handleAppRefresh" and the open the device as soon as you see that notification.

• Go back and make sure you understand exactly what you "know". One of the common mistakes I've seen is that the analysis of a given data set (like a series of log messages) is primarily based on "memory" ("this is how what I remember the code doing") not "fact" ("this is what the code specifically does"). So, for example, a log message might say something like "task expired" but that log message is actually on a code path that could happen for other reasons.

In terms of investigating this from our side, what we'd really need is a sysdiagnose from a device that's experiencing the issue. I don't know how feasible that is, but if you're able to reproduce the issue or are in contact with a user who's experiencing the issue, here are the critical things to be aware of:

• It's absolutely critical that you tell us WHEN the problem actually occurred, as well as any other context you can provide (your bundle ID, task id, etc). The console log volume is enormous and difficult to interpet, so going in "blind" often feels like looking for a the right needle in a mountain of needles. The ideal here is when your log messages got to both your own log file and the console archive. That lets you use your own log file as an index into the system console, quickly getting to exactly where the problem is.

• It doesn't really matter how quickly after the problem occurs you capture the log. Obviously "an hour ago" is better than "7 days ago", but there isn't really any difference between "5 min", "30 min", or "4 hours". Indeed, when I'm investigating issues where you do know EXACTLY when the problem occurs, I often ask the developer to wait a few minutes before triggering the log, as this makes it easier to separate out the log noise the sysdiagnose generates from what's actually important.

• It is important that the device has not been power cycled and that "plenty" of storage is available. Many sub-systems purge data on reboot or when storage is constrained, making the log far less useful. You can try capturing anyway, but don't be surprised if there isn't anything interesting.

If you're able to capture a sysdiagnose, then please file a bug on this and then post the bug number back here. I'm not sure there is a system bug here, but the behavior your describing is weird enough that the engineering team and I would like to understand what's going on.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I validated our app code again, it strictly follows Apple examples. I also validated the logic around scheduling the next fetch date, we already had unit tests around it to ensure it is always the date in the future (we aim for background fetches during the weekend). Regarding when we track the expiration handler it's the BGAppRefreshTask expiration handler.

The app uses Bugsnag to track handled and unhandled errors and it shows the time of the event since when the Bugsnag was loaded (applicationDidFinishLaunching).

This is how I can see that a very large number of expired tasks are under 5 seconds after the Bugsnag was loaded.

We are not able to reproduce those expiration on our devices (or the QA devices) so there's no way to get sysdiagnose because our error tracking is fully anonymized and our app don't have accounts, we don't know which exact users are affected.

@available(iOS 13.0, *)
    private func handleAppRefresh(task: BGAppRefreshTask) {
        scheduleAppRefresh()
        task.expirationHandler = {
            Tracker.trackErrorMessage("handleAppRefresh expirationHandler: \(task.identifier)")
            task.setTaskCompleted(success: false)
        }

        // Fetch sounds metadata.
        DataManager.shared.updateLibrary { _ in
            task.setTaskCompleted(success: true)
        }
    }

How can I test the following:

Test what happens if you unlock your phone immediately after your refresh task starts. I don't think this happens with refresh tasks, but we do expire processing tasks if the phone unlocks (processing tasks should only run when the device is idle). The easy way to test this case is to have you app post a local notification when it enters "handleAppRefresh" and the open the device as soon as you see that notification.

Thank you.

So, let me start here:

How can I test the following:

The basic idea I was outlining there was using a local notification as the hint/trigger that background app refresh has occurred, so you can then unlock the device "immediately" if/when you see that alert. However, that technique is also useful for situations like this:

We are not able to reproduce those expiration on our devices (or the QA devices) so there's no way to get sysdiagnose because our error tracking is fully anonymized and our app don't have accounts, we don't know which exact users are affected.

If you have formal beta testers and/or the app is being used by your development team or other "known" users, then you can use the same local notification "trick" to notify one those "special" users that they should collect a sysdiagnose from that device. Typically you'd do something like enabling the flag in TestFlight (where the users are "known" and willing to collect this kind of data for you) and disable it in "production"/App Store (where you don't want to bother/confuse customers).

One small cautionary not here:

The app uses Bugsnag to track handled and unhandled errors and it shows the time of the event since when the Bugsnag was loaded (applicationDidFinishLaunching).

This is how I can see that a very large number of expired tasks are under 5 seconds after the Bugsnag was loaded.

One thing to be careful about here is making sure you're data means EXACTLY what you think it means. In the case here, what you're actually comparing is the time Bugsnag logs a particular message against the time expiration logged. It's possible that's entirely fine- Bugsnag initialization time is short and "constant" so, practically speaking, it's the same as if you'd logged directly out of "applicationDidFinishLaunching". However, it could also be the case that Bugsnag under some unknown set of circumstances, Bugsnag takes longer to load/initialize, making the expiration time look much shorter than it actually is.

There are also other, more complicated variations on that "theme". Most of our APIs like this have some degree of protection against "cheating" built in, so that an app can't get extra runtime by tweaking it's own internal processing to delay when it receives information from the system. SO, for example, in a sequence like this:

1. Spends 20s doing "stuff" prior to applicationDidFinishLaunching

2. Sets up BGTaskScheduler in applicationDidFinishLaunching

3. System calls launchHandler to start task.

...Then I'd expect that task to expire closer to 10s vs. 30s.

Lastly, returning to this point:

our error tracking is fully anonymized

Does the system let you track issues by device, even though the device itself is anonymous? Putting that another way, can you see "all" the data produced by a given device, even though you don't know who/which physical device that actually is. If you're able to correlate data, then that might given you insight it to what actually triggers the issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you Kevin,

Regarding Bugsnag initialization, we start it in applicationDidFinishlaunching on the main thread and given our launch times from Xcode organizer (around 1 second 90% and around 0.5 second 50%) and users never complaining of having long start times I don't see how it could take that much longer time than normally it does (sub 100ms).

Regarding using notification to test the behavior, the idea is nice, but the slight problem is that it requires somebody closely watching the phone to quickly react to unpredictable background fetch event. I was testing it before and setting to the be triggered as quickly as possible, but usually it was hours of waiting for it to occur after backgrounding the app. Is there a way to force triggering it earlier? The only way I'm able to trigger background fetches (except when running the app via Xcode) is on my jailbroken device by attaching the debugger to DASDaemon and executing forceRunActivities however I think it won't work when the device is locked.

We also never saw those early expirations during development or beta testing, they are not in large percentage, but the number of events is not small. It's that we just waste users and our server resources because of those quick expirations.

Regarding the Does the system let you track issues by device, even though the device itself is anonymous? the data is very limited (e.g. language, app version, compiler version, thread stack trace), it's way less than in organizer crash logs.

So before I close the thread, please confirm that those steps are correct:

1. call scheduleAppRefresh() in applicationDidEnterBackground(_: UIApplication)
2. call scheduleAppRefresh() in the handleAppRefresh directly like in the Apple's documentation and in the code snipped I provided.

Lastly, is there a way to know if the app was launched due to the app refresh? If we know that we can avoid a lot of unnecessary initializations.

Thank you!

Regarding using notification to test the behavior, the idea is nice, but the slight problem is that it requires somebody closely watching the phone to quickly react to unpredictable background fetch event.

Not really. The sysdiagnose capture covers a very long period of time (hour to days, depending on circumstances) so as long as the device hasn't been rebooted* it doesn't actually matter when you collect the log. While closer in time is theoretically "better", for an issue like this there isn't really any practical difference between collecting a long "immediately" vs 30+ minutes later.

*A lot of log data is purged at reboot, so that is a problem for this sort of thing.

For most issue I actually recommend developer wait 5-10 min. after an issue before they trigger the log, as that makes sure that the log noise of the sysdiagnose isn't mixed in with any "trailing" log data. I'll also say that the upper time band here is pretty big. I don't like saying "sure, collect it 4 days later" because things do go wrong, but I've gotten useful information out of sysdiagnoses that were capture several days after the original event. There's certainly no need to actively watch for the notification to try and "catch" it.

I was testing it before and setting to the be triggered as quickly as possible, but usually it was hours of waiting for it to occur after backgrounding the app. Is there a way to force triggering it earlier? The only way I'm able to trigger background fetches (except when running the app via Xcode) is on my jailbroken device by attaching the debugger to DASDaemon and executing forceRunActivities however I think it won't work when the device is locked.

No, and I wouldn't trust anything like this if there was. My guess is that one of a few things is going to happen once you start testing with the approach I suggested above:

1. This happens "all the time", in which case collecting a sysdiagnose will be easy. Just use the app normally for "awhile" and trigger the sysdiagnose when you see the notification.

2. "None" of your users see it except for one (or a few) people who see it "regularly".

3. "None" of your users see it, except for random occurrences that don't have any real pattern.

My guess here is that it will be 2 or 3, but the issue is that you don't need it for #1 (because the issue will be relatively easy to reproduce) and it's unlikely to help for 2 or 3 (because it won't duplicate whatever "extra" factor is causing the issue).

We also never saw those early expirations during development or beta testing, they are not in large percentage, but the number of events is not small.

I don't know how large your user base is, but one note here is that for REALLY "big" apps, very rare events can be "noticeable" in absolute terms. For example, with a large enough user base and an app that's heavily used during the day, the number of task that expire because the user manually power cycled* their device is probably "measurable".

*Note that this is a made up example of the top of my head. I don't know if this will actually trigger expiration or not.

So before I close the thread, please confirm that those steps are correct:

Yes, those were correct.

Lastly, is there a way to know if the app was launched due to the app refresh?

No, however...

If we know that we can avoid a lot of unnecessary initializations.

...you maybe able to get largely the same result by shifting where/how you initialize work. You could either move other work "later" (for example, out of didFinishLaunching) or move registration earlier (for example, into willFinishLaunchingWithOptions).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware