General: Forums subtopic: App & System Services > Processes & Concurrency Forums tag: Background Tasks Background Tasks framework documentation UIApplication background tasks documentation ProcessInfo expiring activity documentation Using background tasks documentation for watchOS Performing long-running tasks on iOS and iPadOS documentation WWDC 2020 Session 10063 Background execution demystified — This is critical resource. Watch it! [1] WWDC 2022 Session 10142 Efficiency awaits: Background tasks in SwiftUI WWDC 2025 Session 227 Finish tasks in the background — This contains an excellent summary of the expected use cases for each of the background task types. iOS Background Execution Limits forums post UIApplication Background Task Notes forums post Testing and Debugging Code Running in the Background forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Sadly the video is currently not available from Apple. I’ve left the link in place just in case it comes back.

We are developing a watchOS application that records long audio sessions and uploads them to our backend in chunks (~5 MB each) using pre-signed URLs and URLSession background upload. Current behavior: While audio recording is active, uploads continue successfully even when the app is in the background. Once the recording stops, if multiple chunks (e.g., 10+) are still pending, the remaining uploads do not proceed in the background and appear to be suspended. We attempted to use WKExtendedRuntimeSession (mindfulness type) to allow sufficient time to enqueue background upload tasks, but the session is invalidated when the app goes to the background (e.g., wrist down or app inactive), which prevents reliable scheduling of uploads. Additionally, we added the entitlement: com.apple.developer.extended-runtime-session (mindfulness) in the Watch app entitlements file, but Xcode automatic signing fails with: “Provisioning profile does not include the com.apple.developer.extended-runtime-session entitlement.” It appears that the provisioning profile is not being updated to include this entitlement. Our questions: Is WKExtendedRuntimeSession (mindfulness) expected to support scheduling background URLSession uploads after the app goes to background? How should we reliably complete pending background uploads on watchOS after a long recording session ends? Is there any additional entitlement or recommended approach for this use case? Why is the extended runtime entitlement not being applied to the provisioning profile despite being added in the entitlements file? We are aiming to follow Apple-recommended practices for long-running tasks and background uploads on watchOS. Any guidance would be greatly appreciated.

I'm implementing a PHBackgroundResourceUploadExtension to back up photos and videos from the user's library to our cloud storage service. Our existing upload infrastructure uses chunked uploads for large files (splitting videos into smaller byte ranges and uploading each chunk separately). This approach: Allows resumable uploads if interrupted Stays within server-side request size limits Provides granular progress tracking Looking at the PHAssetResourceUploadJobChangeRequest.createJob(destination:resource:) API, I don't see a way to specify byte ranges or create multiple jobs for chunks of the same resource. Questions: Does the system handle large files (1GB+) automatically under the hood, or is there a recommended maximum file size for a single upload job? Is there a supported pattern for chunked/resumable uploads, or should the destination URL endpoint handle the entire file in one request? If our server requires chunked uploads (e.g., BITS protocol with CreateSession → Fragment → CloseSession), is this extension the right mechanism, or should we use a different approach for large videos? Any guidance on best practices for large asset uploads would be greatly appreciated. Environment: iOS 26, Xcode 18

I am developing an app used by public safety agencies. Part of the app is used to determine live agency staffing using geofences. For example, a geofence exists around a station, and when a user enters or exits that geofence, the app updates the staffing count at that station in real time. The issue I am having is reliably detecting when a user enters or exits the geofence while the app is killed (meaning the user force quit the app from the app launcher). I understand that iOS can relaunch an app in the background if the system terminated the process using Region Monitoring, but I haven't gotten a clear answer about whether or how this is possible if the user kills (force quits) the app. Thank you in advance for your assistance.

The expirationHandler on BGProcessingTask is a () -> Void closure. It provides no information about why it was called. In my testing, all of the following trigger the same handler: Time expiration Resource pressure (CPU, memory, battery) Not reporting progress User tapping "Stop" on the Live Activity There is no way for the app to tell these apart. Questions: Q1. Is there an official, complete list of all conditions that trigger expirationHandler? The documentation only mentions "time expires." Q2. What is the specific time limit before timeout? If it varies by device state, what are the conditions? Q3. A way to distinguish the reason is needed. "User stop" and "system expiration" require completely different handling. Currently this is impossible. Environment: iOS 26, physical device

I'm developing a PHBackgroundResourceUploadExtension and finding it difficult to debug because the system controls when the extension launches. Current experience: The extension starts at unpredictable times (anywhere from 1 minute to several hours after photos are added) By the time I attach the debugger, the upload may have already completed or failed Breakpoints in init() or early lifecycle methods are often missed Questions: Is there a way to force-launch the extension during development (similar to how we can manually trigger Background App Refresh in Xcode)? Are there any launch arguments or environment variables that put the extension in a debug/eager mode? I tried taking photos/videos, but this doesn't trigged app extension in all cases. Any tips for improving the debug cycle would be greatly appreciated. Environment: iOS 26, Xcode 18

I'm implementing PHBackgroundResourceUploadExtension to back up photos and videos to our cloud storage service. During testing, I observed that iCloud-optimized photos (where the full-resolution original is stored in iCloud, not on device) do not upload. The upload job appears to silently skip these assets. Questions: Is this behavior intentional/documented? I couldn't find explicit mention of this limitation. If the device only has the optimized/thumbnail version locally, does the system: - Automatically download the full-resolution asset from iCloud before uploading? - Skip the asset entirely? - Return an error via PHAssetResourceUploadJobChangeRequest? For a complete backup solution, should we: - Pre-fetch full-resolution assets using PHAssetResourceManager.requestData(for:options:) before creating upload jobs? - Use a hybrid approach (this extension for local assets + separate logic for iCloud-only assets)? Environment: iOS 26, Xcode 18

We are using BGContinuedProcessingTask on iOS 26 for long-running background video compression and upload. This work usually takes about 30 minutes to 1 hour. In testing on physical devices, expirationHandler is invoked irregularly. In some cases, it seems like it is caused by total task duration, and in other cases, it seems related to system resource conditions such as CPU, memory, or battery. However, even after many experiments, we have not been able to find a clear or consistent pattern. The important problem for us is that we cannot tell why expirationHandler was called. From the app’s perspective, we need to handle the following cases differently: the user taps Stop in the Live Activity the system expires the task due to time expiration the task is terminated due to system resource pressure (CPU, memory, battery, etc.) other system-driven termination cases However, at the moment, it is difficult or practically impossible to distinguish these cases reliably. My questions are: In the context of BGContinuedProcessingTask, is it correct to think that expirationHandler may be triggered by reasons such as time expiration, system resource pressure, and user stop? If so, is there any official or supported way for the app to distinguish between these reasons? For long-running work such as video compression and upload, is it expected behavior that expirationHandler is invoked irregularly? If BGContinuedProcessingTask is not a stable approach for 30-minute to 1-hour background work, is there any other recommended or more reliable way to perform this kind of long-running background processing on iOS without unexpected interruption? Environment: iOS 26, physical device

We are using BGContinuedProcessingTask on iOS 26 for long-running background video compression and upload. This work usually takes about 30 minutes to 1 hour. In testing on physical devices, expirationHandler is invoked irregularly. In some cases, it seems like it is caused by total task duration, and in other cases, it seems related to system resource conditions such as CPU, memory, or battery. However, even after many experiments, we have not been able to find a clear or consistent pattern. The important problem for us is that we cannot tell why expirationHandler was called. From the app’s perspective, we need to handle the following cases differently: • the user taps Stop in the Live Activity • the system expires the task due to time expiration • the task is terminated due to system resource pressure (CPU, memory, battery, etc.) • other system-driven termination cases However, at the moment, it is difficult or practically impossible to distinguish these cases reliably. My questions are: 1. In the context of BGContinuedProcessingTask, is it correct to think that expirationHandler may be triggered by reasons such as time expiration, system resource pressure, and user stop? 2. If so, is there any official or supported way for the app to distinguish between these reasons? 3. For long-running work such as video compression and upload, is it expected behavior that expirationHandler is invoked irregularly? 4. If BGContinuedProcessingTask is not a stable approach for 30-minute to 1-hour background work, is there any other recommended or more reliable way to perform this kind of long-running background processing on iOS without unexpected interruption? Environment: iOS 26, physical device

The expirationHandler on BGProcessingTask is a () -> Void closure. It provides no information about why it was called. In my testing, all of the following trigger the same handler: Time expiration Resource pressure (CPU, memory, battery) Not reporting progress User tapping "Stop" on the Live Activity There is no way for the app to tell these apart. Questions: Q1. Is there an official, complete list of all conditions that trigger expirationHandler? The documentation only mentions "time expires." Q2. What is the specific time limit before timeout? If it varies by device state, what are the conditions? Q3. A way to distinguish the reason is needed. "User stop" and "system expiration" require completely different handling. Currently this is impossible. Environment: iOS 26, physical device

Hi, I am trying to implement a PHBackgroundResourceUploadExtension to upload backup media files to an external cloud service based on these docs: https://developer.apple.com/documentation/PhotoKit/uploading-asset-resources-in-the-background#Acknowledge-completed-jobs Creating jobs and actual uploading is working as expected, but the problem I have is in the acknowledgeCompletedJobs() function. When trying to access a job's resource, the resource is nil and thus has empty assetLocalIdentifier and originalFilename. Did anybody successfully implement this extension or knows, why this would happen? Because the resource of an acknowledgable job is empty, I can not match it back to my processed assets.

Hi, I am trying to implement a PHBackgroundResourceUploadExtension to upload backup media files to an external cloud service based on these docs: https://developer.apple.com/documentation/PhotoKit/uploading-asset-resources-in-the-background#Acknowledge-completed-jobs Creating jobs and actual uploading is working as expected, but the problem I have is in the acknowledgeCompletedJobs() function. When in this function, I am trying to access a job's resource. The resource is nil and thus has empty assetLocalIdentifier and originalFilename. Did anybody successfully implement this extension or knows, why this would happen? Because the resource of an acknowledgable job is empty, I can not match it back to my processed assets.

We are developing a video processing app that applies CIFilter chains to video frames. To not force the user to keep the app foregrounded, we were happy to see the introduction of BGContinuedProcessingTask to continue processing when backgrounded. With iOS 26, I was excited to see the com.apple.developer.background-tasks.continued-processing.gpu entitlement, which should allow GPU access in the background. Even the article in the documentation provides "exporting video in a film-editing app" or "applying visual filters (HDR, etc) or compressing images for social media posts" as use cases. However, when I check BGTaskScheduler.shared.supportedResources.contains(.gpu) at runtime, it returns false on every iPhone I've tested (including iPhone 15 Pro and iPhone 16 Pro). From forum responses I've seen, it sounds like background GPU access is currently limited to iPad only. If that's the case, I have a few questions: Is this an intentional, permanent limitation — or is iPhone support planned for a future iOS release? What is the recommended approach for GPU-dependent background work on iPhone? My custom CIKernels are written in Metal (as Apple recommends since CIKL is deprecated), but Metal CIKernels cannot fall back to CPU rendering. This creates a situation where Apple's own deprecation guidance (migrate to Metal) conflicts with background processing realities (no GPU on iPhone). Should developers maintain deprecated CIKL kernel versions alongside Metal kernels purely as a CPU fallback for background execution? That feels like it defeats the purpose of the migration. It seems like a gap in the platform: the API exists, the entitlement exists, but the hardware support isn't there for the most common device category. Any clarity on Apple's direction here would be very helpful.

Hello, We are facing an issue with performing a DTLS handshake when our iOS application is in the background. Our app (Vocera Collaboration Suite – VCS) uses secure DTLS-encrypted communication for incoming VoIP calls. Problem Summary: When the app is in the background and a VoIP PushKit notification arrives, we attempt to establish a DTLS handshake over our existing socket. However, the handshake consistently fails unless the app is already in the foreground. Once the app is foregrounded, the same DTLS handshake logic succeeds immediately. Key Questions: Is performing a DTLS handshake while the app is in the background technically supported by iOS? Or is this an OS-level limitation by design? If not supported, what is the Apple-recommended alternative to establish secure DTLS communication for VoIP flows without bringing the app to the foreground? Any guidance or clarification from Apple engineers or anyone who has solved a similar problem would be greatly appreciated. Thank you.

Hello, I am using CLLocationManager to monitor multiple CLBeaconRegion instances (up to 20). When the app is terminated by the system (not force-quit) and a region enter event occurs, the app is relaunched in the background. I have two questions: What is the expected execution time window after relaunch before the app is suspended again? Is it supported to start short CoreBluetooth operations (e.g., scanning or connecting briefly) within this window? I understand that force-quitting the app disables background relaunch, so this question applies only to system-terminated apps.

Hi, I've now identified a few areas when BGContinuedProcessingTask gets expired by the system no progress for ~30 seconds high CPU usage high temperature Some of these I can preempt and expire preemptively and handle the notification, others I cannot and just need to let the failure bubble up. When the failure does bubble up, I'd like to update the title and subtitle. I'm able to update the title, but the subtitle is fixed at "Task Failed" Is there any workaround? Or shall I file a bug here?

Hi Everyone 🙌 Who knows, additional content that downloads in install time are summarized to total app size in App Store page ? If yes, additional size going to WiFi/Cell download recommendations ? And what the limit ? Will be appreciate of all information, maybe someone using Background Asset extension :pray:

I am implementing BLE scanning and connection using CoreBluetooth in a Flutter application with native iOS Swift code. BLE scanning and connection work correctly in the foreground and for a short time after the app is sent to the background. However, after some time in the background, BLE scanning stops and the device is no longer discovered. The app appears to be suspended by iOS. Key Observation: When location services are actively in use (navigation arrow visible in the iOS status bar), BLE scanning and reconnection work reliably in the background. When location services are not actively running, BLE scanning stops in the background even though the app has “Always Allow” location permission. Expected Result BLE scanning and connection should continue to function in the background using the Bluetooth LE background mode, without relying on active location updates. Actual Result BLE scanning starts successfully App enters background After some time, scanning stops Device is no longer discovered BLE works again only if location services are actively running BLE Connection Behavior One-time scan connects successfully to a BLE medical device App is sent to background Existing connection does not disconnect However, new scans or reconnections fail once the app is suspended Relevant Native iOS Code (AppDelegate) import Flutter import UIKit import CoreBluetooth @main @objc class AppDelegate: FlutterAppDelegate { private var backgroundTaskID: UIBackgroundTaskIdentifier = .invalid override func application( _ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? ) -> Bool { GeneratedPluginRegistrant.register(with: self) if let identifiers = launchOptions?[UIApplication.LaunchOptionsKey.bluetoothCentrals] as? [String] { print("App relaunched for BLE state restoration: \(identifiers)") } NotificationCenter.default.addObserver( self, selector: #selector(appDidEnterBackground), name: UIApplication.didEnterBackgroundNotification, object: nil ) return super.application(application, didFinishLaunchingWithOptions: launchOptions) } @objc private func appDidEnterBackground() { backgroundTaskID = UIApplication.shared.beginBackgroundTask { self.endBackgroundTask() } } private func endBackgroundTask() { if backgroundTaskID != .invalid { UIApplication.shared.endBackgroundTask(backgroundTaskID) backgroundTaskID = .invalid } } } Questions for DTS: Is it expected behavior that CoreBluetooth background scanning effectively stops once the app is suspended, even when the Bluetooth LE background mode is enabled? Why does BLE background scanning appear to work reliably only when location services are actively running? Is iOS internally associating BLE background execution with active location updates? For continuous BLE reconnection (medical device use case), is the recommended approach to rely solely on CoreBluetooth state restoration instead of continuous background scanning? Is it considered best practice to avoid long-running BLE scans in the background and instead wait for system-delivered BLE events? Additional Notes Issue is reproducible on real devices Not using private APIs or unsupported background execution methods Objective is to follow Apple-recommended, App Store–compliant behavior

Hi, I have been recently debugging the BGContinuedProcessingTask API and encountered some of the following issues. I hope you can provide some answers: First, let me explain my understanding of this API. I believe its purpose is to allow an app to trigger tasks that can be represented with progress indicators and require a certain amount of time to complete. After entering the background, these tasks can continue to be completed through the BGContinuedProcessingTask, preventing the system from terminating them before they are finished. In the launchHandler of the registration process, we only need to do a few things: Determine whether the actual business processing is still ongoing. Update the progress, title, and subtitle. Handle the expirationHandler. Set the task as completed. Here are some issues I encountered during my debugging process: After I called register and submit, the BGContinuedProcessingTask could not be triggered. The return values from my API calls were all normal. I tried different device models, and some could trigger the task normally, such as the 15 Pro Max and 12 Pro Max. However, there were also some models, such as the 17 Pro, 15 Pro, and 15, that could not trigger the task properly. Moreover, there was no additional error information to help locate the issue. The background task failed unexpectedly, but my app was still running normally. As I mentioned above, my launchHandler only retrieves the actual business status and updates it. If a background task fails unexpectedly while the app is still running normally, it can mislead users and degrade the user experience of the app. Others have also mentioned the issue of inconsistent behavior on devices that do not support Dynamic Island. On devices that support Dynamic Island, when a task is triggered in the foreground, the app does not immediately display a pop-up notification within the app. However, on devices that do not support Dynamic Island, the app directly displays a pop-up notification within the app, and this notification does not disappear when switching between different screens within the same app. The user needs to actively swipe up to dismiss it. I think this experience is too intrusive for users. I would like to know whether this will be maintained in the future or if there is a plan to fix it. On devices that do not support Dynamic Island, using the beta version 26.1 of the system, if the system is in dark mode but the app triggers a business interface in white, the pop-up notification will have the same color as the current page, making it difficult to read the content inside the pop-up. Users can actively stop background tasks by using the stop button, or the system can also stop tasks automatically when resources are insufficient or when a task is abnormal. However, according to the current API, all these actions are triggered through the expirationHandler. Currently, there is no way to distinguish whether the task was stopped by the user, by the system due to resource insufficiency, or due to an abnormal task. I would like to know whether there will be more information provided in the future to help distinguish these different scenarios. I believe that the user experience issues mentioned in points 2 and 3 are the most important. Please help to answer the questions and concerns above. Thank you!

Desired Behavior I want the app to be able to handle multiple Push-to-Start notifications even when it is completely terminated. Each Live Activity should: Be successfully displayed upon receiving a Push-to-Start notification. Trigger background tasks to send its update token to the server, regardless of the time interval between notifications. Problem I am facing an issue with iOS Live Activities when using Push-to-Start notifications to trigger Live Activities in an app that has been completely terminated. Here’s the detailed scenario: When the app is completely terminated and I send the first Push-to-Start notification: The Live Activity is successfully displayed. didFinishLaunchingWithOptions` is triggered, and background tasks execute correctly, including sending the update token to the server. When I send consecutive Push-to-Start notifications in quick succession (e.g., within a few seconds or minutes): Both notifications successfully display their respective Live Activities. Background tasks are executed correctly for both notifications. However, when there is a longer interval (e.g., 10 minutes) between two Push-to-Start notifications: The first notification works perfectly—it displays the Live Activity, triggers didFinishLaunchingWithOptions, and executes background tasks. The second notification successfully displays the Live Activity but fails to execute any background tasks, such as sending the update token to the server. My HypothesisI suspect that iOS might impose a restriction where background runtime for Push-to-Start notifications can only be granted once within a certain time frame after the app has been terminated. Any insights into why this issue might be occurring or how to ensure consistent background task execution for multiple Push-to-Start notifications would be greatly appreciated!