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 iOS Background Execution Limits forums post UIApplication Background Task Notes 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.

I created an app. One if its functionalities is receive Remote Notification in the background, while app is monitoring Significant Location Changes (SLC). This functionality worked fine. I was receiving these notifications correctly. Sometimes instantly, sometime with small or large delay. And then I send the app for review. It was rejected with 3 remarks: The app or metadata includes information about third-party platforms that may not be relevant for App Store users, who are focused on experiences offered by the app itself (I wrote that app communication works both for iOS and Android.) The app declares support for audio in the UIBackgroundModes key in your Info.plist but we are unable to locate any features that require persistent audio. EULA (End User License Agreement) is missing for in-app purchases. After the rejection the app is no longer receiving these notifications. They are there, since the app receives them, when I open app, or significant location change is detected. It also works, when I run the app directly from Xcode (in debug mode), not from TestFlight nor in Sandbox. It seem to me like Apple somehow spoiled my background capabilities on purpose or accidentally. Is it possible? What can I do with it? Is it the case that I should just fix the review remarks and send the app back to review, and once the app passes it, it will work again? Or should I not count on it? Any suggestions? I asked Apple using: https://developer.apple.com/contact/topic/#!/topic/select but so far no response.

I'm developing a safety-critical monitoring app that needs to fetch data from government APIs every 30 minutes and trigger emergency audio alerts for threshold violations. The app must work reliably in background since users depend on it for safety alerts even while sleeping. Main Challenge: iOS background limitations seem to prevent consistent 30-minute intervals. Standard BGTaskScheduler and timers get suspended after a few minutes in background. Question: What's the most reliable approach to ensure consistent 30-minute background monitoring for a safety-critical app where missed alerts could have serious consequences? Are there special entitlements or frameworks for emergency/safety applications? The app needs to function like an alarm clock - working reliably even when backgrounded with emergency audio override capabilities.

my app need tracking location all the time both foreground and background. Please suggest how to prevent the app from being terminated. or detect when app is terminated.

I would love to use Background GPU Access to do some video processing in the background. However the documentation of BGContinuedProcessingTaskRequest.Resources.gpu clearly states: Not all devices support background GPU use. For more information, see Performing long-running tasks on iOS and iPadOS. Is there a list available of currently released devices that do (or don't) support GPU background usage? That would help to understand what part of our user base can use this feature. (And what hardware we need to test this on as developers.) For example it seems that it isn't supported on an iPad Pro M1 with the current iOS 26 beta. The simulators also seem to not support the background GPU resource. So would be great to understand what hardware is capable of using this feature!

Basically the title. I am trying to implement a local notification to trigger, regardless of internet connection, around 3-5pm if a certain array in the app is not empty to get the user to sync unsaved work with the cloud. I wanted to used the BGAppRefreshTask as I saw it was lightweight and quick for just posting a banner notification but after inspecting it in the console, it looks like it needs internet connection to trigger. Is this the case or am I doing something wrong? Should I be using the BGProcessingTask instead?

Hello, I have a question regarding the behavior of BGProcessingTaskRequest when the app is force-quit by the user via the App Switcher. Based on common understanding and various discussions — including the following Apple Developer Forum threads: Waking up an iOS app after app is … | Apple Developer Forums Will BGAppRefreshTaskRequest will … | Apple Developer Forums Background fetch after app is forc… | Apple Developer Forums …it is widely understood that iOS prevents background execution (such as background fetch, push notifications, or BGTaskScheduler) after a user force-quits an app via the App Switcher. However, in my app, I have observed that a scheduled BGProcessingTaskRequest still executes even after the app has been explicitly terminated via App Switcher. The task is scheduled using submit(_:error:), and it is clearly running some time after the app has been closed by the user. That said, the task does run, but it appears to operate under tighter constraints — for example, it may be allowed to run for a shorter duration, and network requests appear to be more restricted compared to when the app is not force-quit. My questions are: Are there any documented or undocumented exceptions that allow this kind of behavior after force-quit? Could this be a bug or a behavior change in recent iOS versions? (I am observing this on iOS 18.3, 18.4, and 18.5) Any insights, experiences, or clarifications from Apple engineers or fellow developers would be greatly appreciated. Thank you!

Hello everyone, We are building an iOS app using React Native that connects to a custom Bluetooth Low Energy (BLE) accessory. The accessory continuously sends small chunks of audio data to the app through BLE (basically every time the user speaks), which are then streamed in real time to our server via WebSocket for transcription and processing. We need to know if the following behavior is allowed by iOS runtime and App Store review policies: Can the app open a WebSocket connection in the background (not permanently, just briefly, several times a day) triggered by BLE activity from a registered accessory? Is there a limit to this? Clarifications: The app is not expected to remain permanently awake. Only during accessory-triggered events. WebSocket is required due to the real-time nature of streaming STT and delivering quick responses (via notifications). If allowed, are there any specific Info.plist declarations or entitlements we must include? Thanks in advance! Fran

Summary: I'm developing an iOS audio app in Flutter that requires background audio playback for long-form content. Despite having a paid Apple Developer Program account, the "Background Modes" capability does not appear as an option when creating or editing App IDs in the Developer Portal, preventing me from enabling the required com.apple.developer.background-modes entitlement. Technical Details: In the app that I am developing, users expect uninterrupted playback when app is backgrounded or device is locked similar to Audible, Spotify, or other audio apps that continue playing in background The Problem: When building for device testing or App Store submission, Xcode shows: Provisioning profile "iOS Team Provisioning Profile: com.xxxxx-vxxx" doesn't include the com.apple.developer.background-modes entitlement. However, the "Background Modes" capability is completely missing from the Developer Portal when creating or editing any App ID. I cannot enable it because the option simply doesn't exist in the capabilities list. What I've Tried: Multiple browsers/devices: Safari, Chrome, Firefox, incognito mode, different computers Account verification: Confirmed paid Individual Developer Program membership is active New App IDs: Created multiple new App IDs - capability never appears for any of them Documentation review: Followed all Apple documentation for configuring background execution modes Different regions: Tried changing portal language to English (US) Cache clearing: Logged out, cleared cookies, tried different sessions Apple Support Response: Contacted Developer Support (Case #102633509713). Received generic documentation links and was directed to Developer Forums rather than technical escalation. Has anyone else experienced the "Background Modes" capability missing from their Developer Portal? Has anyone successfully used the App Store Connect API to add background-modes when the GUI doesn't show it? What's the proper escalation path when Developer Support provides generic responses instead of technical assistance? Things I have attempted to solve this: audio_service package: Implemented as potential workaround, but still requires the system-level entitlement Manual provisioning profiles: Cannot create profiles with required entitlement if capability isn't enabled on App ID Other perhaps important facts about the environment where I am building the app: macOS Sonoma Xcode 15.x Flutter 3.5.4+ Apple Developer Program (Individual, paid)

Hi Team! Has anyone found a reliable way to detect CarPlay connection without the app needing to be in the foreground? I’m exploring a concept where, for example, as someone nears home while driving, a prompt appears on the CarPlay screen asking “Would you like to turn on the lights / open garage?” triggered by proximity and CarPlay connection. Would be cool to have it work automatically, but knowing you're in the car is kind of important. From what I can see, apps can’t reliably detect CarPlay connection unless they’re actively open on the CarPlay screen. Most background detection methods (like external screen connect notifications) appear deprecated. That is, unless you're specifically approved as a "messaging" or "navigation" app that appear to get special privilages to send alerts from the background. If I send an alert (or poll Carplay periodically) it just gives silent/dead response. Is there any approach, framework, entitlement, or UI pattern that could allow a passive trigger or background detection while driving with CarPlay connected? I can't see any way to bring an app to the foreground either. Not looking to abuse any rules... just want to understand if anyone’s found a clean, approved workaround. Thanks in advance!

I'm looking to maximise my Watch app's widget to be as up to date as possible. If we imagined the app was a simple step counter, and we wanted to display the users count as up to date as possible. We can conclude: We don't care about widget timelines beyond the current entry as we can't predict the future! We need to refresh the count as often as possible The refresh should be very quick with a straightforward HealthKit query, no networking or heavy work needed. We will assume the user has the complication/widget on their active Watch face. With the standard WidgetKit APIs we can expire the timeline after 15 minutes and in my experimentation a Watch app can usually update its widget timeline at that frequency if it's on the Watch face. I'm experimenting with two methods to try and improve refreshes further A user's step count might not have recently changed when the timeline update is called. I was therefore looking into the HealthKit enableBackgroundDelivery API (which requires the HealthKit Background Delivery entitlement to be enabled) to get updates limited to once an hour from a HKObserverQuery, I can then call the WidgetCenter.shared.reloadAllTimelines() from there. WatchOS also support the BGAppRefreshTaskRequest(identifier:"") and .backgroundTask(.appRefresh) APIs. I can request updates once every 15 minutes here too and then call the WidgetCenter.shared.reloadAllTimelines(). With option 1, this update opportunity is great as it will specifically update when there's new steps so even once an hour this would be helpful (A real shame to be limited to once an hour even if this used up WidgetKit standard reload budgets: FB13879817, FB11677132, FB10016177). But I can't determine if this update takes away one of the standard timeline expiration updates that already run 4 times an hour? Could I observe additional Health types to get additional updates? Do I need the Background Modes Capability as well as the HealthKit Background Delivery for this in Xcode or just the HealthKit one? With option 2, I can't find a suitable option in the (short) list of supported background modes in Xcode. Does not selecting any mean my app will get 0 refreshes from this route and so should not be implemented in my use case?

Hey everyone, I have an issue I'm running into – maybe someone has the expertise to help! I've created an app that adds Intents to the Shortcuts app, to interact with S3-compatible object storage. Everything works fine, until you decide to upload/download a large file, that your internet connection cannot handle in the ~30-second intent timeout. I've explored uploading files with a background task which seems to work somehow, but the bigger issue would be downloading larger files, as other parts of the subsequent shortcut may rely on it. To the question: Is there some way of increasing the timeout for a shortcuts intent, or a way to "trick" shortcuts into letting my custom intents download/upload files without timing out? Thanks so much!

Hi Apple Dev Team & Community, We’ve encountered an issue with background location updates when using an XCFramework we’ve built from our main app. Context: We have a standalone app called TravelSafely that reliably performs background location updates and alerts, even during sleep mode. From this app, we extracted some core functionality into an XCFramework, including location management, and provided it as an SDK to a client. We created a demo app to test this SDK in isolation. Problem: In the demo app, we notice that location updates work fine in the foreground. However, in the background or sleep mode, location updates sometimes stop completely. When we bring the app to the foreground again, location resumes. This does not happen in the original standalone app. What We’ve Already Checked: UIBackgroundModes includes location Info.plist has the required permissions Location is started correctly using startUpdatingLocation We maintain strong references and use background tasks as needed Question: Why would an app using a binary XCFramework (with location logic) behave differently from the original app in terms of background execution? Is there any known issue or recommendation when working with SDKs/XCFrameworks that need to manage background tasks and location updates? Any insights or recommendations to maintain proper background behavior would be highly appreciated. Thank you!

I would like to inquire about the feasibility of developing an iOS application with the following requirements: The app must support real-time audio communication based on UDP. It needs to maintain a TCP signaling connection, even when the device is locked. The app will run only on selected devices within a controlled (closed) environment, such as company-managed iPads or iPhones. Could you please clarify the following: Is it technically possible to maintain an active TCP connection when the device is locked? What are the current iOS restrictions or limitations for background execution, particularly related to networking and audio? Are there any recommended APIs or frameworks (such as VoIP, PushKit, or Background Modes) suitable for this type of application?

Hello forum, I want to keep my app running in the background after user swaps up, for the purpose of workout tracking. start up the task and continuously receipt GPS updates process the location data show the data on a live activity Two examples Strava paddlelogger Question: Does this mean, these two apps would just pause when the .backgroundTimeRemaining becomes 0? How does a workout app "work" in background mode, do I need to handle budget running out?

Hi, I have a couple questions about background app refresh. First, is the function RefreshAppContentsOperation() where to implement code that needs to be run in the background? Second, despite importing BackgroundTasks, I am getting the error "cannot find operationQueue in scope". What can I do to resolve that? Thank you. func scheduleAppRefresh() { let request = BGAppRefreshTaskRequest(identifier: "peaceofmindmentalhealth.RoutineRefresh") // Fetch no earlier than 15 minutes from now. request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60) do { try BGTaskScheduler.shared.submit(request) } catch { print("Could not schedule app refresh: \(error)") } } func handleAppRefresh(task: BGAppRefreshTask) { // Schedule a new refresh task. scheduleAppRefresh() // Create an operation that performs the main part of the background task. let operation = RefreshAppContentsOperation() // Provide the background task with an expiration handler that cancels the operation. task.expirationHandler = { operation.cancel() } // Inform the system that the background task is complete // when the operation completes. operation.completionBlock = { task.setTaskCompleted(success: !operation.isCancelled) } // Start the operation. operationQueue.addOperation(operation) } func RefreshAppContentsOperation() -> Operation { }

I am building banking application which has audio/video and text chat. It is intended for contacting bank support. When user device has auto lock on after 30 seconds, session is ended, and user needs to initiate it again. Will Apple allow this kind of application to have Audio, Airplay, and Picture in Picture or Voice over IP for background modes for this kind of application or it is against Apple rules (per 2.5.4 - https://developer.apple.com/app-store/review/guidelines/)? Chat framework uses Web sockets and SIP.

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.

I am work an app development on an app which request an audio function in background as an alert sound. during debug testing , the function work fine, but once I testing standalone without debugging , The function not work , it will play out the sound when I back to app. does any way to trace the issues ?

Hi all, I’m encountering a consistent issue with SwiftData on watchOS when using CloudKit sync. After enabling: let config = ModelConfiguration(schema: schema, cloudKitDatabase: .automatic) …the app terminates ~30–60 seconds into a WKExtendedRuntimeSession. This happens specifically when: Always-On Display is OFF The iPhone is disconnected or in Airplane Mode The app is running in a WKExtendedRuntimeSession (e.g., used for meditation tracking) The Xcode logs show a warning: Background Task ("CoreData: CloudKit Setup"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. It appears CloudKit sync setup is being triggered automatically and flagged by the system as an unmanaged long-running task, leading to termination. Workaround: Switching to: let config = ModelConfiguration(schema: schema, cloudKitDatabase: .none) …prevents the issue entirely — no background task warning, no crash. Feedback ID submitted: FB17685611 Just wanted to check if others have seen this behavior or found alternative solutions. It seems like something Apple may need to address in SwiftData’s CloudKit handling on watchOS.

Hi all, I'm working on a non-interactive macOS application (a service or daemon), and I'm trying to understand the best practices around logging and error reporting, particularly in failure scenarios. If a daemon or service fails in macOS, where is it expected to log errors, and how can users or developers discover what went wrong? Specifically, I have a few questions: What is the recommended location or system for logging errors from a non-interactive macOS application? Should we use os_log, standard error output, or write directly to files somewhere? How can a user or developer access these logs to diagnose issues—should logs be visible via the Console app? Is there a standard approach to making failure information easily accessible for debugging and support, especially for daemons running under launchd? Any guidance or best practices would be appreciated.