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!

I’m building a companion app that connects to a custom hardware hub (IoT device) used for home safety monitoring. The hub is installed in homes and is responsible for triggering critical alerts like fire alarms, motion detection, door sensor activity, and baby monitor events. Current Architecture: The hub initially connects to the app via Bluetooth (BLE) for provisioning (to get Wi-Fi credentials). Once provisioned, the hub switches to Wi-Fi and communicates with the app via a WebSocket connection to stream real-time event updates. What I’m Trying to Achieve: My goal is to maintain background communication with the hub even when the app is not actively in use, in order to: Receive real-time updates from the hub while the device is locked or the app is in background. Trigger local notifications immediately when critical sensor events (e.g., fire, motion) occur. Ensure persistence across backgrounding, app swipes (force close), and device reboots, if possible. What I'm Observing: On iOS, WebSocket connection is suspended or dropped shortly after the app goes to the background or is locked. Even though the I've scheduled periodic fetches, notifications are delayed until the app is reopened, at which point all missed WebSocket messages arrive at once. If the app is force-closed or after reboot, no reconnection or notification happens at all. Key Questions I Have: Since the hub is initially provisioned via BLE, and could potentially send BLE flags or triggers for key events, can I use bluetooth-central mode to keep the app active or wake it up on BLE activity? Once the hub switches to Wi-Fi and uses WebSocket, is it possible to combine BLE triggers to wake the app and then reconnect to the WebSocket to fetch the full event payload? Is there a legitimate and App Store-compliant way to maintain a connection or background task with: BLE accessory triggers followed by Real-time data processing via Wi-Fi/WebSocket? Would this use case qualify as a "companion device" scenario under iOS background execution policies? What is the best practice for handling this kind of hybrid BLE + WebSocket alerting flow to ensure timely user notifications, even in background/locked/force-closed states? Any advice, documentation links, implementation patterns, or examples from similar companion device apps would be greatly appreciated. Thanks in advance!

Hi everyone! I’ve developed a location-based Audio AR app in Unity with FMOD & Resonance Audio and AirPods Pro Head-Tracking to create a ubiquitous augmented soundscape experience. Think of it as an audio version of Pokémon Go, but with a more precise location requirement to ensure spatial audio is placed correctly. I want this experience to run in the background on iOS, but from what I’ve gathered, it seems Unity doesn’t support this well. So, I’m considering developing a Swift version instead. Since this is primarily for research purposes, privacy concerns are not a major issue in my case. However, I’ve come across some potential challenges: Real-time precise location updates – Can iOS provide fully instantaneous, high-accuracy location updates in the background? Continuous real-time data processing – Can an app continuously process spatial audio, head-tracking, and location data while running in the background? I’m not sure if newer iOS versions have improved in these areas or if there are workarounds to achieve this. Would this kind of experience be feasible to run in the background on iOS? Any insights or pointers would be greatly appreciated! I’m very new to iOS development, so apologies if this is a basic question. Thanks in advance!