General: DevForums subtopic: App & System Services > Processes & Concurrency Processes & concurrency covers a number of different technologies: Background Tasks Resources Concurrency Resources — This includes Swift concurrency. Service Management Resources XPC Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

We are experiencing a crash in our application that only occurs on devices running iOS beta 26. It looks like a Beta problem. The crash appears to be caused by an excessive number of open File Descriptors. We identified this after noticing a series of crashes in different parts of the code each time the app was launched. Sometimes it would crash right at the beginning, when trying to load the Firebase plist file. That’s when we noticed a log message saying “too many open files,” and upon further investigation, we found that an excessive number of File Descriptors were open in our app, right after the didFinishLaunching method of the AppDelegate. We used the native Darwin library to log information about the FDs and collected the following: func logFDs() { var rlim = rlimit() if getrlimit(RLIMIT_NOFILE, &rlim) == 0 { print("FD LIMIT: soft: \(rlim.rlim_cur), hard: \(rlim.rlim_max)") } // Count open FDs before Firebase let openFDsBefore = countOpenFileDescriptors() print("Open file descriptors BEFORE Firebase.configure(): \(openFDsBefore)") } private func countOpenFileDescriptors() -> Int { var count = 0 let maxFD = getdtablesize() for fd in 0..<maxFD { if fcntl(fd, F_GETFD) != -1 { count += 1 } } return count } With this code, we obtained the following data: On a device with iOS 26 Beta 1, 2, or 3: FD LIMIT: soft: 256, hard: 9223372036854775807 Open file descriptors BEFORE Firebase.configure(): 256 On a device with iOS 18: FD LIMIT: soft: 256, hard: 9223372036854775807 Open file descriptors BEFORE Firebase.configure(): 57 In the case of the device running iOS 26 beta, the app crashes when executing Firebase.configure() because it cannot open the plist file, even though it can be found at the correct path — meaning the OS locates it. To confirm this was indeed the issue, we used the following code to close FDs before proceeding with Firebase configuration. By placing a breakpoint just before Firebase.configure() and running the following LLDB command: expr -l c -- for (int fd = 180; fd < 256; fd++) { (int)close(fd); } This released the FDs, allowing Firebase to proceed with its configuration as expected. However, the app would later crash again after hitting the soft limit of file descriptors once more. Digging deeper, we used this code to try to identify which FDs were being opened and causing the soft limit to be exceeded: func checkFDPath() { var r = rlimit() if getrlimit(RLIMIT_NOFILE, &r) == 0 { print("FD LIMIT: soft: \(r.rlim_cur), hard: \(r.rlim_max)") for fd in 0..<Int32(r.rlim_cur) { var path = [CChar](repeating: 0, count: Int(PATH_MAX)) if fcntl(fd, F_GETPATH, &path) != -1 { print(String(cString: path)) } } } } We ran this command at the very beginning of the didFinishLaunching method in the AppDelegate. On iOS 26, the log repeatedly showed Cryptexes creating a massive number of FDs, such as: /dev/null /dev/ttys000 /dev/ttys000 /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Application Support/DTX_8.191.1.1003.sqlite /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Caches/KSCrash/MyAppScheme/Data/ConsoleLog.txt /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-wal /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-shm /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.01 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.11 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.12 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.13 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.14 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.15 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.16 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.17 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.18 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.19 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.20 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.21 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.22 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.23 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.24 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.25 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.26 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.29 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.30 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.31 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.32 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e … This repeats itself a lot of times. … /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40

Hello! We are in the progress of migrating a large Swift 5.10 legacy code base over to use Swift 6.0 with Strict Concurrency checking. We have already stumbled across a few weird edge cases where the "guaranteed" @MainActor isolation is violated (such as with @objc #selector methods used with NotificationCenter). However, we recently found a new scenario where our app crashes accessing main actor isolated state on a background thread, and it was surprising that the compiler couldn't warn us. Minimal reproducible example: class ViewController: UIViewController { var isolatedStateString = "Some main actor isolated state" override func viewDidLoad() { exampleMethod() } /// Note: A `@MainActor` isolated method in a `@MainActor` isolated class. func exampleMethod() { testAsyncMethod() { [weak self] in // !!! Crash !!! MainActor.assertIsolated() // This callback inherits @MainActor from the class definition, but it is called on a background thread. // It is an error to mutate main actor isolated state off the main thread... self?.isolatedStateString = "Let me mutate my isolated state" } } func testAsyncMethod(completionHandler: (@escaping () -> Void)) { let group = DispatchGroup() let queue = DispatchQueue.global() // The compiler is totally fine with calling this on a background thread. group.notify(queue: queue) { completionHandler() } // The below code at least gives us a compiler warning to add `@Sendable` to our closure argument, which is helpful. // DispatchQueue.global().async { // completionHandler() // } } } The problem: In the above code, the completionHandler implementation inherits main actor isolation from the UIViewController class. However, when we call exampleMethod(), we crash because the completionHandler is called on a background thread via the DispatchGroup.notify(queue:). If were to instead use DispatchQueue.global().async (snippet at the bottom of the sample), the compiler helpfully warns us that completionHandler must be Sendable. Unfortunately, DispatchGroup's notify gives us no such compiler warnings. Thus, we crash at runtime. So my questions are: Why can't the compiler warn us about a potential problem with DispatchGroup().notify(queue:) like it can with DispatchQueue.global().async? How can we address this problem in a holistic way in our app, as it's a very simple mistake to make (with very bad consequences) while we migrate off GCD? I'm sure the broader answer here is "don't mix GCD and Concurrency", but unfortunately that's a little unavoidable as we migrate our large legacy code base! 🙂

It looks like ExtensionKit (and ExtensionFoundation) is fully available on iOS 26 but there is no mention about this in WWDC. From my testing, it seems as of beta 1, ExtensionKit allows the app from one dev team to launch extension provided by another dev team. Before we start building on this, can someone from Apple help confirm this is the intentional behavior and not just beta 1 thing?

Hi everyone, could you help us? We implemented a Flutter library that basically makes a call every x minutes if the app is in the background, but when I generate the version via TestFlight for testing, it doesn't work. Can you help us understand why? Below is a more detailed technical description. Apple Developer Technical Support Request Subject: BGTaskScheduler / Background Tasks Not Executing in TestFlight - Flutter App with workmanager Plugin Issue Summary Background tasks scheduled using BGTaskScheduler are not executing when the app is distributed via TestFlight. The same implementation works correctly when running the app locally via USB/Xcode debugging. We are developing a Flutter application that needs to perform periodic API calls when the app is in the background. We have followed all documentation and implemented the required configurations, but background tasks are not being executed in the TestFlight build. App Information Field Value App Version 3.1.15 (Build 311) iOS Minimum Deployment Target iOS 15.0 Framework Flutter Flutter SDK Version ^3.7.2 Technical Environment Flutter Dependencies (Background Task Related) Package Version Purpose workmanager ^0.9.0+3 Main background task scheduler (uses BGTaskScheduler on iOS 13+) flutter_background_service ^5.0.5 Background service management flutter_background_service_android ^6.2.4 Android-specific background service flutter_local_notifications ^19.4.2 Local notifications for background alerts timezone ^0.10.0 Timezone support for scheduling Other Relevant Flutter Dependencies Package Version firebase_core 4.0.0 firebase_messaging (via native Podfile) sfmc (Salesforce Marketing Cloud) ^9.0.0 geolocator ^14.0.0 permission_handler ^12.0.0+1 Info.plist Configuration We have added the following configurations to Info.plist: UIBackgroundModes <key>UIBackgroundModes</key> <array> <string>location</string> <string>remote-notification</string> <string>processing</string> </array> ### BGTaskSchedulerPermittedIdentifiers ```xml <key>BGTaskSchedulerPermittedIdentifiers</key> <array> <string>br.com.unidas.apprac.ios.workmanager.carrinho_api_task</string> <string>br.com.unidas.apprac.ios.workmanager</string> <string>be.tramckrijter.workmanager.BackgroundTask</string> </array> **Note:** We included multiple identifier formats as recommended by the `workmanager` Flutter plugin documentation: 1. `{bundleId}.ios.workmanager.{taskName}` - Custom task identifier 2. `{bundleId}.ios.workmanager` - Default workmanager identifier 3. `be.tramckrijter.workmanager.BackgroundTask` - Plugin's default identifier (as per plugin documentation) ## AppDelegate.swift Configuration We have configured the `AppDelegate.swift` with the following background processing setup: ```swift // In application(_:didFinishLaunchingWithOptions:) // Configuration to enable background processing via WorkManager // The "processing" mode in UIBackgroundModes allows WorkManager to use BGTaskScheduler (iOS 13+) // This is required to execute scheduled tasks in background (e.g., API calls) // Note: User still needs to have Background App Refresh enabled in iOS settings if UIApplication.shared.backgroundRefreshStatus == .available { // Allows iOS system to schedule background tasks with minimum interval UIApplication.shared.setMinimumBackgroundFetchInterval(UIApplication.backgroundFetchIntervalMinimum) } ## WorkManager Implementation (Dart/Flutter) ### Initialization ```dart /// Initializes WorkManager static Future<void> initialize() async { await Workmanager().initialize(callbackDispatcher, isInDebugMode: false); print('WorkManagerService: WorkManager initialized'); } ### Task Registration /// Schedules API execution after a specific delay ## Observed Behavior ### Works (Debug/USB Connection) - When running the app via Xcode/USB debugging - Background tasks are scheduled and executed as expected - API calls are made successfully when the app is backgrounded ### Does NOT Work (TestFlight) - When the app is distributed via TestFlight - Background tasks appear to be scheduled (no errors in code) - Tasks are **never executed** when the app is in background - We have tested with: - Background App Refresh enabled in iOS Settings - App used frequently - Device connected to WiFi and charging - Waited for extended periods (hours) ## Possible heart points 1. **Are there any additional configurations required for `BGTaskScheduler` to work in TestFlight/Production builds that are not required for debug builds?** 2. **Is the identifier format correct?** We are using: `br.com.unidas.apprac.ios.workmanager.carrinho_api_task` - Should it match exactly with the task name registered in code? 3. **Are there any known issues with Flutter's `workmanager` plugin and iOS BGTaskScheduler in production environments?** 4. **Is there any way to verify through logs or system diagnostics if the background tasks are being rejected by the system?** 5. **Could there be any conflict between our other background modes (`location`, `remote-notification`) and `processing`?** 6. **Does the Salesforce Marketing Cloud SDK (SFMC) interfere with BGTaskScheduler operations?** ## Additional Context - We have verified that `Background App Refresh` is enabled for our app in iOS Settings - The app has proper entitlements for push notifications and location services - Firebase, SFMC (Salesforce Marketing Cloud), and other SDKs are properly configured - The issue is **only** present in TestFlight builds, not in debug/USB-connected builds ## References - [Apple Documentation - BGTaskScheduler](https://developer.apple.com/documentation/backgroundtasks/bgtaskscheduler) - [Apple Documentation - Choosing Background Strategies](https://developer.apple.com/documentation/backgroundtasks/choosing_background_strategies_for_your_app) Thank you

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?

I’m looking for an authoritative answer on how BGAppRefreshTask behaves after a user force-quits an app (swipes it away in the App Switcher). My app relies on early-morning background refresh to prepare and schedule notifications based on user-defined thresholds and weather forecasts. Behavior across devices seems inconsistent, however: sometimes a scheduled background refresh still runs, and other times it appears completely blocked. Apple’s documentation doesn’t clearly state what should happen, and developer discussions conflict. Could someone from Apple please clarify: Will a previously scheduled BGAppRefreshTask run after the user force-quits the app? If not, is there a recommended alternative for time-sensitive updates that must schedule user alerts? What is the expected system behavior regarding the predictability of background refresh after a force-quit? A definitive answer would help ensure the app aligns with intended system behavior. Thanks!

To establish a privileged helper daemon from a command line app to handle actions requiring root privileges I still use the old way of SMJobBless. But this is deprecated since OSX 10.13 and I want to finally update it to the new way using SMAppService. As I'm concerned with securing it against malicious exploits, do you have a recommended up-to-date implementation in Objective-C establishing a privileged helper and verifying it is only used by my signed app? I've seen the suggestion in the documentation to use SMAppService, but couldn't find a good implementation covering security aspects. My old implementation in brief is as follows: bool runJobBless () { // check if already installed NSFileManager* filemgr = [NSFileManager defaultManager]; if ([filemgr fileExistsAtPath:@"/Library/PrivilegedHelperTools/com.company.Helper"] && [filemgr fileExistsAtPath:@"/Library/LaunchDaemons/com.company.Helper.plist"]) { // check helper version to match the client // ... return true; } // create authorization reference AuthorizationRef authRef; OSStatus status = AuthorizationCreate (NULL, kAuthorizationEmptyEnvironment, kAuthorizationFlagDefaults, &authRef); if (status != errAuthorizationSuccess) return false; // obtain rights to install privileged helper AuthorizationItem authItem = { kSMRightBlessPrivilegedHelper, 0, NULL, 0 }; AuthorizationRights authRights = { 1, &authItem }; AuthorizationFlags flags = kAuthorizationFlagDefaults | kAuthorizationFlagInteractionAllowed | kAuthorizationFlagPreAuthorize | kAuthorizationFlagExtendRights; status = AuthorizationCopyRights (authRef, &authRights, kAuthorizationEmptyEnvironment, flags, NULL); if (status != errAuthorizationSuccess) return false; // SMJobBless does it all: verify helper against app and vice-versa, place and load embedded launchd.plist in /Library/LaunchDaemons, place executable in /Library/PrivilegedHelperTools CFErrorRef cfError; if (!SMJobBless (kSMDomainSystemLaunchd, (CFStringRef)@"com.company.Helper", authRef, &cfError)) { // check helper version to match the client // ... return true; } else { CFBridgingRelease (cfError); return false; } } void connectToHelper () { // connect to helper via XPC NSXPCConnection* c = [[NSXPCConnection alloc] initWithMachServiceName:@"com.company.Helper.mach" options:NSXPCConnectionPrivileged]; c.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol (SilentInstallHelperProtocol)]; [c resume]; // call function on helper and wait for completion dispatch_semaphore_t semaphore = dispatch_semaphore_create (0); [[c remoteObjectProxy] callFunction:^() { dispatch_semaphore_signal (semaphore); }]; dispatch_semaphore_wait (semaphore, dispatch_time (DISPATCH_TIME_NOW, 10 * NSEC_PER_SEC)); dispatch_release (semaphore); [c invalidate]; [c release]; }

Hi, I'll explain my question through how whatsapp does it. When the phone is locked then whatsapp routes call through apple's native callkit When unlocked, pressing accept essentially redirects to whatsapp and then whatsapp handles the call from there. However, this component of unlock detection is what I'm not able to find any info about. Essentially, how i do it is: let isPhoneLocked = !UIApplication.shared.isProtectedDataAvailable isProtectedDataAvailable == true → device is unlocked isProtectedDataAvailable == false → device is locked The problem is that if the phone has been recently unlocked, then protected data is still available on the phone even after the lock for the next 10-40 seconds. So theres a false positive. I want there to be a foolproof and robust way to do this. And I'm not entirely sure how

Hi everyone, I’m trying to register fonts system-wide using CTFontManagerRegisterFontURLs with the .persistent scope. The fonts are delivered through Apple-Hosted Background Assets (since On-Demand Resources are deprecated). Process-level registration works perfectly, but persistent registration triggers a system “Install Fonts” prompt, and tapping Install causes the app to crash immediately. I’m wondering if anyone has successfully used Apple-Hosted Background Assets to provide persistent, system-wide installable fonts, or if this is a current OS limitation/bug. What I Expect Fonts delivered through Apple-Hosted Background Assets should be eligible for system-wide installation Tap “Install” should install fonts into Settings → Fonts just like app-bundled or ODR fonts App should not crash Why This Matters According to: WWDC 2019: Font Management and Text Scaling Developers can build font provider apps that install fonts system-wide, using bundled or On-Demand Resources. WWDC 2025: Discover Apple-Hosted Background Assets On-Demand Resources are deprecated, and AHBAs are the modern replacement. Therefore, persistent font installation via Apple-Hosted Background Assets appears to be the intended path moving forward. Question Is this a known limitation or bug in iOS? Should .persistent font installation work with Apple-Hosted Background Assets? Do we need additional entitlement, manifest configuration, or packaging rules? Any guidance or confirmation from Apple engineers would be greatly appreciated. Additional Info I submitted a Feedback including a minimal reproducible sample project: FB21109320

Hi there, First thanks for all the work on BGContinuedProcessingTask! It looks really promising. I have a question / issue around the behavior when a BGContinuedProcessingTask expires. Here is my setup. I have an app who's responsible for uploading large files in the field (AKA wifi is not expected) For a given file, it can likely fail due to network conditions I'm using Multipart upload though so I can retry a file to pick up where it left off. I use one taskIdentifier per file, and when the file fails, I can retry the task and have it continue where it left off (I am reusing the taskIdentifier here for retries, let me know if I shouldn't be doing that) Here is the behavior I am seeing I start an upload, it seems to be uploading normally I turn on airplane mode to simulate expiration of the task the task fails as expected after ~30 seconds, and I see the failure in my home screen. I have callbacks in the task to put my app in the proper state on expiration / failure I turn back on airplane mode and I retry the task, the way I do this is I do NOT re-register, I simply re-submit the task with the same TaskIdentifier. What I would have expected is that the failure task is REPLACED with the new task and new progress. Instead what I see is TWO ContinuedBackgroundProcessingTasks, one in the failure state and one in progress. My question is How can I make retries reuse the same task notification item? OR if that's not possible, how do I programmatically clear the task failure? I've tried cancelTask but that doesn't seem to clear it.

Started a new X-Code Project after updating to 26.0.1 and realized that I get an error when trying to mark a class as ObservableObject => "Class XYZ does not conform to Protocol 'ObservableObject'. Strange behaviour, because at old projects the code is working even though the build options are the same and other settings like iOS version in Target are the same. There must be something chaged under the hood of XCode? I have to import Combine now, before I could write my class, e.g. CoreData Datamanager: ObservableObject only using CoreData.

I'm specifically focused on Live Activity, but I think this is somewhat a general question. The app could get a few callbacks when: There's a new payload (start, update, end) There's a new token (start, update) There's some other lifecycle event (stale, dismissed) Assuming that the user didn't force kill the app, would the app get launched in all these scenarios? When OS launches the app for a reason, should we wrap our tasks with beginBackgroundTask or that's unnecessary if we're expecting our tasks to finish within 30 seconds? Or the OS may sometimes be under stress and give you far less time (example 3 seconds) and if you're in slow internet, then adding beginBackgroundTask may actually come in handy?

Currently I am trying to find a work around to fetch data from server and update user defaults when app is forced quit. Can anyone suggest for this ?

We added the com.apple.developer.background-tasks.continued-processing.gpu key to the entitlement file and set it to true, but BGTaskScheduler.supportedResources does not include gpu. How can we configure it to obtain permission for GPU access in the background? Test device: iPhone 16 Pro Max, iOS 26 release version.

Since macOS 26, including the latest 26.1, the menu bar icon does not show up for our app called Plover which is built with PySide6 (based on Qt 6) and runs via a relocatable python that is packaged into the app. The code is open source and can be found on GitHub. The latest release, including the notarized DMG, can be found here. When running the .app via the command below, the menu bar icon does show up but the process that is running is python3.13 and not Plover: /Applications/Plover.app/Contents/MacOS/Plover -l debug When running the app by just clicking on the application icon, the process is Plover but the menu bar icon is not showing - also not in the settings (Menu Bar > Allow in the Menu Bar). Before macOS 26, the menu bar icon was always shown. Some pointers to potentially relevant parts of our code: shell script that builds the .app Info.plist plover_launcher.c trayicon.py This problem might be related to this thread, including the discussion around Qt not calling NSApplicationMain. What I'm trying to figure out is whether this is a problem with macOS 26, Qt 6, PySide6, or our code. Any pointers are highly appreciated!

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?

I’m currently porting a Chrome Extension to Safari and integrating it with native messaging in a Safari Web Extension. As part of this, I’m building a proxy to forward messages between the web extension and a socket in another application, both ways. Additionally, the socket occasionally broadcasts messages that also need to be sent to the web extension. The issue I’m facing is that the app extension terminates whenever I call context.completeRequest(returningItems: nil), which prevents me from listening for incoming messages from the socket (I'm using the Network Framework). To work around this, I’ve tried not calling context.completeRequest(returningItems: nil), which keeps the app extension running. However, I’m unsure if this is the right approach—currently, I’m simply ignoring the response and relying entirely on SFSafariApplication.dispatchMessage. According to the documentation, the app extension lifecycle ends when the system terminates it, but I need to keep the socket listener active. Has anyone encountered a similar issue, or does anyone have suggestions for maintaining the socket connection while adhering to the app extension lifecycle? Any insights would be greatly appreciated!

I have implemented a XPC server using C APIs. I want to write unit tests for it. I came across the following links that use Swift APIs- Testing and Debugging XPC Code With an Anonymous Listener TN3113 I have tried to write anonymous listener code and the client code in the same file, using C APIs- #include <unistd.h> #include <syslog.h> #include <pthread.h> #include <stdio.h> #include <xpc/xpc.h> #include <xpc/connection.h> #include <CoreFoundation/CoreFoundation.h> static void Anon_Client_Connection_Handler(xpc_connection_t connection, xpc_object_t clientMessage) { const char *description = xpc_copy_description(clientMessage); printf("Event received - %s\n", description); free((void *)description); xpc_type_t type = xpc_get_type(clientMessage); if (type == XPC_TYPE_ERROR) { if (clientMessage == XPC_ERROR_CONNECTION_INVALID) printf("Client_Connection_Handler received invalid connection n"); else if (clientMessage == XPC_ERROR_TERMINATION_IMMINENT) printf("Client_Connection_Handler received termination notice n"); } else { const char *clientMsg = xpc_dictionary_get_string(clientMessage, "message"); printf("Received from client: %s ", clientMsg); } } static void Anon_Listener_Connection_Handler(xpc_connection_t connection) { printf("Anon_Listener_Connection_Handler called, setting up event handler \n"); xpc_connection_set_event_handler(connection, ^(xpc_object_t clientMessage) { printf("Processing the connection! \n"); Anon_Client_Connection_Handler(connection, clientMessage); }); xpc_connection_resume(connection); } int main(int argc, const char *argv[]) { xpc_connection_t anon_listener = xpc_connection_create(NULL, NULL); xpc_connection_set_event_handler(anon_listener, ^(xpc_object_t clientConnection) { printf("Client tried to connect \n"); Anon_Listener_Connection_Handler(clientConnection); }); xpc_connection_resume(anon_listener); printf("\nINFO Anonymous connection resumed"); xpc_object_t anon_endpoint = xpc_endpoint_create(anon_listener); xpc_connection_t clientConnection = xpc_connection_create_from_endpoint(anon_endpoint); xpc_object_t message = xpc_dictionary_create(NULL, NULL, 0); xpc_dictionary_set_string(message, "message", "client's message"); xpc_connection_send_message_with_reply(clientConnection, message, dispatch_get_main_queue(), ^(xpc_object_t event) { printf("\nINFO inside reply"); const char *description = xpc_copy_description(event); printf("\nINFO %s",description); free((void *)description); }); xpc_release(message); xpc_release(anon_listener); printf("\nINFO Releasing listener"); xpc_release(anon_endpoint); printf("\nINFO Releasing endpoint"); // dispatch_main(); return 0; } and this is the output I get INFO Anonymous connection resumed INFO Releasing listener INFO Releasing endpoint I am not able to connect to the client and exchange messages. Where am I going wrong?