I've been reading this question: https://developer.apple.com/forums/thread/701945 and watching the videos on background tasks But can't arrive to a concrete solution. Q1: Are there any tips (or sample app) on how to handle a launch in background in a streamlined way? How to have a shared code that is ran for both 'launch in background' & 'launch in foreground'? Specifically the case I'm talking about is: You set up some observance of some OS callback at a Foo screen of your app. Example app should request and then send push-to-start live activity tokens to server. Or setup location tracking. App is then suspended and then later terminated but is eligible for relaunch App is then launched in background because it has requested a push-to-start live activity token or an update for location tracking. User DOES NOT go back to screen Foo. So at this point app is no longer tracking / listening to updates for token update or location changes. How should I architecture my code for this? I'm trying to see if there's a an approach where I can avoid having multiple places in code where I do the same thing. Currently what I'm doing is as such: Q2: Is it then correct to say that anytime you've launched your app, whether it's in foreground or background then you must immediately match 'all observations done by the previous app launch'? Like store items in UserDefaults and upon launch retrieve them and do: handleGeneralAppLaunchFlow() // ALSO if defaults.contains("didLastLaunchSetupLiveActivtiyTokenObservance") { for await ptsToken in Activity<EmojiRangers> .pushToStartTokenUpdates { ... } } if defaults.contains("didLastLaunchSetupLocationTracking") { locationManager = CLLocationManager() locationManager?.delegate = itsDelegate locationManager?.allowsBackgroundLocationUpdates = true locationManager?.showsBackgroundLocationIndicator = true locationManager?.startUpdatingLocation() } // Other checks for prior observance setup Q3: Actually I think even if app is launched in foreground then because you may not end up at screen Foo again, then you must setup things regardless of app state and just based on prior observations set. Right? Q4: And then later if the user ever made it again to screen Foo, then we just skip the re-do of the observance, or maybe to just keep things simple, we'd just redo without over-engineering things? I tried to mark my questions with Q1- Q4.

Hi all, I've been trying to test the suspension -> resume behaviour of our app, on iPad (iPadOS 18.3.1), however I'm unable to reliably get the application into a suspended state. Things I've read that do not work reliably: Backgrounding the application and waiting ~1 minute Backgrounding the application and opening a bunch of other applications Sometimes it will work consistently, then other times I can be waiting for 30 minutes or more and it still won't suspend. If it matters - I'm launching the app via xcode & it's also a capacitor app with a web sockets connection. Is there any way to reliably suspend an app? Thanks

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!

When using the old withTaskCancellationHandler(operation:onCancel:isolation:) to run background tasks, you were notified that the background task gets cancelled via the handler being called. SwiftUI provides the backgroundTask(_:action:) modifier which looks quite handy. However how can I check if the background task will be cancelled to avoid being terminated by the system? I have tried to check that via Task.isCancelled but this always returns false no matter what. Is this not possible when using the modifier in which case I should file a bug report? Thanks for your help

Hello Apple Developer Community, I am developing a medical app that is classified as Class B according to FDA regulations. The app connects to a medical device using Bluetooth Low Energy (BLE) to collect critical medical data such as ECG readings. To ensure accurate data collection and maintain the quality of the medical readings, the app needs to wake up every five minutes in the background and perform tasks for approximately 30 seconds. I understand that iOS has strict limitations on background execution to preserve battery and system performance. However, due to the medical nature of the app and the need for periodic data collection, I am seeking guidance on the following: If I can provide documentation that the app is associated with an FDA-approved Class B medical device, would Apple allow more lenient background task execution policies? Are there specific APIs, such as BackgroundTasks, CoreBluetooth, or other recommended strategies, that could help me achieve this behavior reliably? Is there a process to apply for an exception or special consideration for medical apps that require periodic background activity? Any insights or recommendations would be greatly appreciated. Thank you!

Hello, I’m experiencing an issue with my iOS app that uses CoreBluetooth in combination with beacon monitoring. My app is designed to wake via beacon region monitoring and then start scanning for a specific BLE peripheral (with specific service UUIDs). When the device screen is bright (i.e., the device is unlocked, or locked but the screen is active/bright), everything works perfectly—the connection is established and maintained without any issues in both: foreground and background. However, when the device is left alone for a while and the lock-screen dims (sleeps), the app continues to run in the background and range the beacon (I can confirm this via realtime console logs), but the connection attempt fails. Here’s what I observe: The central manager’s delegate method didConnect is called, indicating that the peripheral was connected. Almost immediately afterward, didDisconnect is triggered with the error message: "The specified device has disconnected from us.". The interesting part is (I repeatedly see this error in the console, because the app repeatedly tries to connect to peripheral until a success), when I touch the lockscreen (not unlock, but just touch, which makes the screen to light up brighter), the connection is being established without any further issues! I have the necessary background modes enabled in the app’s capabilities (e.g., bluetooth-central, location-always-mode, etc..). My expectation was that, thanks to beacon monitoring, the app would be awakened when needed, and scanning/connection would work reliably in the background regardless of whether the device is active or dimmed. My questions are: Why might the connection fail with this error when the device is locked/dimmed? Is this behavior expected due to iOS power management policies even if the app remains active in the background? Is there a way to ensure a reliable connection in such cases? Any insights, workarounds, or suggestions would be greatly appreciated. Thank you in advance!

I've been having trouble with .backgroundTask(.appRefresh()) causing an intermittent crash when my app is launched. When the crash happens, the app flashes a darkened screen with the home screen device information (time-of-day, battery life, etc) weirdly pivoted landscape and right-justified. This screen shows for a split-second, disappears, and the app does NOT launch. Re-tapping the app icon will often re-launch the app without incident. After much trouble-shooting, I've discovered that commenting out EITHER @Environment(\.scenePhase) private var phase or the .backgroundTask(.appRefresh()) {} code eliminates the crash, so it's somehow caused by having both present at the same time. As you can see in the example below, it's not even necessary to actually use .scenePhase or .backgroundTask to run any other code in order to create the crash. The following minimal reproducible example will create the crash on an actual device, although you may need to launch and quit the app in quick succession 10-20 times to see the crash. (I realize most users aren't likely to do that - sometimes the crash occurs in the actual app on the first launch. But it's an intermittent problem so may require a few testing rounds to appear.) In addition to the code shown here, I've added the "Background Modes" capability with "Background Fetch" to "Signing & Capabilities" and added the "UpdateBadge" task to "Info" as a "Permitted background task scheduler identifier". Any idea what could be causing the crash and how to prevent it? struct ToyBackgroundTasksApp: App { @Environment(\.scenePhase) private var phase var sharedModelContainer: ModelContainer = { let schema = Schema([ Item.self, ]) let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: false) do { return try ModelContainer(for: schema, configurations: [modelConfiguration]) } catch { fatalError("Could not create ModelContainer: \(error)") } }() var body: some Scene { WindowGroup { ContentView() } .modelContainer(sharedModelContainer) .backgroundTask(.appRefresh("UpdateBadge")) { print("background task") } } }

I have currently created an app which contains an upload button which when clicked upload health data using HealthKit to an AWS S3 bucket. Now I want to implement an automatic file upload mechanism which would mean that the app is installed and opened just once - and then the upload must happen on a schedule (once daily) from the background without ever having to open the app again. I've tried frameworks like NSURLSession and BackgroundTasks but nothing seems to work. Is this use case even possible to implement? Does iOS allow this? The file is just a few KBs in size. For reference, here is the Background Tasks code: import UIKit import BackgroundTasks import HealthKit class AppDelegate: NSObject, UIApplicationDelegate { let backgroundTaskIdentifier = "com.yourapp.healthdata.upload" func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -&gt; Bool { // Register the background task BGTaskScheduler.shared.register(forTaskWithIdentifier: backgroundTaskIdentifier, using: nil) { task in self.handleHealthDataUpload(task: task as! BGAppRefreshTask) } // Schedule the first upload task scheduleDailyUpload() return true } // Schedule the background task for daily execution func scheduleDailyUpload() { print("[AppDelegate] Scheduling daily background task.") let request = BGAppRefreshTaskRequest(identifier: backgroundTaskIdentifier) request.earliestBeginDate = Date(timeIntervalSinceNow: 24*60*60) do { try BGTaskScheduler.shared.submit(request) print("[AppDelegate] Daily background task scheduled.") } catch { print("[AppDelegate] Could not schedule daily background task: \(error.localizedDescription)") } } // Handle the background task when it's triggered by the system func handleHealthDataUpload(task: BGAppRefreshTask) { print("[AppDelegate] Background task triggered.") // Call your upload function with completion handler HealthStoreManager.shared.fetchAndUploadHealthData { success in if success { print("[AppDelegate] Upload completed successfully.") task.setTaskCompleted(success: true) // Schedule the next day's upload after a successful upload self.scheduleDailyUpload() } else { print("[AppDelegate] Upload failed.") task.setTaskCompleted(success: false) } } // Handle task expiration (e.g., if upload takes too long) task.expirationHandler = { print("[AppDelegate] Background task expired.") task.setTaskCompleted(success: false) } } }

I am developing an App that will enable voice calls between users through webrtc. When the user opens the App and switches the App to the background, the user will receive the incoming call notification through Silent Push Notifications (not PushKit). My question is as follows, If set UIBackgroundModes to voip and do not use PushKit and CallKit, will this cause the background App to be unable to use webrtc voice calls (requires network, microphone, and audio permissions)? Can I set UIBackgroundModes = audio combined with AVAudioSession playAndRecord instead of setting UIBackgroundModes to voip, so that I can use the microphone and audio in the background to implement webrtc voice calls? Thanks for your help.

When I run my app with XCode on my iPhone, and then moved into the background, I'm getting a EXC_BREAKPOINT exception after a few minutes, seemingly when iOS attempts to call my app with a BGAppRefreshTask: Thread 23 Queue: com.apple.BGTaskScheduler (com.mycompany.MyApp.RefreshTask) (serial) 0 _dispatch_assert_queue_fail 12 _pthread_wqthread Enqueued from com.apple.duet.activityscheduler.client.xpcqueue (Thread 23) 0 dispatch_async 20 start_wqthread I can't quite understand the reason from this crash. In the background task, I'm attempting to update live activities. In the process, it might encounter code that calls MainActor and manipulate @Observable objects. Might that be the reason?

I am able to setup and schedule a background refresh task as well as manually trigger it via Xcode and the simulator tied to my iPhone 11 Pro test phone using the e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier: However, it won't execute on the app on it's own. And yes, the pinfo.list entries are correct and match! I know the scheduler is not exact on timing but it's just not executing on its own. Since I can trigger manually it I'm pretty sure the code is good but I must be missing something. I created an observable object for this code and the relevant parts look like this: class BackgroundTaskHandler: ObservableObject { static let shared = BackgroundTaskHandler() var taskState: BackgroundTaskState = .idle let backgroundAppRefreshTask = "com.opexnetworks.templateapp.shell.V1.appRefreshTask" func registerBackgroundTask() { BGTaskScheduler.shared.register(forTaskWithIdentifier: backgroundAppRefreshTask, using: nil) { task in self.handleAppRefresh(task: task as! BGAppRefreshTask) } self.updateTaskState(to: .idle, logMessage: "✅ Background app refresh task '\(backgroundAppRefreshTask)' registered.") BGTaskScheduler.shared.register(forTaskWithIdentifier: backgroundTaskIdentifier, using: nil) { task in self.handleProcessingTask(task: task as! BGProcessingTask) } self.updateTaskState(to: .idle, logMessage: "✅ Background task identifier '\(backgroundTaskIdentifier)' registered.") } // Handle the app refresh task private func handleAppRefresh(task: BGAppRefreshTask) { self.updateTaskState(to: .running, logMessage: "🔥 app refresh task is now running.") PostNotification.sendNotification(title: "Task Running", body: "App refresh task is now running.") let queue = OperationQueue() queue.maxConcurrentOperationCount = 1 let operation = BlockOperation { self.doSomeShortTaskWork() } task.expirationHandler = { self.updateTaskState(to: .expired, logMessage: "💀 App refresh task expired before completion.") PostNotification.sendNotification(title: "Task Expired", body: "App refresh task expired before completion \(self.formattedDate(Date())).") operation.cancel() } operation.completionBlock = { if !operation.isCancelled { self.taskState = .completed } task.setTaskCompleted(success: !operation.isCancelled) let completionDate = Date() UserDefaults.standard.set(completionDate, forKey: "LastBackgroundTaskCompletionDate") self.updateTaskState(to: .completed, logMessage: "🏁 App refresh task completed at \(self.formattedDate(completionDate)).") PostNotification.sendNotification(title: "Task Completed", body: "App refresh task completed at: \(completionDate)") self.scheduleAppRefresh() // Schedule the next one } queue.addOperation(operation) } func scheduleAppRefresh() { // Check for any pending task requests BGTaskScheduler.shared.getPendingTaskRequests { taskRequests in let refreshTaskIdentifier = self.backgroundAppRefreshTask let refreshTaskAlreadyScheduled = taskRequests.contains { $0.identifier == refreshTaskIdentifier } if refreshTaskAlreadyScheduled { self.updateTaskState(to: .pending, logMessage: "⚠️ App refresh task '\(refreshTaskIdentifier)' is already pending.") // Iterate over pending requests to get details for taskRequest in taskRequests where taskRequest.identifier == refreshTaskIdentifier { let earliestBeginDate: String if let date = taskRequest.earliestBeginDate { earliestBeginDate = self.formattedDate(date) } else { earliestBeginDate = "never" } self.updateTaskState(to: .pending, logMessage: "⚠️ Pending Task: \(taskRequest.identifier), Earliest Begin Date: \(earliestBeginDate)") } // Optionally, show a warning message to the user in your app PostNotification.sendNotification(title: "Pending Tasks", body: "App refresh task is already pending. Task scheduling cancelled.") return } else { // No pending app refresh task, so schedule a new one let request = BGAppRefreshTaskRequest(identifier: refreshTaskIdentifier) request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60) // Earliest in 15 minutes do { try BGTaskScheduler.shared.submit(request) self.taskState = .scheduled self.updateTaskState(to: .scheduled, logMessage: "✅ App refresh task '\(refreshTaskIdentifier)' successfully scheduled for about 15 minutes later.") PostNotification.sendNotification(title: "Task Scheduled", body: "App refresh task has been scheduled to run in about 15 minutes.") } catch { print("Could not schedule app refresh: \(error)") self.taskState = .failed self.updateTaskState(to: .failed, logMessage: "❌ Failed to schedule app refresh task.") } } } } // Short task work simulation private func doSomeShortTaskWork() { print("Doing some short task work...") // Simulate a short background task (e.g., fetching new data from server) sleep(5) print("Short task work completed.") } In my AppDelegate I trigger the registerBackground task in the didFinishLaunchingWithOptions here: BackgroundTaskHandler.shared.registerBackgroundTask() And I scheduled it here in the launch view under a task when visible: .task { BackgroundTaskHandler.shared.scheduleAppRefresh() } I've also tried the last in the AppDelegate after registering. either way the task schedules but never executes.

we have three problem when using the push notification on Live Activity. 1. What is the specific callback strategy for the activityUpdates property in ActivityKit? We found that in actual user scenarios, there is a probability that we may not receive callbacks. From the community experience, there are some resource optimization strategies that do not perform callbacks. From this perspective, the explanation is kind of vague. Is there any clear feedback to understand why callbacks are performed/not performed? 2.what is the specific description of the wake-up strategy, when background app receive Live Activity offline start Push? From community experience, we can see that the system may wake up for a duration of 0-30s due to resource optimization strategies, or not wake up/not deal with it. Is there an official description of the wake-up strategy? or we also have to follow this description: Wake up of apps using content-available pushes are heavily throttled. You can expect 1-2 wakeup per hour as a best case scenario in the hands of your users. so this cannot be assumed to be a reliable wake-up on demand mechanism for an app. 3 How can we determine user have selected (allow or always allow) of the Live Activity permission? When we use real-time activity offline push, there are two system prompts in iOS: the first prompt : allow and disallow real-time activity the second prompt : always allow and disallow Is there an interface that can directly determine which permission the user has chosen (allow/always allow)? (By the way, we can get disallow status). At present, we haven't seen any interface in the official documentation/interface that can determine (allow/always allow). The difference here will affect the generation of Update Token. Without Update Token, we can not update our activity instance.

Hi I'm new to the forum, I'm planning an app just for Apple watch, I would like to use bluetooth audio in background, how can I do it? The messages I send via bluetooth stop as soon as the watch display turns off. Thank you! Nax

I'm working on an in-house iOS app designed to help users accurately track their routes during trips. Currently, I've implemented a method to track users when the app is open in the background. However, I'm facing challenges, as the tracking stops when the device is locked for more than 10 minutes. I'm looking for a solution to continuously track a user's geolocation, even if the app is closed or not in use. Specifically, I want to ensure uninterrupted tracking, especially when the device is locked. Here are some key points: Current Method: I'm currently using the Core Location method and a combination of background tasks and a repeating timer to fetch the user's location and update a log for geolocation tracking when the app is open in the background. Issues Faced: The tracking stops when the device is locked for more than 10 minutes. This limitation impacts the accuracy of the route tracking during longer trips. Objective: My goal is to achieve continuous geolocation tracking, even when the app is closed or not actively used, to provide users with a seamless and accurate record of their routes. Platform: The app is developed for iOS using the .net maui platform, and I'm seeking solutions or suggestions that are compatible with the iOS .net maui environment. If anyone has experience or insights into achieving continuous geolocation tracking on iOS, especially when the app is not in use or the device is locked, I would greatly appreciate the assistance.

The UIApplication background task mechanism allows you to prevent your app from being suspended for short periods of time. While the API involved is quite small, there’s still a bunch of things to watch out for. The name background task is somewhat misappropriate. Specifically, beginBackgroundTask(expirationHandler:) doesn’t actually start any sort of background task, but rather it tells the system that you have started some ongoing work that you want to continue even if your app is in the background. You still have to write the code to create and manage that work. So it’s best to think of the background task API as raising a “don’t suspend me” assertion. You must end every background task that you begin. Failure to do so will result in your app being killed by the watchdog. For this reason I recommend that you attach a name to each background task you start (by calling beginBackgroundTask(withName:expirationHandler:) rather than beginBackgroundTask(expirationHandler:)). A good name is critical for tracking down problems when things go wrong. IMPORTANT Failing to end a background task is the number one cause of background task problems on iOS. This usually involves some easy-to-overlook error in bookkeeping that results in the app begining a background task and not ending it. For example, you might have a property that stores your current background task identifier (of type UIBackgroundTaskIdentifier). If you accidentally creates a second background task and store it in that property without calling endBackgroundTask on the identifier that’s currently stored there, the app will ‘leak’ a background task, something that will get it killed by the watchdog. One way to avoid this is to wrap the background task in an object; see the QRunInBackgroundAssertion post on this thread for an example. Background tasks can end in one of two ways: When your app has finished doing whatever it set out to do. When the system calls the task’s expiry handler. Your code is responsible for calling endBackgroundTask(_:) in both cases. All background tasks must have an expiry handler that the system can use to ‘call in’ the task. The background task API allows the system to do that at any time. Your expiry handler is your opportunity to clean things up. It should not return until everything is actually cleaned up. It must run quickly, that is, in less than a second or so. If it takes too long, your app will be killed by the watchdog. Your expiry handler is called on the main thread. It is legal to begin and end background tasks on any thread, but doing this from a secondary thread can be tricky because you have to coordinate that work with the expiry handler, which is always called on the main thread. The system puts strict limits on the total amount of time that you can prevent suspension using background tasks. On current systems you can expect about 30 seconds. IMPORTANT I’m quoting these numbers just to give you a rough idea of what to expect. The target values have changed in the past and may well change in the future, and the amount of time you actually get depends on the state of the system. The thing to remember here is that the exact value doesn’t matter as long as your background tasks have a functional expiry handler. You can get a rough estimate of the amount of time available to you by looking at UIApplication’s backgroundTimeRemaining property. IMPORTANT The value returned by backgroundTimeRemaining is an estimate and can change at any time. You must design your app to function correctly regardless of the value returned. It’s reasonable to use this property for debugging but we strongly recommend that you avoid using as part of your app’s logic. IMPORTANT Basing app behaviour on the value returned by backgroundTimeRemaining is the number two cause of background task problems on iOS. The system does not guarantee any background task execution time. It’s possible (albeit unlikely, as covered in the next point) that you’ll be unable to create a background task. And even if you do manage to create one, its expiry handler can be called at any time. beginBackgroundTask(expirationHandler:) can fail, returning UIBackgroundTaskInvalid, to indicate that you the system is unable to create a background task. While this was a real possibility when background tasks were first introduced, where some devices did not support multitasking, you’re unlikely to see this on modern systems. The background time ‘clock’ only starts to tick when the background task becomes effective. For example, if you start a background task while the app is in the foreground and then stay in the foreground, the background task remains dormant until your app moves to the background. This can help simplify your background task tracking logic. The amount of background execution time you get is a property of your app, not a property of the background tasks themselves. For example, starting two background task in a row won’t give you 60 seconds of background execution time. Notwithstanding the previous point, it can still make sense to create multiple background tasks, just to help with your tracking logic. For example, it’s common to create a background task for each job being done by your app, ending the task when the job is done. Do not create too many background tasks. How many is too many? It’s absolutely fine to create tens of background tasks but creating thousands is not a good idea. IMPORTANT iOS 11 introduced a hard limit on the number of background task assertions a process can have (currently about 1000, but the specific value may change in the future). If you see a crash report with the exception code 0xbada5e47, you’ve hit that limit. Note The practical limit that you’re most likely to see here is the time taken to call your expiry handlers. The watchdog has a strict limit (a few seconds) on the total amount of time taken to run background task expiry handlers. If you have thousands of handlers, you may well run into this limit. If you’re working in a context where you don’t have access to UIApplication (an app extension or on watchOS) you can achieve a similar effect using the performExpiringActivity(withReason:using:) method on ProcessInfo. If your app ‘leaks’ a background task, it may end up being killed by the watchdog. This results in a crash report with the exception code 0x8badf00d (“ate bad food”). IMPORTANT A leaked background task is not the only reason for an 0x8badf00d crash. You should look at the backtrace of the main thread to see if the main thread is stuck in your code, for example, in a synchronous networking request. If, however, the main thread is happily blocked in the run loop, a leaked background task should be your primary suspect. Prior to iOS 11 information about any outstanding background tasks would appear in the resulting crash report (look for the text BKProcessAssertion). This information is not included by iOS 11 and later, but you can find equivalent information in the system log. The system log is very noisy so it’s important that you give each of your background tasks an easy-to-find name. For more system log hints and tips, see Your Friend the System Log. iOS 13 introduced the Background Tasks framework. This supports two type of requests: The BGAppRefreshTaskRequest class subsumes UIKit’s older background app refresh functionality. The BGProcessingTaskRequest class lets you request extended background execution time, typically overnight. WWDC 2020 Session 10063 Background execution demystified is an excellent summary of iOS’s background execution model. Watch it, learn it, love it! For more background execution hints and tips, see Background Tasks Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History 2023-06-16 Added a link to my QRunInBackgroundAssertion post. 2022-06-08 Corrected a serious error in the discussion of BGProcessingTaskRequest. Replaced the basic system log info with a reference to Your Friend the System Log. Added a link to Background Tasks Resources. Made other minor editorial changes. 2021-02-27 Fixed the formatting. Added a reference to the Background Tasks framework and the Background execution demystified WWDC presentation. Minor editorial changes. 2019-01-20 Added a note about changes in the iOS 13 beta. Added a short discussion about beginning and ending background tasks on a secondary thread. 2018-02-28 Updated the task name discussion to account for iOS 11 changes. Added a section on how to debug ‘leaked’ background tasks. 2017-10-31 Added a note about iOS 11’s background task limit. 2017-09-12 Numerous updates to clarify various points. 2017-08-17 First posted.

I’m facing an issue with iOS that I hope someone can help with. I developed an app a few years ago that records GPS tracks. Up until recently, everything worked fine—even when the app was running in the background, the recording continued without problems. However, since releasing an update compiled after the iOS 18 release, users have reported that background tracking no longer works. I’ve reviewed the iOS documentation but haven’t found any relevant changes or solutions. Before the newly compiled release the app was working well on iOS 18 devices as well. Some users have reported that switching to the location permission from "When Using the App" to "Always" solved the issue. This is not the case for all users. Has anyone else encountered this issue? Any recommendations or insights on how to resolve it would be greatly appreciated. Below you can see the code used for the location tracking. Before the issue happened the app was compiled with XCode 15.4. Now I am using XCode 16.2 locationManager.activityType = CLActivityType.fitness locationManager.desiredAccuracy = kCLLocationAccuracyBest locationManager.distanceFilter = 3 locationManager.allowsBackgroundLocationUpdates = true locationManager.pausesLocationUpdatesAutomatically = false if #available(iOS 11.0, *) { locationManager.showsBackgroundLocationIndicator = true } locationManager.startUpdatingLocation() if #available(iOS 17.0, *) { // Create a CLBackgroundActivitySession object backgroundActivitySession = CLBackgroundActivitySession() } Thanks in advance for your help!

Hello everyone, I am currently working on a project for the health sector. Basically we have some Bluetooth low energy devices that have a button. When this button is pressed (usually for emergency situation), this event should alert our backend and therefore send help. Is it technically possible to do this on IOS? I am aware that apple have very strict restrictions in relation to background services, and after doing some research I found that it's impossible to run any custom code if the app is terminated by the user. Is there a way to make a request for such special cases so that apple allows us to actually launch the app (or if not possible send a http request) when this beacon button is pressed (Of course with the bluetooth device already connected to the Iphone) even if the app is completely terminated. Thanks :)

I am considering to use the BGAppRefreshTask mechanism, and while I think I have read and understood all documentation and hints in this forum about it (especially the limitations), the one thing I do not understand is: how can I debug it? I cannot find a way to trigger the BGAppRefreshTask execution reliably and immediately. I would have expected the Xcode Debug->Simulate Background Fetch menu to do this for me, but it only sends the app into the background. I am working with the unmodified (except for a few added print()) ColorFeed sample code project from Apple, which schedules a task 15min into the future when it goes to the background. Using a real device, I have not managed to trigger execution of the BGAppRefreshTask more often than once a day so far. Surely, there must be a way to trigger it much more often solely for debugging and development purposes (I am totally happy with all restrictions for the final app). So what detail am I missing here?

Any idea to achieve reliable periodic Bluetooth data retrieval on iOS, even when the app is closed or killed.

Our watch app, Regatta Timer, is a specialised countdown timer for sailing competitions. It is crucial that the beeps & haptics continue when 'wrist down' on alway on displays. We tried to enable this by adding 'background mode' but that only works in the Xcode Apple Watch simulator, not on an actual device with always on display. Any idea how we can get this working also on the Apple Watch device? In ContentView.swift we currently added this code: WKInterfaceDevice.current().play(sound) } but that doesnt work - regardless of adding , phase == .active` or not. STEPS TO REPRODUCE Install on an ACTUAL DEVICE with always on display start the countdown timer: beeps & sounds are OK (each minute,...) do 'wrist down': the countdown timer continues on the dimmed display, but the sounds & haptics stop working until you raise your wrist to wake up the display.