We’re receiving increasing user reports that our macOS app is unexpectedly terminated in the background—without crash reports or user action.
Our app is a sandboxed status-bar app (UIElement, NSStatusItem) running continuously, syncing data via CloudKit and Core Data. It has no main window unless opened via the status bar.
Observed patterns:
- Happens more frequent on macOS 15 (Sonoma), though earlier versions are affected too.
- Often occurs when disk space is limited (~10% free), but occasionally happens with ample free space.
- System logs consistently show:
CacheDeleteAppContainerCaches requesting termination assertion for <our bundle ID>
No crash reports are generated, indicating macOS silently terminates our app, likely related to RunningBoard or CacheDelete purging caches during disk pressure. Since our app is meant to run persistently, these silent terminations significantly disrupt user experience.
We’re seeking guidance on:
- Can we prevent or reduce these terminations for persistently running status bar apps?
- Are there recommended APIs or configurations (e.g., NSProcessInfo assertions, entitlements, LaunchAgents) to resist termination or receive notifications under low disk conditions?
- What are Apple’s best practices for ensuring sandboxed apps reliably run during disk pressure?
We understand macOS terminates apps to reclaim space but would appreciate recommendations to improve resilience within platform guidelines.
Thank you!
Can we prevent or reduce these terminations for persistently running status bar apps?
I'm not sure it will work in all cases or on all systems but, in theory, CacheDelete should not be terminating your app if there there is any data for it to delete. That means ensuring any temporary directories that it cleans are empty ("Caches", "tmp", etc) but may also require avoiding any API/framework usage that would consume this kind of storage without your knowledge.
Having said that:
Are there recommended APIs or configurations (e.g., NSProcessInfo assertions, entitlements, LaunchAgents) to resist termination or receive notifications under low disk conditions?
What are Apple’s best practices for ensuring sandboxed apps reliably run during disk pressure?
...I think avoiding the termination itself is the wrong way to approach this issue. There are so many edge cases possible failure points here that it's very difficult to predict or prevent all of them. Similarly, giving up the benefits of being able to cache data under normal conditions to avoid a relatively rare termination isn't necessarily a good tradeoff.
My recommendation would actually be to ignore the specifics of termination itself and instead focus on having the system relaunch your app if/when it happens to be terminated. My suggestion would be to use SMAppService to configure you app as a LaunchAgent which is configured to be relaunched. In most cases, this will make this kind of termination largely invisible to the user, either because it happened while the user wasn't actively using their machine or because the time frame was short enough that the user never noticed.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
