Hi, We are running into issues with iOS app prewarming, where the system launches our app before the user has entered their passcode. In our case, the app stores flags, counters, and session data in UserDefaults and the Keychain. During prewarm launches: UserDefaults only returns default values (nil, 0, false). We have no way of knowing whether this information is valid or just a placeholder caused by prewarming. Keychain items with kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly are inaccessible, which can lead to broken business logic (the app can assume no session exists). No special launch options or environment variables appear to be set. We can reproduce this 100% of the time by starting a Live Activity in the app before reboot. Here’s an example of the workaround we tried, following older recommendations: __attribute__((constructor)) static void ModuleInitializer(void) { char* isPrewarm = getenv("ActivePrewarm"); if (isPrewarm != NULL && isPrewarm[0] == '1') { exit(0); // prevent prewarm launch from proceeding } } On iOS 16+, the ActivePrewarm environment variable doesn’t seem to exist anymore (though older docs and SDKs such as Sentry reference it). We also tried listening for UIApplication.protectedDataDidBecomeAvailableNotification, but this is not specific to prewarming (it also fires when the device gets unlocked) and can cause watchdog termination if we delay work too long. Questions: Is there a supported way to opt out of app prewarming? What is the correct way to detect when an app is being prewarmed? Is the ActivePrewarm environment variable still supported in iOS 16+? Ideally, the UserDefaults API itself should indicate whether it is returning valid stored values or defaults due to the app being launched in a prewarm session. We understand opting out may impact performance, but data security and integrity are our priority. Any guidance would be greatly appreciated.

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.

Hello everyone, I’m a new developer still learning as I go. I’m building a simple watchOS app that tracks Apple Watch battery consumption, records hourly usage data, and uses that information to predict battery life in hours. I’ve run into an issue where background refresh completely stalls after charging and never recovers, regardless of what I do. The only way to restore normal behavior is to restart the watch. Background refresh can work fine for days, but if the watch is charging and a scheduled background refresh tries to run during that period, it appears to be deferred—and then remains in that deferred state indefinitely. Even reopening the app or scheduling new refreshes doesn’t recover it. Has anyone else encountered this behavior? Is there a reliable workaround? I’ve seen a few reports suggesting that there may be a regression in scheduleBackgroundRefresh() on watchOS 26, where tasks are never delivered after certain states. Any insights or confirmations would be greatly appreciated. Thank you!

How can you force cancel a task that doesn't need cleanup and doesn't check for cancellation? If this cannot be done, would this be a useful addition to Swift? Here is the situation: The async method doesn't check for cancellation since it is not doing anything repetively (for example in a loop). For example, the method may be doing "try JSONDecoder().decode(Dictionary<String, ...>.self, from: data)" where data is a large amount. The method doesn't need cleanup. I would like the force cancellation to throw an error. I am already handling errors for the async method. My intended situation if that the user request the async method to get some JSON encoded data, but since it is taking longer that they are willing to wait, they would tap a cancellation button that the app provides.

First, our app communicates with our blood glucose monitor (CGM) using Bluetooth Low Energy (BLE). On an iPhone 14 Pro with iOS 26.0.1, Bluetooth communication works properly even when the app is in the background and locked. Even if the phone and CGM are disconnected, the app continues to scan in the background and reconnects when the phone and CGM are back in close proximity. It won't be dormant in the background or when the screen is locked. This effectively ensures that diabetic users can monitor their blood glucose levels in real time. However, after using iOS 26.0.1 on the iPhone 17, we've received user feedback about frequent disconnections in the background. Our logs indicate that Bluetooth communication is easily disconnected when switching to the background, and then easily dormant by the system, especially when the user's screen is locked. This situation significantly impacts users' blood glucose monitoring, and users are unacceptable. What can be done?

Hi! I've been developing iOS and macOS apps for many years, but now I am looking to dive into smth i have never touched before, namely privileged helpers, and i am struggling hard trying to find my footing. Here’s my use case: I have a CLI tool that requires elevated privileges. I want to create a menu bar app that can interact with this tool, but I’m struggling to find solid documentation or examples of how to accomplish this using SMAppService. I might just be missing something obvious. If anyone could point me toward relevant documentation, examples, articles, tutorials, or even a WWDC session that covers running privileged helpers with SMAppService, I would greatly appreciate it. Thanks in advance!

I am currently developing a macOS app that can show system HUDs in the Notch Till Sequoia I used to kill the OSDUIHelper process (which displays the default macOS Volume and Brightness control HUDs) - and replaced it with my app's HUDs But, it is not working on macOS Tahoe anymore as the OSDUIHelper process is no longer there due to the UI changes Has the process been renamed - or is there any other way to kill the process?

I'm try to monitor all processes by ES client. But I found the process name is different from the Activity Monitor displayed. As shown in the picture below, there are ShareSheetUI(Pages) and ShareSheetUI(Finder) processes in Activity Monitor, but I can only get the same name ShareSheetUI, I thought of many ways to display the name in parentheses, but nothing worked, so there is a way to display the process name like Activity Monitor?

i am trying to create a daemon with xpc for my app by referring to https://github.com/alienator88/HelperToolApp but i keep getting XPC remote proxy error: Couldn’t communicate with a helper application. All the identifiers all correct but the helper code is not reached.

I'm working on an XPC server and need to determine the owner of the client process that connects to it. Specifically, I'd like to retrieve details such as the fully qualified user name or other identifying information from the XPC client connection.I'm considering using xpc_connection_get_pid() to get the client’s process ID, but I’m unsure of the best way to map this to the user who owns the process. Is there a recommended API or approach to capture this information securely?

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

DESCRIPTION OF PROBLEM Logs and data from our application indicate various errors that strongly suggest that our application is being launched in a state in which the device is likely locked. We are looking for guidance on how to identify, debug, reproduce, and fix these cases. Our application does not use any of the common mechanisms for background activity, such as Background App Refresh, Navigation, Audio, etc. Errors we get in our logs such as "authorization denied (code: 23)" when trying to access a file in our app's container on disk (a simple disk cache for data our application uses) strongly suggest that the device is operating in a state, such as being locked, where our application lacks the requisite permissions it would normally have during operation. Furthermore, attempts to access authentication information stored in the keychain also fails. We use kSecAttrAccessibleWhenUnlocked when accessing items we store in the keychain. We have investigated "Prewarming", as well as our notification extension that helps process incoming push notifications, but cannot find any way to recreate this behavior. Are there any steps Apple engineers can recommend to triage and debug this? Some additional questions that would help us: What are all of the symptoms that we can look for if prewarming escapes the intended execution context? What are all of the circumstances in which we would be unauthorized to access the app’s documents/file directories even if it works correctly in normal operation? STEPS TO REPRODUCE Unfortunately, we are unable to forcibly reproduce this behavior in our application, so we're looking for guidance on how we might simulate this behavior in Xcode / Instruments. Are there tools that Apple provides that would allow us to simulate certain behaviors like prewarming to verify our application's functionality? Are there other reasons our application might be launched while the device is locked? Are there other reasons we would receive security errors when accessing the keychain or disk that are unrelated to the device being locked?

Issue: Background downloads using the flutter_downloader package work perfectly in debug mode and release mode when run directly from Xcode (plugged in). However, when I create an archive build and install the app separately (via TestFlight or direct IPA install), the background download stops working as soon as the app is minimized. ✅ What I’ve already done Info.plist <key>UIBackgroundModes</key> <array> <string>remote-notification</string> <string>fetch</string> <string>processing</string> <string>audio</string> <string>push-to-talk</string> </array> AppDelegate.swift import UIKit import Flutter import Firebase import flutter_downloader import BackgroundTasks @main @objc class AppDelegate: FlutterAppDelegate { static let backgroundChannel = "com.example.app/background_service" private var backgroundCompletionHandler: (() -> Void)? override func application( _ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? ) -> Bool { FirebaseApp.configure() GeneratedPluginRegistrant.register(with: self) FlutterDownloaderPlugin.setPluginRegistrantCallback(registerPlugins) if #available(iOS 10.0, *) { UNUserNotificationCenter.current().delegate = self } if #available(iOS 13.0, *) { registerBackgroundTask() } return super.application(application, didFinishLaunchingWithOptions: launchOptions) } @available(iOS 13.0, *) private func registerBackgroundTask() { BGTaskScheduler.shared.register( forTaskWithIdentifier: "com.example.app.process_download_queue", using: nil ) { [weak self] task in guard let self = self else { return } self.handleDownloadQueueTask(task: task as! BGProcessingTask) } } @available(iOS 13.0, *) private func handleDownloadQueueTask(task: BGProcessingTask) { scheduleNextDownloadTask() let headlessEngine = FlutterEngine(name: "BackgroundTaskEngine", project: nil, allowHeadlessExecution: true) headlessEngine.run() let channel = FlutterMethodChannel( name: AppDelegate.backgroundChannel, binaryMessenger: headlessEngine.binaryMessenger ) task.expirationHandler = { channel.invokeMethod("backgroundTaskExpired", arguments: nil) } channel.invokeMethod("processNextInBackground", arguments: nil) { result in task.setTaskCompleted(success: (result as? Bool) ?? false) } } override func application( _ application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: @escaping () -> Void ) { self.backgroundCompletionHandler = completionHandler super.application(application, handleEventsForBackgroundURLSession: identifier, completionHandler: completionHandler) } override func applicationDidEnterBackground(_ application: UIApplication) { if #available(iOS 13.0, *) { scheduleNextDownloadTask() } } @available(iOS 10.0, *) override func userNotificationCenter( _ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void ) { if #available(iOS 14.0, *) { completionHandler([.list, .banner, .badge, .sound]) } else { completionHandler([.alert, .badge, .sound]) } } @available(iOS 10.0, *) override func userNotificationCenter( _ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -> Void ) { completionHandler() } } // MARK: - Helper @available(iOS 13.0, *) func scheduleNextDownloadTask() { let request = BGProcessingTaskRequest(identifier: "com.example.app.process_download_queue") request.requiresNetworkConnectivity = true request.requiresExternalPower = false request.earliestBeginDate = Date(timeIntervalSinceNow: 60) do { try BGTaskScheduler.shared.submit(request) print("BGTask: Download queue processing task scheduled successfully.") } catch { print("BGTask: Could not schedule download queue task: \(error)") } } private func registerPlugins(registry: FlutterPluginRegistry) { if !registry.hasPlugin("FlutterDownloaderPlugin") { FlutterDownloaderPlugin.register(with: registry.registrar(forPlugin: "FlutterDownloaderPlugin")!) } } 🧩 Observations Background download works correctly when: The app is plugged in and run via Xcode (release/debug) It stops working when: The app is installed from an archived build (IPA/TestFlight) and minimized All entitlements and background modes are properly added. Provisioning profile includes required background modes. ❓Question Is there any known limitation or signing difference between Xcode run and archived release builds that could cause URLSession background tasks not to trigger? Has anyone faced a similar issue when using flutter_downloader on iOS 13+ with BGTaskScheduler or URLSession background configuration? Any help or working setup example for production/TestFlight would be appreciated.

If I create a BGContinuedProcessingTaskRequest, register it, and then "do work" within it appropriately reporting progress, and before my task has finished doing all the work it had to do, its expirationHandler triggers... does the task later try again? Or does it lose the execution opportunity until the app is next re-launched to the foreground? In my testing, I never saw my task execute again once expired (which suggests the latter?). I was able to easily force this expiry by starting my task, backgrounding my app, then launching the iOS Camera App. My example is just using test code inspired from https://developer.apple.com/documentation/backgroundtasks/performing-long-running-tasks-on-ios-and-ipados let request = BGContinuedProcessingTaskRequest(identifier: taskIdentifier, title: "Video Upload", subtitle: "Starting Upload") request.strategy = .queue BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: nil) { task in guard let task = task as? BGContinuedProcessingTask else { return } print("i am a good task") var wasExpired = false task.expirationHandler = { wasExpired = true } let progress = task.progress progress.totalUnitCount = 100 while !progress.isFinished && !wasExpired { progress.completedUnitCount += 1 let formattedProgress = String(format: "%.2f", progress.fractionCompleted * 100) task.updateTitle(task.title, subtitle: "Completed \(formattedProgress)%") sleep(1) } if progress.isFinished { print ("i was a good task") task.setTaskCompleted(success: true) } else { print("i was not a good task") task.setTaskCompleted(success: false) } } try? BGTaskScheduler.shared.submit(request) Apologies if this is clearly stated somewhere and I'm missing it.

For example, let’s propose an XPC service that can connect to websites. Suppose that I want to connect to Apple.com, microsoft.com, and ibm.com. Can 3 service objects be made between the service and client? Or does the service have to return an ID for each web connection, with the client needing to specify which connection ID along with a command?

Just trying to understand the documentation. Obviously, we can send a request to the service to return all the data at once. Can the data arrive in pieces, involving either multiple async callbacks or a Combine Publisher?

Im using the low-level C xpc api <xpc/xpc.h> and i get this error when I run it: Underlying connection interrupted. I know this error stems from the call to xpc_session_send_message_with_reply_sync(session, message, &reply_err);. I have no previous experience with xpc or dispatch and I find the xpc docs very limited and I also found next to no code examples online. Can somebody take a look at my code and tell me what I did wrong and how to fix it? Thank you in advance. Main code: #include <stdio.h> #include <xpc/xpc.h> #include <dispatch/dispatch.h> // the context passed to mainf() struct context { char* text; xpc_session_t sess; }; // This is for later implementation and the name is also rudimentary void mainf(void* c) { //char * text = ((struct context*)c)->text; xpc_session_t session = ((struct context*)c)->sess; dispatch_queue_t messageq = dispatch_queue_create("y.ddd.main", DISPATCH_QUEUE_SERIAL); xpc_object_t message = xpc_dictionary_create(NULL, NULL, 0); xpc_dictionary_set_string(message, "test", "eeeee"); if (session == NULL) { printf("Session is NULL\n"); exit(1); } __block xpc_rich_error_t reply_err = NULL; __block xpc_object_t reply; dispatch_sync(messageq, ^{ reply = xpc_session_send_message_with_reply_sync(session, message, &reply_err); if (reply_err != NULL) printf("Reply Error: %s\n", xpc_rich_error_copy_description(reply_err)); }); if (reply != NULL) printf("Reply: %s\n", xpc_dictionary_get_string(reply, "test")); else printf("Reply is NULL\n"); } int main(int argc, char* argv[]) { // Create seperate queue for mainf() dispatch_queue_t mainq = dispatch_queue_create("y.ddd.main", DISPATCH_QUEUE_CONCURRENT); dispatch_queue_t xpcq = dispatch_queue_create("y.ddd.xpc", NULL); // Create the context being sent to mainf struct context* c = malloc(sizeof(struct context)); c->text = malloc(sizeof("Hello")); strcpy(c->text, "Hello"); xpc_rich_error_t sess_err = NULL; xpc_session_t session = xpc_session_create_xpc_service("y.getFilec", xpcq, XPC_SESSION_CREATE_INACTIVE, &sess_err); if (sess_err != NULL) { printf("Session Create Error: %s\n", xpc_rich_error_copy_description(sess_err)); xpc_release(sess_err); exit(1); } xpc_release(sess_err); xpc_session_set_incoming_message_handler(session, ^(xpc_object_t message) { printf("message recieved\n"); }); c->sess = session; xpc_rich_error_t sess_ac_err = NULL; xpc_session_activate(session, &sess_ac_err); if (sess_err != NULL) { printf("Session Activate Error: %s\n", xpc_rich_error_copy_description(sess_ac_err)); xpc_release(sess_ac_err); exit(1); } xpc_release(sess_ac_err); xpc_retain(session); dispatch_async_f(mainq, (void*)c, mainf); xpc_release(session); dispatch_main(); } XPC Service code: #include <stdio.h> #include <xpc/xpc.h> #include <dispatch/dispatch.h> int main(void) { xpc_rich_error_t lis_err = NULL; xpc_listener_t listener = xpc_listener_create("y.getFilec", NULL, XPC_LISTENER_CREATE_INACTIVE, ^(xpc_session_t sess){ printf("Incoming Session: %s\n", xpc_session_copy_description(sess)); xpc_session_set_incoming_message_handler(sess, ^(xpc_object_t mess) { xpc_object_t repl = xpc_dictionary_create_empty(); xpc_dictionary_set_string(repl, "test", "test"); xpc_rich_error_t send_repl_err = xpc_session_send_message(sess, repl); if (send_repl_err != NULL) printf("Send Reply Error: %s\n", xpc_rich_error_copy_description(send_repl_err)); }); xpc_rich_error_t sess_ac_err = NULL; xpc_session_activate(sess, &sess_ac_err); if (sess_ac_err != NULL) printf("Session Activate: %s\n", xpc_rich_error_copy_description(sess_ac_err)); }, &lis_err); if (lis_err != NULL) { printf("Listener Error: %s\n", xpc_rich_error_copy_description(lis_err)); xpc_release(lis_err); } xpc_rich_error_t lis_ac_err = NULL; xpc_listener_activate(listener, &lis_ac_err); if (lis_ac_err != NULL) { printf("Listener Activate Error: %s\n", xpc_rich_error_copy_description(lis_ac_err)); xpc_release(lis_ac_err); } dispatch_main(); }

In the header for workloop.h there is this note: A dispatch workloop is a "subclass" of dispatch_queue_t which can be passed to all APIs accepting a dispatch queue, except for functions from the dispatch_sync() family. dispatch_async_and_wait() must be used for workloop objects. Functions from the dispatch_sync() family on queues targeting a workloop are still permitted but discouraged for performance reasons. I have a couple questions related to this. First, I'd like to better understand what the alluded-to 'performance reasons' are that cause this pattern to be discouraged in the 'queues targeting a workloop' scenario. From further interrogation of the headers, I've found these explicit callouts regarding differences in the dispatch_sync and dispatch_async_and_wait API: dispatch_sync: Work items submitted to a queue with dispatch_sync() do not observe certain queue attributes of that queue when invoked (such as autorelease frequency and QOS class). dispatch_async_and_wait: Work items submitted to a queue with dispatch_async_and_wait() observe all queue attributes of that queue when invoked (inluding [sic] autorelease frequency or QOS class). Additionally, dispatch_async_and_wait has a section of the headers devoted to 'Differences with dispatch_sync()', though I can't say I entirely follow the distinctions it attempts to draw. Based on that, my best guess is that the 'performance reasons' are something about either QoS not being properly respected/observed or some thread context switching differences that can degrade performance, but I would appreciate insight from someone with more domain knowledge. My second question is a bit more general – taking a step back, why exactly do these two API exist? It's not clear to me from the existing documentation I've found why I would/should prefer dispatch_sync over dispatch_async_and_wait (other than the aforementioned callout noting the former is unsupported on workloops). What is the motivation for preserving both these API vs deprecating dispatch_sync in favor of dispatch_async_and_wait (or functionally subsuming one with the other)? Credit to Luna for originally posing/inspiring these questions.

After logging in to the main App, turn on screen recording, then switch to the interface of another App to perform operations. After about ten-odd minutes, when returning to the main App, it was found that the app was forcefully quit by the system, and subsequent operations could not be carried out.

iOS BGProcessingTask + Background Upload Not Executing Reliably on TestFlight (Works in Debug) Description: We are facing an issue with BGTaskScheduler and BGProcessingTask when trying to perform a background audio-upload flow on iOS. The behavior is inconsistent between Debug builds and TestFlight (Release) builds. Summary of the Problem Our application records long audio files (up to 1 hour) and triggers a background upload using: BGTaskScheduler BGProcessingTaskRequest Background URLSession (background with identifier) URLSession background upload task + AppDelegate.handleEventsForBackgroundURLSession In Debug mode (Xcode → Run on device), everything works as expected: BGProcessingTask executes handleEventsForBackgroundURLSession fires Background URLSession continues uploads reliably Long audio files successfully upload even when the app is in background or terminated However, in TestFlight / Release mode, the system does not reliably launch the BGProcessingTask or Background URLSession events. Technical Details We explicitly register BGTaskScheduler: BGTaskScheduler.shared.register( forTaskWithIdentifier: "example.background.process", using: nil ) { task in self.handleBackgroundProcessing(task: task as! BGProcessingTask) } We schedule it using: let request = BGProcessingTaskRequest(identifier: "example.background.process") request.requiresNetworkConnectivity = true request.requiresExternalPower = false try BGTaskScheduler.shared.submit(request) We also use Background URLSession: let config = URLSessionConfiguration.background(withIdentifier: sessionId) config.sessionSendsLaunchEvents = true config.isDiscretionary = false AppDelegate.handleEventsForBackgroundURLSession is implemented correctly and works in Debug. Issue Observed (TestFlight Only) In TestFlight builds: BGProcessingTask rarely triggers, or the system marks it as NO LONGER RUNNING. Background upload tasks sometimes never start or complete. No logs appear from our BGProcessingTask handler. system logs show messages like: NO LONGER RUNNING bgProcessing-example.background.process Tasks running in group [com.apple.dasd.defaultNetwork] are 1! This occurs most frequently for large audio uploads (30–60 minutes), while small files behave normally. What We Have Verified Proper Info.plist values: Permitted background modes: processing, audio, fetch BGTaskSchedulerPermittedIdentifiers contains our identifier BGProcessingTask is being submitted successfully (no errors) App has microphone permission + background audio works Device plugged/unplugged doesn’t change outcome Key Question for Apple We need clarification on: Why BGProcessingTask behave differently between Debug and TestFlight builds? Are there additional restrictions or heuristics (related to file size, CPU usage, runtime, network load, or power constraints) that cause BGProcessingTask to be throttled or skipped in Release/TestFlight? How can we guarantee a background upload continues reliably for large files (100MB–500MB) on TestFlight and App Store builds? Is there an Apple-recommended pattern to combine BGProcessingTask + Background URLSession for long-running uploads? Expected Result Background uploads should continue reliably for long audio files (>30 minutes) when the app goes to background or is terminated, in the same way they currently function in Debug builds.