CacheDeleteDaily is killing location app while in-use and in the background

We have two location tracking apps, that businesses heavily use. We prefer to use the While Using permissions, this way when the app is in the background a blue band appears on the home screen, thus giving the end users the confidence that the app is tracking their location


Since iOS 12 we've been noticing that both our locations apps seem to die at the same time.

If they are restarted after that, they work fine till the next day but again they will die at the same time.


After checking the Console logs, it looks like its the CacheDeleteDaily service that kills the apps.


One would expect that if the app is in use, the CacheDeleteDaily wouldn't kill it. Is someone else also seeing this behaviour?


Does anyone know of any way to workaround/correct this?

Replies

I’ve seen other posts about this (background location updates stopping on their own after hours or days), but nothing that specifically identified the culprit that was killing the apps in the background. Thanks for doing the troubleshooting. Please file a bug report.


As for a workaround. If you use Always permission, you can set the showsBackgroundLocationIndicator property on CLLocationManager to show the blue bar. I have no idea if that would affect whether or not the app gets killed. It should allow you to use some other API (e.g. region monitoring) to maybe restart it eventually without user intervention. But there would still be a gap in location recording.

Please file a bug report.

I second that.

Also, please post your bug number here, just for the record.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I'm also seeing this problem.


22:13:57.647615 +0100 assertiond Request to create termination assertion <BKSTerminationAssertionCreateEvent: 0x104f38c10; Identifier: *******; Name: *******; Target BundleID: ********; Efficacy: Unused> from client <BKClientHandle: 0x105831fd0; CacheDeleteDail:2662; connections: 1>


This is while my app is using location updates in bg.


Please update with bug number so i can follow if there is a fix or possible workaround


Thanks

Please update with bug number so i can follow if there is a fix or possible workaround

I recommend that you file your own bug about this because:

  • It will get dup’d to the original bug, so you can then see the open/closed status of that bug.

  • It will give iOS Engineering a better understanding of this impact of this issue.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

We attempted to use the Always permission as a workaround but unfortunately our app is still being terminated by CacheDeleteDaily. We've been testing on iOS 12.1 & 12.1.2 iPhones.


This is what we've seeing in the sysdiagnose logs (logs aquired by using this process https://download.developer.apple.com/iOS/iOS_Logs/sysdiagnose_Logging_Instructions.pdf)


At some point this CacheDeleteDaily process starts

default2019-01-12 05:04:24.265725 -0600CacheDeleteDailyenumerating bundles of type: LSBundleTypeInstalledApp


And picks up the assertion to terminate my app

default2019-01-12 05:04:30.332460 -0600CacheDeleteDailyAcquired termination assertion for event <BKSTerminationAssertionCreateEvent: 0x102e13720; Identifier: 289-3D3DA072-128D-4509-B4E7-164CBF820139; Name: com.MyAwesomeLocationApp; Target BundleID: com.MyAwesomeLocationApp; Efficacy: Unused>


Following the advice in this forum, I created a bug and provided all the information I have. It was marked a duplicate of another bug (the original one I guess?).

I also filed a TSI (Technical Support Incident) and DTS (Developer Technical Support) said there is no workaround they can provide for my bug report :[


This is a big deal for us as our apps rely on persistent background location. Our only workaround currently is to prompt the user not to plug in their device when using background location services. The CacheDeleteDaily process only seems to run when the device is plugged in.


We found some really good information here that was being relayed from DTS: https://stackoverflow.com/questions/53005174/ios-12-terminates-apps-in-the-background-for-no-reason

Does anyone know if this has been resolved in 12.1.3?

Nothing in the release notes for 12.1.3 about a fix for this, so I assume not. But wouldn't mind clarification if it has been resolved. I'm testing on a bunch of devices running 12.1.3 today.

Does anyone know if this has been resolved in 12.1.3?

It has not. Nor has it been resolved in the just-seeded 12.2b1.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"
(r. 45505724)

Does anyone know if this has been resolved in 12.2b2?

Nothing in the release notes for 12.2b2 about a fix for this, so I assume not. But wouldn't mind clarification if it has been resolved. I'm testing on a bunch of devices running 12.2b2 today.


My bug number is 45583576(Duplicate of 45505724).

Does anyone know if this has been resolved in 12.2b2?

It’s definitely worth re-testing this on 12.2b2.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

We are experiencing the same issue on watchOS. I tested with watchOS v5.2b2, but still see the issue. Can you comment on whether this issue is being addressed in watchOS?

Please clarify what you mean by the "same issue"


Do you actually have a sysdiagnose with entries for CacheDeleteDaily terminating your app on the watch?

Or is it the same issue, as in, your app is stopping location updates on the watch mysteriously?

Yes we do. After seeing the app quit at night (while charging), I performed a sysdiagnose on the watch. I saw this line in the watch system logs:


2019-02-02 05:22:06.456561-0800 0x72e9 Default 0x1457 292 0 CacheDeleteDaily: (AssertionServices) [com.apple.assertiond:termination_assertion] Acquired termination assertion for event <BKSTerminationAssertionCreateEvent: 0x15566540; Identifier: ****; Name: com.ourcompany.ourapp.watchkitapp; Target BundleID: com.ourcompany.ourapp.watchkitapp; Efficacy: Unused>


Upgraded to watchOS v5.2b2 and still see the watch app restarting at night when the device is charging.

> It’s definitely worth re-testing this on 12.2b2.


Dear eskimo,


I tested it with iOS 12.2 beta 2 for 1 week.

At the moment there are no problems.

I hope the problem does not occur even in the official release version.


It was a great help!

Thank you for your kindness.


Sincerely,

I tested it with iOS 12.2 beta 2 for 1 week. At the moment there are no problems.

Yay! Thanks for letting us know.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

We've found that this behavior stops when the passcode on the watch is disabled. Strange...


Any updates on whether you can address this the same way you addressed it for iOS?