Hi everyone, I recently built an iOS application that fetches the healthkit data with the BGProcessingTask. It is working as expected in the debug with the physical device connected but its not working in Testflight. I printed out the logs but they don't show that the background process's running. Here is my code snippet. func registerBackgroundTask() { BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: nil) { task in LogManager.shared.addBackgroundProcessLog("registering the background task...") print("registering the background task...") self.handleBackgroundTask(task: task as! BGProcessingTask) } } func scheduleBackgroundHealthKitSync() { print("scheduling background task...") LogManager.shared.addBackgroundProcessLog("scheduling background task...") let request = BGProcessingTaskRequest(identifier: taskIdentifier) request.earliestBeginDate = Date(timeIntervalSinceNow: 60 * 1) request.requiresNetworkConnectivity = true request.requiresExternalPower = false do { try BGTaskScheduler.shared.submit(request) print("BGProcessingTask scheduled") LogManager.shared.addBackgroundProcessLog("BGProcessingTask scheduled") } catch { print("Failed to schedule task: \(error)") LogManager.shared.addBackgroundProcessLog("Failed to schedule task: \(error)", isError: true) print(LogManager.shared.backgroundProcessLogs) } } func handleBackgroundTask(task: BGProcessingTask) { LogManager.shared.addBackgroundProcessLog("handleBackgroundTask triggered") print("handleBackgroundTask triggered") let dispatchGroup = DispatchGroup() dispatchGroup.enter() // Reschedule the background sync for the next time scheduleBackgroundHealthKitSync() var taskCancelled = false // Handling expiration task.expirationHandler = { taskCancelled = true LogManager.shared.addBackgroundProcessLog("Background task expired", isError: true) print("Background task expired") dispatchGroup.leave() } let healthKitManager = HealthKitManager.shared // Start the background sync operation healthKitManager.fetchAndSendAllTypes() { success in if success { LogManager.shared.addBackgroundProcessLog("HealthKit sync completed successfully") print("HealthKit sync completed successfully") } else { LogManager.shared.addBackgroundProcessLog("HealthKit sync failed", isError: true) print("HealthKit sync failed") } dispatchGroup.leave() } // Notify when all tasks are completed dispatchGroup.notify(queue: .main) { // Check if the task was cancelled using your own flag or state if taskCancelled { task.setTaskCompleted(success: false) // Fail the task if it was cancelled } else { task.setTaskCompleted(success: true) // Complete successfully if not cancelled } LogManager.shared.addBackgroundProcessLog("Background task ended with status: \(taskCancelled == false)") print("Background task completed with success: \(taskCancelled == false)") // Logs success or failure } } Here are the logs from my device. scheduling background task... BGProcessingTask scheduled

Will App be terminated or suspended when updating to incremental version from app store?

I do have background Modes added to Xcode. How can I fix this? Automatic signing failed Xcode failed to provision this target. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator. Provisioning profile "iOS Team Provisioning Profile: com.designoverhaul.bladerunner" doesn't include the com.apple.developer.background-modes entitlement. I emailed Dev Support but they said they cant help. Thank you.

Dear Apple Support Team, My app, io.cylonix.sase, has a BGAppRefreshTask (io.cylonix.sase.ios.refresh) that is canceled by dasd ~9ms after submission from a Network Extension. Please help identify the cause and suggest a solution. App Details: App ID: io.cylonix.sase iOS Version: 17.1.1 (iPhone Xs Max) Network Extension: saseWgNetworkExtension with packet-tunnel-provider entitlement Use Case: VPN app; Network Extension records file receipts in shared group UserDefaults and schedules BGAppRefreshTask to wake the main app. App Usage: High (frequently used) System State: Sufficient resources (not low on battery or memory) Issue: The task is submitted but canceled immediately with priority 10. It has never run, so rate-limiting is not an issue. ` debug 22:09:37.952749-0700 dasd Best binding found for evaluator 0x16d541720: <private> debug 22:09:37.954483-0700 dasd Invoking selector backgroundTaskSchedulerPermittedIdentifiersWithContext:tableID:unitID:unitBytes: on <LSApplicationRecord 0x724844650> default 22:09:37.955563-0700 dasd CANCELED: bgRefresh-io.cylonix.sase.ios.refresh:ABDAFA at priority 10 <private>!

Hello Apple Support, I’m facing an issue with Background Fetch in my React Native project. When I click on Simulate Background Fetch in Xcode, everything works as expected on the iOS Simulator—background tasks run smoothly, and data is fetched without issues. However, on a real device, the app goes to the background but doesn’t execute any of the scheduled background tasks, and it also remains in the background without terminating. Here’s some additional context: React Native Project: I’m using React Native to develop this app, and the background tasks involve: Getting User Location: Fetching the user’s location in the background. API Calls: Calling an API to fetch necessary information based on the user’s location. Scheduling Notifications and Alarms: Scheduling notifications and alarms based on the API response data. Simulator vs. Real Device: In the iOS Simulator, all these background tasks trigger and function correctly when I simulate Background Fetch. On the real device, however, none of these tasks are triggered when I try to simulate Background Fetch. The app only moves to the background without performing any tasks or getting terminated. Device and Configuration Details: iOS Version: 17 Device Model: Iphone xs, Iphone 11, iphone 7 Background Modes: Background Fetch is enabled in Capabilities, and I’ve set the fetch interval to the minimum for testing. I’ve verified that all configurations are correctly set, and I’ve tried restarting the device and Xcode, but the issue persists. Is there something specific about Background Fetch that could prevent it from functioning as expected on physical devices? Any guidance on troubleshooting or additional steps would be highly appreciated. Thank you!

When I search, it's always people trying to do stuff in the background. I want my app to only do stuff when it is active. And this post https://developer.apple.com/forums/thread/685525 seems to have prevented replies from the start. Which means it's just a documentation page and does not belong in the discussion forums at all, because it prevents all discussion.

How can I enable "Extended Runtime Sessions" for a companion watch app? Here https://developer.apple.com/documentation/watchkit/using-extended-runtime-sessions in targets under 'Signing & Capabilities' I checked "Audio" and Session Type 'Mindfulness', I created an ExtendedRuntimeManager.swift file. When running a simulation the error message says "Extended Runtime Session ungültig: Reason=-1, Error=This application does not have appropriate permissions to schedule a session." How does the app get the 'appropriate permissions'?

Thank you for always reading my questions. This time, I'd like to ask some specific questions to gain a deeper understanding of iOS CoreBluetooth. In the previous question, we learned that although iOS can perform BLE scanning in the background, it is not suitable for use as a data logger. I was also taught that when using it as a data logger, the iOS app should use GATT communication, and that instead of reading data from the device one by one, it is recommended to store large amounts of data on the device and connect at an appropriate time (such as when the iOS app enters the foreground) to retrieve the data all at once. My requirements are the same as last time. I want to send data from a device equipped with some kind of sensor via BLE and display it in a graph in the iOS app. Data should be acquired every few to tens of seconds and reflected immediately in the graph. Measurements may take up to 24 hours at most. I would like to avoid making any major changes to the device. Also, it is unclear whether there will be enough memory for the data logger for 24 hours. Therefore, I am first looking for an appropriate communication method for the iOS app. iOS is smart and convenient, so I think users will check the measurement status every time they use this iOS app.Therefore, I want to be able to check the changes from the start of measurement to the present in a graph as soon as the app is launched. I would like to measure data from multiple devices (e.g. 5 devices) at the same time. I have a question based on the above requirements. When thinking about the best way to avoid making changes to the device, the only way I could come up with, as someone with insufficient iOS technology, is to keep the connection open via GATT communication and continue to obtain data. However, does iOS GATT communication have any limitations in this regard? Will the OS automatically disconnect GATT communication at a certain time? Also, if that happens, is there a way to automatically reconnect and obtain the data? Is it possible to smoothly obtain data using iOS GATT communication without any particular restrictions even in the background? Are any other permissions required? Regarding the sixth requirement. Until last time, with BLE scanning, even if there were multiple devices, the iOS app could measure the data for as many devices as it wanted, but this time, how many devices can be read? In the case of GATT communication with iOS CoreBluetooth, can multiple devices maintain a long connection? Or is it basically better to have one device per connection when creating such an app for iOS? I would like to know if there are any restrictions or points to be careful of when using GATT communication with multiple devices. I'm sorry for broadening my question, but if neither question 1 nor question 2 works, it will put a burden on the design of the device. If data is stored on the device, is it possible to automatically and periodically connect to the device at a set time interval (for example, once an hour, allowing for some margin of error) when the iOS app is in the background, and obtain log data from the device? If you can think of any other best methods, please feel free to let me know. Also, I'd be happy if you could reply with any reference materials or URLs. Please note that our response may be delayed.

Hi. I have a device that is connected to my phone and sends few bytes at different times. The app caches those events and sends them to server as soon as internet is available. This all works, but when app goes to background or user locks the phone then after few seconds app has no internet access. It still caches the events that are important but unable to send them until app is brought to foreground. How can app still connect to server? I saw few posts saying they solved it by using URLSession with a background mode, but in my case it says: Terminating app due to uncaught exception 'NSGenericException', reason: 'Upload tasks from NSData are not supported in background sessions.' As I understood URLSession can download or upload files, but the events comming from BLE device are few bytes, so how to send them to server as soon as possible? Found this stackoverflow question and gave me some hopes https://stackoverflow.com/questions/63016680/sending-network-request-after-bluetooth-update-while-ios-app-is-in-background but no examples at all.

I am suspecting that setting GCController.shouldMonitorBackgroundEvents = true does not actually make the game controllers inputs accessible to the app when it is in the background. About this value the official documentation says: A Boolean value that indicates whether the app needs to respond to controller events when it isn’t the frontmost app. Now the behavior is that when the app is in focus the users inputs do get correctly recognized but as soon as the app enters the background no inputs get recognized. The controller does not get reported as disconnecting and still works for example in launchpad. I am sure that about 2 months ago when I first used this it did work as one would expect. I also have seen that an app which lets users execute certain actions using their controller has stoped working recently, adding to my suspicion of the feature being broken. Here is a minimum reproducible example: import SwiftUI import GameController @main struct TestingControllerConnectionApp: App { @NSApplicationDelegateAdaptor(AppDelegate.self) var appDelegate var body: some Scene { WindowGroup { ContentView() } } } class AppDelegate: NSObject, NSApplicationDelegate { var statusItem: NSStatusItem? var controller: GCController? func applicationDidFinishLaunching(_ notification: Notification) { setupMenuBar() GCController.shouldMonitorBackgroundEvents = true NotificationCenter.default.addObserver( self, selector: #selector(controllerDidConnect), name: .GCControllerDidConnect, object: nil ) NotificationCenter.default.addObserver( self, selector: #selector(controllerDidDisconnect), name: .GCControllerDidDisconnect, object: nil ) } @objc private func setupMenuBar() { let menu = NSMenu() menu.addItem(NSMenuItem(title: "Quit", action: #selector(quitApp), keyEquivalent: "q")) statusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength) statusItem?.button?.image = NSImage(resource: .controllerBar) statusItem?.menu = menu } @objc private func quitApp() { NSApp.terminate(nil) } @objc private func controllerDidConnect(_ notification: Notification) { if let controller = notification.object as? GCController { print("Controller connected") self.controller = controller if let gamepad = controller.extendedGamepad { gamepad.buttonA.pressedChangedHandler = { _, _, pressed in print("Button A pressed: \(pressed)") } } } } @objc private func controllerDidDisconnect(_ notification: Notification) { print("Controller disconnected") } } This is created in a completely fresh Xcode project and NSHumanInterfaceDeviceUsageDescription has been added. I am using a PS5 Controller and a Mac running MacOS 15.4.1 which has been restarted and only Xcode and the app have been opened. I have tested this with setting a multitude of different entitlements and capabilities including: NSHumanInterfaceDeviceUsageDescription Supports Controller User Interaction Required background modes -> App communicates with an accessory com.apple.security.device.bluetooth com.apple.security.device.hid com.apple.security.device.usb I have also set this value at different points in the code with no change of effect. Does anybody see if there is any fault in my code or my understanding of the effect of the value 'shouldMonitorBackgroundEvents'? Or is this the functionality actually being broken on Apples part?

Hello, When my mobile app is terminated, say 30 secs later the CarPlay app stops working. I don't get the access token that is saved in the KeyChain. The same happens when my mobile app is in background for more than 20 secs or so. Please suggest the way forward. Or is this the expected behavior?

Nice to meet you, I'm currently trying to create an app like a data logger using BLE. When a user uses the above app, they will probably put the app in the background and lock their iPhone if they want to collect data for a long period of time. Therefore, the app I want to create needs to continue scanning for BLE even when it goes into the background. The purpose is to continue to obtain data from the same device at precise time intervals for a long period of time (24 hours). In that case, can I use the above function to continue to read and record advertising data from the same device periodically (at intervals of 10 seconds, 1 minute, or 5 minutes) after the app goes into the background? Any advice, no matter how small, is welcome. Please feel free to reply. Also, if you have the same question in this forum and it has already been answered, I would appreciate it if you could let me know.

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. The documentations says: The system decides the best time to launch your background task, and provides your app up to 30 seconds of background runtime. I expected "up to 30 seconds" to be 10-30 seconds range, not that extremely short. Is there any heuristic that affects how much time the app gets? 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. Thank you!.

Hello. Background: Most learning resources are for leaning Swift/Objective-C. I'm pretty sure I need something different. I'm already an experienced software engineer, just new to iOS/MacOS development. My problem is not learning the language, but rather how to learn modern best practices. I cannot find examples for what I'm looking for. So much seems to be sparse on implementation details, out of date, or both. I'm trying to write an app that has a few distinct parts. The UI portion will be mostly a menu bar app, which I am not having a problem discovering resources for how to implement. The app will also have a daemon and utilize network extensions. This is where I am having trouble. What's the current best practices on how to write and launch a daemon? Should the daemon be its own library/package which is them imported into the main app? If so, which Xcode template do I use for this? Are there any Hello World! examples of this? What is the best way for a UI app to communicate with a daemon? Are there any Hello World! repositories on how to implement network extensions? Should this be done in the main UI app, or in a separate library/package? TIA

I've been seeing a high number of BGTaskScheduler related crashes, all of them coming from iOS 18.4. I've encountered this myself once on launch upon installing my app, but haven't been able to reproduce it since, even after doing multiple relaunches and reinstalls. Crash report attached at the bottom of this post. I am not even able to symbolicate the reports despite having the archive on my MacBook: Does anyone know if this is an iOS 18.4 bug or am I doing something wrong when scheduling the task? Below is my code for scheduling the background task on the view that appears when my app launches: .onChange(of: scenePhase) { newPhase in if newPhase == .active { #if !os(macOS) let request = BGAppRefreshTaskRequest(identifier: "notifications") request.earliestBeginDate = Calendar.current.date(byAdding: .hour, value: 3, to: Date()) do { try BGTaskScheduler.shared.submit(request) Logger.notifications.log("Background task scheduled. Earliest begin date: \(request.earliestBeginDate?.description ?? "nil", privacy: .public)") } catch let error { // print("Scheduling Error \(error.localizedDescription)") Logger.notifications.error("Error scheduling background task: \(error.localizedDescription, privacy: .public)") } #endif ... } 2025-02-23_19-53-50.2294_+0000-876d2b8ec083447af883961da90398f00562f781.crash

I'm developing a medication scheduling app similar to Apple Health's Medications feature, and I'd like some input on my current approach to background tasks. In my app, when a user creates a medication, I generate ScheduledDose objects (with corresponding local notifications) for the next 2 weeks and save them to SwiftData. To ensure this 2-week window stays current, I've implemented a BGAppRefreshTask that runs daily to generate new doses as needed. My concern is whether BGAppRefreshTask is the appropriate mechanism for this purpose. Since I'm not making any network requests but rather generating and storing local data, I'm questioning if this is the right approach. I'm also wondering how Apple Health's Medications feature handles this kind of scheduling. Their app seems to maintain future doses regardless of app usage patterns. Has anyone implemented something similar or can suggest the best background execution API for this type of scenario? Thanks for any guidance you can provide.

Hi! I'm trying to submit a task request into BGTaskScheduler when I background my app. The backgrounding triggers an update of data to a shared app groups container. I'm currently getting the following error and unsure where it's coming from: *** Assertion failure in -[BGTaskScheduler _unsafe_submitTaskRequest:error:], BGTaskScheduler.m:274 Here is my code: BGAppRefreshTaskRequest *request = [[BGAppRefreshTaskRequest alloc] initWithIdentifier:kRBBackgroundTaskIdentifier]; NSError *error = nil; bool success = [[BGTaskScheduler sharedScheduler] submitTaskRequest:request error:&error];

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!