Our app scans Bluetooth in the background. However, the iPhone 17 device does not scan in the background. ios 26 Is there anything I need to do?

Our app scans Bluetooth in the background. However, the iPhone 17 device does not scan in the background. ios 26 Is there anything I need to do? The setting values are as follows. device connection interval min : 60 connection interval max : 75 slave latency : 0 supervision timeout : 4000 advertising interval : 20

Our app scans Bluetooth in the background. However, the iPhone 17 device does not scan in the background. ios 26 Is there anything I need to do? device1 connection interval min : 60 connection interval max : 75 slave latency : 0 supervision timeout : 4000 advertising interval : 20

After iOS 26 was released to the public and our build began rollout, we started seeing a strange crash affect users immediately after the app goes to the background. According to the symbolication provided in Xcode, this appears to be the result of a UICollectionView potentially related to the keyboard and a UIAlertController. I’m not sure how an error somewhere else can cause a crash in our app which does not use UIKit in the background. The feedback associated with this post is: FB20305833. I will attach a sample of the crash report in my next comment.

The following code worked as expected on iOS 26 RC, but it no longer works on the official release of iOS 26. Is there something I need to change in order to make it work on the official version? Registration BGTaskScheduler.shared.register( forTaskWithIdentifier: taskIdentifier, using: nil ) { task in ////////////////////////////////////////////////////////////////////// // This closure is not called on the official release of iOS 26 ////////////////////////////////////////////////////////////////////// let task = task as! BGContinuedProcessingTask var shouldContinue = true task.expirationHandler = { shouldContinue = false } task.progress.totalUnitCount = 100 task.progress.completedUnitCount = 0 while shouldContinue { sleep(1) task.progress.completedUnitCount += 1 task.updateTitle("\(task.progress.completedUnitCount) / \(task.progress.totalUnitCount)", subtitle: "any subtitle") if task.progress.completedUnitCount == task.progress.totalUnitCount { break } } let completed = task.progress.completedUnitCount >= task.progress.totalUnitCount if completed { task.updateTitle("Completed", subtitle: "") } task.setTaskCompleted(success: completed) } Request let request = BGContinuedProcessingTaskRequest( identifier: taskIdentifier, title: "any title", subtitle: "any subtitle", ) request.strategy = .queue try BGTaskScheduler.shared.submit(request) Sample project code: https://github.com/HikaruSato/ExampleBackgroundProcess

In iOS Background Execution limits, I see this: When the user ‘force quits’ an app by swiping up in the multitasking UI, iOS interprets that to mean that the user doesn’t want the app running at all. iOS also sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. However, I see that when I close an app on iPadOS 26 with the red X, the app doesn't appear in the multitasking UI. So are they treated as force closes and prevented from running background tasks?

Our VoIP app receives PushKit notifications successfully (callservicesd Delivering 1 VoIP payload appears in logs). However, the app is consistently terminated by the system when running in the background or killed state. The crash is caused by iOS expecting a reportNewIncomingCall to CallKit, but the system reports: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push.' *** Assertion failure in -[PKPushRegistry _terminateAppIfThereAreUnhandledVoIPPushes], PKPushRegistry.m:349 Key Observations: VoIP pushes arrive and are delivered to the app. In foreground, some methods work and CallKit UI sometimes appears. In background/killed state, app is always terminated before CallKit UI shows. Logs confirm the system requires CallKit to be reported immediately inside pushRegistry(_:didReceiveIncomingPushWith:for:completion:). Steps to Reproduce: Run the app with VoIP + CallKit integration. Put app in background (or kill it). Send a VoIP push. Observe system logs and crash: callservicesd: Delivering 1 VoIP payload(s) to application UrgiDoctor: Apps receiving VoIP pushes must post an incoming call via CallKit... error: Killing VoIP app because it failed to post an incoming call in time. Expected Behavior: On receiving a VoIP push, CallKit UI (Accept / Decline screen) should always appear. App should not be killed if reportNewIncomingCall is called in time. Actual Behavior: CallKit UI never appears in background/killed state. App is force-terminated by iOS before user can accept/decline the call. Request: Guidance on the correct sequence for calling reportNewIncomingCall and completionHandler() in pushRegistry. Clarification if any changes in iOS 17/18 affect PushKit + CallKit behavior. Best practices for ensuring CallKit UI always appears reliably after a VoIP push. Environment: iOS 18.5 Simulator + Device Xcode 16.4 Using PushKit + CallKit with VoIP entitlement

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.

I’m developing a iOS VPN app, and I need to execute a task in the main app even when it’s in the background or killed state. I know the Network Extension continues running during those times. Is there a way for the extension to immediately notify the app or trigger a task on the app side?

Hello im creating an expo module using this new API, but the problem i found currently testing this functionality is that when the task fails, the notification error doesn't go away and is always showing the failed task notification even if i start a new task and complete that one. I want to implement this module into the production app but i feel like having always the notification error might confuse our users or find it a bit bothersome. Is there a way for the users to remove this notification? Best regards!

I got users feed back, sometimes they seem the launch screen after active from background, and the launch screen show more longer than the cold launch. I check the app's log, when this issue happens, it displays a view controller named 'STKPrewarmingViewController', and disappears after about 5 seconds. And form the normal users, app don't have same behavior. It seems app need prewarming after back from background, why? Devices System version: iOS 18.4, app build with Xcode 16. How to fixed this issues? Thanks!

Testing Environment: iOS: 26.0 Beta 7 Xcode: Beta 6 Description: We are implementing the new BGContinuedProcessingTask API introduced in iOS 26. We have followed the official documentation and WWDC session guidance to configure our project. The Background Modes (processing) and Background GPU Access capabilities have been added in Xcode. The com.apple.developer.background-tasks.continued-processing.gpu entitlement is present and set to in the .entitlements file. The provisioning profile details viewed within Xcode explicitly show that the "Background GPU Access" capability and the corresponding entitlement are included. Despite this correct configuration, when running the app on supported hardware (iPhone 16 Pro), a call to BGTaskScheduler.supportedResources.contains(.gpu) consistently returns false. This prevents us from setting request.requiredResources = .gpu. As a result, when the BGContinuedProcessingTask starts without the GPU resource flag, our internal Metal-based exporter attempts to access the GPU and is terminated by the system, throwing an IOGPUMetalError: Insufficient Permission (to submit GPU work from background). We have performed extensive debugging, including a full reset of the provisioning profile (removing/re-adding capabilities, toggling automatic signing, cleaning build folders, and reinstalling the app), but the issue persists. This strongly suggests a bug in the iOS 26 beta where the runtime is failing to correctly validate a valid entitlement. Additionally, we've observed inconsistent behavior across devices. On an A16-based iPad, the task submits successfully (BGTaskScheduler.submit does not throw an error), but the launch handler is never invoked by the system. On the iPhone 16 Pro, the handler is invoked, but we encounter the supportedResources issue described above. This leads us to ask for clarification on the exact hardware requirements for this feature. We hypothesize that it may be limited to devices that support Apple Intelligence (A17 Pro and newer). Could you please confirm this and provide official documentation on the device support criteria? Steps to Reproduce: Create a new Xcode project. In Signing & Capabilities, add "Background Modes" (with "Background processing" checked) and "Background GPU Access". Add a permitted identifier (e.g., "com.company.test.*") to BGTaskSchedulerPermittedIdentifiers in Info.plist. In application(_:didFinishLaunchingWithOptions:) or a ViewController's viewDidLoad, log the result of BGTaskScheduler.shared.supportedResources.contains(.gpu). Build and run on a physical, supported device (e.g., iPhone 16 Pro). Expected Results: The log should indicate that BGTaskScheduler.shared.supportedResources.contains(.gpu) returns true. Actual Results: The log shows that BGTaskScheduler.shared.supportedResources.contains(.gpu) returns false.

Hello, I'm trying to adopt the new BGContinuedProcessingTask API, but I'm having a little trouble imagining how the API authors intended it be used. I saw the WWDC talk, but it lacked higher-level details about how to integrate this API, and I can't find a sample project. I notice that we can list wildcard background task identifiers in our Info.plist files now, and it appears this is to be used with continued tasks - a user might start one video encoding, then while it is ongoing, enqueue another one from the same app, and these tasks would have identifiers such as "MyApp.VideoEncoding.ABCD" and "MyApp.VideoEncoding.EFGH" to distinguish them. When it comes to implementing this, is the expectation that we: a) Register a single handler for the wildcard pattern, which then figures out how to fulfil each request from the identifier of the passed-in task instance? Or b) Register a unique handler for each instance of the wildcard pattern? Since you can't unregister handlers, any resources captured by the handler would be leaked, so you'd need to make sure you only register immediately before submission - in other words register + submit should always be called as a pair. Of course, I'd like to design my application to use this API as the authors intended it be used, but I'm just not entirely sure what that is. When I try to register a single handler for a wildcard pattern, the system rejects it at runtime (while allowing registrations for each instance of the pattern, indicating that at least my Info.plist is configured correctly). That points towards option B. If it is option B, it's potentially worth calling that out in documentation - or even better, perhaps introduce a new call just for BGContinuedProcessingTask instead of the separate register + submit calls? Thanks for your insight. K Aside: Also, it would be really nice if the handler closure would be async. Currently if you need to await on something, you need to launch an unstructured Task, but that causes issues since BGContinuedProcessingTask is not Sendable, so you can't pass it in to that Task to do things like update the title or mark the BGTask as complete.

Hello, I’m building an iOS application that supports peer-to-peer file transfer. My goal is to use the WebRTC data channel only (no audio or video) to send files between users. I understand from Apple’s documentation that: • Apps are generally suspended in the background, and arbitrary sockets (like WebRTC) do not continue running. • Background file transfer is officially supported via URLSessionConfiguration.background, which the system manages reliably even if the app is suspended or terminated. • VoIP use cases require CallKit + audio/VoIP background modes, and CallKit must be used for legitimate calls (audio/video). What I want to confirm is: Is it supported for a WebRTC peer connection using only the data channel (no audio/video track, no CallKit call) to continue sending data when the app is in the background or locked? I considered using BGProcessingTask and BGAppRefreshTask, but as far as I can tell, those don’t allow maintaining long-lived sockets for active data transfer. Real-world developer discussions suggest that WebRTC connections are dropped when the app is backgrounded on iOS unless there’s at least one active audio track to keep the session alive. Can someone from Apple confirm if my understanding is correct—that data-only WebRTC connections will be killed in background unless they’re part of an active audio/video call with the appropriate entitlements? Thanks in advance!

Testing Environment: iOS Version: 26.0 Beta 7 Xcode Version: 17.0 Beta 6 Device: iPhone 16 Pro Description: We are implementing the new BGContinuedProcessingTask API and are using the wildcard identifier notation as described in the official documentation. Our Info.plist is correctly configured with a permitted identifier pattern, such as com.our-bundle.export.*. We then register a single launch handler for this exact wildcard pattern. We are performing this registration within a UIViewController, which is a supported pattern as BGContinuedProcessingTask is explicitly exempt from the "register before applicationDidFinishLaunching" requirement, according to the BGTaskScheduler.h header file. The register method correctly returns true, indicating the registration was successful. However, when we then try to submit a task with a unique identifier that matches this pattern (e.g., com.our-bundle.export.UUID), the BGTaskScheduler.shared.submit() call throws an NSInternalInconsistencyException and terminates the app. The error reason is: 'No launch handler registered for task with identifier com.our-bundle.export.UUID'. This indicates that the system is not correctly matching the specific, unique identifier from the submit call to the registered wildcard pattern handler. This behavior contradicts the official documentation. Steps to Reproduce: Create a new Xcode project. In Signing & Capabilities, add "Background Modes" (with "Background processing" checked) and "Background GPU Access". Add a permitted identifier (e.g., "com.company.test.*") to BGTaskSchedulerPermittedIdentifiers in Info.plist. In a UIViewController's viewDidLoad, register a handler for the wildcard pattern. Check that the register method returns true. Immediately after, try to submit a BGContinuedProcessingTaskRequest with a unique identifier that matches the pattern. Expected Results: The submit call should succeed without crashing, and the task should be scheduled. Actual Results: The app crashes immediately upon calling submit(). The console shows an uncaught NSInternalInconsistencyException with the reason: 'No launch handler registered for task with identifier com.company.test.UUID'. Workaround: The issue can be bypassed if we register a new handler for each unique identifier immediately before submitting a request with that same unique identifier. This strongly suggests the bug is in the system's wildcard pattern-matching logic.

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 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.

Dear Apple App Store Review Team, We are currently developing an application focused on user data asset management, aimed at helping users better protect and manage their personal data. One of the core features of our application is to allow users to access files stored on their mobile devices from other devices within the same local network. At present, our implementation works as follows: once the application is launched, it starts an HTTP service in the background to support access from other devices within the local network. However, we have encountered a technical challenge in the iOS environment: when the application is moved to the background or the device screen is turned off, the system imposes strict limitations on the runtime of background tasks. Our testing has shown that, typically after about 30 seconds, the background HTTP service is suspended by the system, which prevents other devices from continuing to access the files. As developers, we would like to clarify the following: What specific technical steps are required to enable a continuous background HTTP service under iOS? During development, which aspects (e.g., system permission configurations, App Store review guidelines) need to be addressed to support such functionality? What qualifications or requirements (e.g., entitlement requests, compliance documentation) are necessary for an application to provide unrestricted HTTP service in the background? If such behavior is not officially supported, we kindly request that you provide the relevant official guidelines and documentation so that we can fully understand the applicable policies and requirements. Thank you very much for your time and guidance.

I have been experimenting with the BGContinuedProcessingTask API recently (and published sample code for it https://github.com/infinitepower18/BGContinuedProcessingTaskDemo) I have noticed that if I lock the phone, the code that runs as part of the task stops executing. My sample code simply updates the progress each second until it gets to 100, so it should be completed in 1 minute 40 seconds. However, after locking the phone and checking the lock screen a few seconds later the progress indicator was in the same position as before I locked it. If I leave the phone locked for several minutes and check the lock screen the live activity says "Task failed". I haven't seen anything in the documentation regarding execution of tasks while the phone is locked. So I'm a bit confused if I encountered an iOS bug here?

I'm working with SwiftData and SwiftUI and it's not clear to me if it is good practice to have a @ModelActor directly populate a SwiftUI view. For example when having to combine manual lab results and clinial results from HealthKit. The Clinical lab results are an async operation: @ModelActor actor LabResultsManager { func fetchLabResultsWithHealthKit() async throws -> [LabResultDto] { let manualEntries = try modelContext.fetch(FetchDescriptor<LabResult>()) let clinicalLabs = (try? await HealthKitService.getLabResults()) ?? [] return (manualEntries + clinicalLabs).sorted { $0.date > $1.date }.map { return LabResultDto(from: $0) } } } struct ContentView: View { @State private var labResults: [LabResultDto] = [] var body: some View { List(labResults, id: \.id) { result in VStack(alignment: .leading) { Text(result.testName) Text(result.date, style: .date) } } .task { do { let labManager = LabResultsManager() labResults = try await labManager.fetchLabResultsWithHealthKit() } catch { // Handle error } } } } EDIT: I have a few views that would want to use these labResults so I need an implementation that can be reused. Having to fetch and combine in each view will not be good practice. Can I pass a modelContext to a viewModel?

Hello. I have implemented background delivery for detecting changes in health kit with HKObserverQuery. It works well, I am reading changes. And I am sending this changes to an https endpoint with using an URLSession.shared.dataTask inside the HKObserverQuery callback while my app is terminated. I have several questions about this: Is starting a URLSession.shared.dataTask inside HKObserverQuery callback when app is terminated is correct way to do it? I am calling HKObserverQuery completion handler whatever dataTask returned success or failure but I am wondering what if the network connection is low and this dataTask response could not received in 2-3 seconds. I have read background deliveries should take 1-2 seconds. Should I use an URL session with background configuration for sending those HTTPS requests? If so, should I use download task or upload task (they don't fit my requirements I am sending a simple json)?