I activate the conditions as follows Unexpected operation found. Details are below Conditions and configurations used in the testing "Background Modes" Capability with "Location updates" checked on added the info.plist keys: NSLocationAlwaysAndWhenInUseUsageDescription, NSLocationWhenInUseUsageDescription with description invoking startMonitoringSignificantLocationChanges using core location API invoking didUpdateLocations using core location API Using Background fetch (15 minutes) I swipe the app to switch from foreground to background mode, and stop the app without deleting it in the switcher. A few hours after the app was stopped, didfinishlaunch, didenterBackground, background fetch, and didUpdateLocation code did not run, but the app started running again in the background from the point it was stopped. The wake-up time is random, and the app will freeze again within a few seconds of running again.(I took logs in all delegate functions related to the app life cycle in the AppDelegate file, but nothing was executed when the app was relaunched.) Is the above behavior normal? If it's normal, who wakes up the app? How do I prevent my app from restarting unexpectedly?

Is there a good explanation somewhere of where background task identifiers are registered and how to modify these? I have entered the "Permitted background task scheduler identifiers" into my xcode target, and it is replicated automatically in Info.plist. I can run the app (which registers the identifier), move it to background (which schedules the task), and then use the debugger to test the launch ("e -l objc -- (void)[[BGTaskScheduler sharedScheduler]..."). However, if I then go back and change the identifier string in the target, plist, and app code, the debugger no longer launches the app in background. It doesn't issue any errors, but just doesn't run it. The change I made to the name is to add an "x" at the end of the string. If I change it back in the target, plist, and app, it works again just fine.

As the title says. We have a pretty specific need for our app, and I have an idea of how to achieve it, but would like input on whether it's good practice or not. In communication apps such as Whatsapp or Discord, they need to send local notifications (and ideally update cached message data so it's fresh) anytime the user gets a new message. Conveniently for them, they control the backend, and so can just send out a silent push notification to the device(s) of user involved. In our case, we are creating a UI for someone else's backend, meaning we can't simply send a silent push on data change. What we were originally thinking was a sort of crowd-source involving a combination of silent push and background refresh, but refresh won't work if the user closes the app. I've read all the given reasons for this, and though I still disagree, there isn't anything we can do about it. So what I'm now thinking is that, at whatever interval (say 1-3hrs) some serverless function sends a silent push to every single client, which will wake them up to make a fetch and compare to the cached data and send a local notification if necessary. Downside here is it will likely incur some cost, and frankly it just feels kind of iffy as a solution, but I'm not sure what else we can do without controlling the backend API. Thoughts? Is there anything I'm missing? Any better ideas? Thanks in advance!

Greetings all, I have installed 2 similar function apps (which are safe/signed e.t.c.) I run at different times, and both add items to the Login Items background section, the one is adding a background daemon and is only functioning when the switch is turned to on, while the other adds a PriviledgedHelperTool and can function even if the switch is turned to off, but if it is turned to on, but if I run this app then somehow the other breaks and can not function properly. So as a workaround I keep the PriviledgedHelperTool switch to off and only the other app's daemon switch to on so they can both operate whenever I want. My question has to do with the one that adds the PriviledgeHelperTool, and I wonder if this script contains any crucial information for the functioning of the according application. Though even if I deleted the PriviledgedHelperTool of it from the according folder, and launched the app, it seems it was not regenerated neither any notification shown up or so. Furthermore even if I removed the PriviledgedHelperTool the app seems to function properly, but I would like that thought to be confirmed by some community experts / developers here. I am on MacBook Air M1, macOS Sonoma 14.3 Developer Beta Thank you all in advance for your time. Best regards.

In ios17 and above, I can detect when swiftUI app goes into and out of background using: @Environment(\.scenePhase) private var phase ... .onChange(of: phase) { switch phase { case .background: print("entering background...") case .active: print("entering foreground...") default: break } } Is there a straightforward way to do this in SwiftUI for ios 16? I've found some examples using UIKit, but I am not that swift (sorry, couldn't resist) with that framework.

Hi There, I am trying to record a meeting and upload it to AWS server. The recording is in .m4a format and the upload request is a URLSession request. The following code works perfectly for recordings less than 15 mins. But then for greater recordings, it gets stuck Could you please help me out in this? func startRecording() { let audioURL = getAudioURL() let audioSettings = [ AVFormatIDKey: Int(kAudioFormatMPEG4AAC), AVSampleRateKey: 12000, AVNumberOfChannelsKey: 1, AVEncoderAudioQualityKey: AVAudioQuality.high.rawValue ] do { audioRecorder = try AVAudioRecorder(url: audioURL, settings: audioSettings) audioRecorder.delegate = self audioRecorder.record() } catch { finishRecording(success: false) } } func uploadRecordedAudio{ let _ = videoURL.startAccessingSecurityScopedResource() let input = UploadVideoInput(signedUrl: signedUrlResponse, videoUrl: videoURL, fileExtension: "m4a") self.fileExtension = "m4a" uploadService.uploadFile(videoUrl: videoURL, input: input) videoURL.stopAccessingSecurityScopedResource() } func uploadFileWithMultipart(endPoint: UploadEndpoint) { var urlRequest: URLRequest urlRequest = endPoint.urlRequest uploadTask = URLSession.shared.uploadTask(withStreamedRequest: urlRequest) uploadTask?.delegate = self uploadTask?.resume() }

I'm trying to add Background Tasks to my SwiftUI app using the modifier backgroundTask(_:action:). I've been unable to get a working example, nothing ever updates in my app in the "background". I've added the identifier to the permitted background task scheduler identifiers , enabled the required background modes capabilities. Any help would be appreciated. It appears that neither appRefresh nor urlSession background tasks are effective in handling the update of JSON data in my app. Also which background task would be best suited for updating json data for my app? When debugging and launching using e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"apprefresh"] doesn't get called on a real device. App struct MyApp: App { @State private var viewModel = ViewModel() var body: some Scene { WindowGroup { ContentView() .environment(viewModel) } .backgroundTask(.appRefresh("apprefresh")) { scheduleAppRefresh() await viewModel.appRefresh() } .backgroundTask(.urlSession("apprefresh")) { scheduleAppRefresh() await viewModel.urlSession() } .onChange(of: phase) { switch phase { case .background: scheduleAppRefresh() default: break } } } func scheduleAppRefresh() { let request = BGAppRefreshTaskRequest(identifier: "apprefresh") request.earliestBeginDate = .now.addingTimeInterval(15 * 60) try? BGTaskScheduler.shared.submit(request) } } ViewModel @Observable class ViewModel { func appRefresh( ) async { } func urlSession( ) async { let config = URLSessionConfiguration.background( withIdentifier: "apprefresh" ) config.sessionSendsLaunchEvents = true let session = URLSession( configuration: config ) let request = URLRequest( url: URL( string: "" )! ) let response = await withTaskCancellationHandler { try? await session.data( for: request ) } onCancel: { let task = session.downloadTask( with: request ) task.resume() } } }

I have a BLE device and the centralManger scans with "centralManager.scanForPeripherals(withServices: [connectionServiceUUID], options: nil)" Then func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) { ... } is called. Here, I could get the advertisementData[CBAdvertisementDataLocalNameKey]. I have set my BLE device to change its local name key for every connections. The BLE communication is repeated in the background.(scan, connect, stop scan, disconnect, ... etc) It works well, but when the screen is off, the value of advertisementData[CBAdvertisementDataLocalNameKey] in didDiscover does not change. Why?

I'm trying to set up background HTTP upload requests (syncing files from the user's phone to a server) that trigger periodically in my Swift app. I don't have strict requirements on when this runs (it can happen overnight or throughout the day). I know Apple provides several APIs for background tasks on iOS (beginBackgroundTask, BGAppRefreshTaskRequest, BGProcessingTaskRequest, URLSession upload vs. background session). And I've seen this post on the Apple developer forums that attempts to explain the differences and when to use which - as well as Apple's page on the subject, but it's still not clear to me how a few of these work in practice, and thus which ones I should utilize for my use case. My questions: How should I schedule periodic file upload tasks in the background? I assume I should use BGProcessingTaskRequest, since I don't know exactly how long the task will take (it could be syncing just 1-2 files, or it could be hundreds) and I don't care if it runs overnight How should I ensure foreground tasks are able to complete after closing the app? (i.e. when a user starts a sync manually in the app) From Apple's page on URLSessionUploadTask: "Unlike data tasks, you can use upload tasks to upload content in the background." Does this mean any requests I make using URLSession.shared.upload() will automatically run in the background if the user closes the app? Even with the async/await version, or do I have to use the completionHandler version? Do I need to call beginBackgroundTask if I'm using URLSession.shared.upload() to guarantee I get more time to finish uploads? What about sequential requests (i.e. requests that haven't started yet by the time the app is closed)? Based on this StackOverflow response, it sounds like I may need to trigger all the uploads in parallel beforehand? https://stackoverflow.com/a/53949607/2359478 Should I even consider URLSessionConfiguration.background for my use case? It sounds like it I use beginBackgroundTask and BGProcessingTaskRequest then this may be unnecessary? Thanks!

Hello Apple Community, I am writing to discuss a limitation I’ve encountered with third-party alarm clock apps on iOS. As it stands, these apps are unable to function like the native Clock app, primarily due to the restrictions imposed by the operating system. Currently, third-party alarm apps rely on standard local notifications, which fire once and then cease. This means that if a user misses the initial notification, there’s no backup mechanism to ensure they are alerted. This is a significant drawback for users who rely on these apps to manage their time effectively. Moreover, some apps have found a workaround by playing a silent sound in the background to keep the app active. However, this method is not only against Apple’s guidelines but also drains the device’s battery life. I propose that Apple consider allowing third-party apps to push notifications from the background in an alarm style, with clear permissions granted by the user. This would enable users to clearly define acceptable notifications and specify an alarm-like display, providing a more personalized and effective alarm experience. By implementing this change, Apple could greatly enhance the functionality and user-friendliness of third-party alarm clock apps, ultimately benefiting the end-users and developers alike. Because this alarm feature is so important for productivity and quick responses to critical events or triggers I'm trying to see how some concepts could be reimagined if we had a little more flexibility. Apple iOS has a feature called StandBy mode that activates when an iPhone is charging and positioned on its side. This feature can be thought of as a kind of smart display for your iPhone that offers fast access to different screens of glanceable information. Always-On Display: StandBy mode can keep the display on even when the phone is locked, which is useful for an alarm app. Users can glance at the time without having to unlock their phone w/ Low-Light Adaptation Customizable Screens: StandBy mode consists of screens that can be accessed by swiping horizontally on your iPhone’s display. This could allow an alarm app to display additional information, such as route, or weather warnings. Interactive Widgets: The widget screen in StandBy mode is interactive and customizable. I look forward to hearing your thoughts on this matter. Best regards, Phil Cutting

Description We have a sidebar-detail layout in our app. Since we moved from NavigationView on iOS 15 to NavigationSplitView on iOS 16, we've seen some issues. On iOS 16, the app is always killed, or reset, when the app enters background. That means whatever the sidebar and detail view show, they will almost always return to the initial blank screen state when coming back from background. On iOS 17, the background issue is mitigated. However, the toolbar button is missing after coming back from background. Those problem aren't present in NavigationView on iOS 15. Steps to Repro General steps… Create a new iOS app demo project with deployment target min version set to iOS 16. Copy and paste the code snippet below into ContentView.swift. Run the app on iPad simulator with the respective Simulator OS versions. iOS 16 Tap the info button on the side bar, it presents a "form sheet" style page. Put the app into background. Open any app. I opened the Photos app. Switch back to the demo app. The sheet is dismissed and the app returns to the initial state, which indicates the app was reset in the background. When I tap the info button again, it doesn't present a sheet. iOS 17 Same steps as 1-3 above for iOS 16. Switch back to the test app. The sheet is not dismissed, which means the app wasn't reset in the background. However, you can see the info button is missing from the sidebar's top toolbar. Similar Posts NavigationSplitView resetting when app enters background: https://developer.apple.com/forums/thread/733472 Selection state is lost when navigating to/from home screen: https://developer.apple.com/forums/thread/728657 SwiftUI NavigationSplitView looses toolbar button when App moves to background - iOS 17 / Xcode 15.0: https://stackoverflow.com/questions/77253055 Repro Code Snippet import SwiftUI struct ContentView: View { let samples = ["foo", "bar"] var body: some View { NavigationSplitView { NavigationStack { sidebar } } detail: { NavigationStack { detail } } } var sidebar: some View { Sidebar(samples: samples) } var detail: some View { Text("Select a sample from the list.") } } struct Sidebar: View { @State private var isPresented = false let samples: [String] var body: some View { List { ForEach(samples, id: \.self) { sample in Text(sample) } } .navigationTitle("Foo") .toolbar { ToolbarItem(placement: .navigationBarTrailing) { Button("Info") { isPresented = true } .sheet(isPresented: $isPresented) { AboutView() } } } } } struct AboutView: View { @Environment(\.dismiss) private var dismiss: DismissAction var body: some View { NavigationStack { List { Text("Copyright © 2023 Foo. All Rights Reserved.") } .navigationTitle("About") .navigationBarTitleDisplayMode(.inline) .toolbar { ToolbarItem(placement: .confirmationAction) { Button("Done") { dismiss() } } } } } }

Hello Community, Need your help/guidance please. Seeking LocationServices experts who can advise me whether my idea for a valuable add-on feature that I've been trying to add into my app for 2+ months is achievable or not given LocationServices limitations. The Feature: to enable users who would like to be automatically notified whenever they're within X meters from a store that provides them an exclusive discount BUT only when they choose to be notified. Instruction to enjoy the feature is by keeping app open in 'background state' (means opened and kept in background) but not when app is terminated state (completely closed). The state is important because I would like to give users the choice to only receive notifications when they choose to instead of all-time. That is to eliminate unnecessary power consumption fetching location updates constantly when user don't need them (example staying at home, at work, etc), but give them option when they go out. Ideal scenario (after opting in to enable 'Always'): user launches the app, keeps in background, go out shopping/dining/etc and enjoy convenience of being automatically notified whenever about Xmeters from a place that they have an exclusive offer for. Implemented conditions: API is called at fixed time interval whenever user is within about 10 meters from their last location, that is to limit checking only when there is certainty user is within the same place for sometime instead of just walking by (this currently works perfectly, using AccuracyBest), the challenge when user terminates app, LocationServices wakes up again and continues to fetch location updates constantly. The Ask: Is it technically possible that I configure app LocationServices to not wake-up with [AccuracyBest] when terminated but instead use only reduced accuracy (like 'significant location updates' or on 'AccuracyOne/ThreeKilometer')? Ideas/suggestions/recommendations would be much much appreciated

I would like to call a "GetMessages" API every 10 minutes while the app is not active or shutdown. if a message is returned, display the message as a local notification Will the background api run if the app is shut down? An example of this is when an email app shows a notification. Can they pull from their server while the app is not running or do they use the push notification service. I know that calendar events can be scheduled locally and for location changes, but I don't know if calling a api task with the app not running is possible.

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.

launch due to a background fetch event does not work when debug in iOS17. it work correctly in iOS16, even though debug with xcode15.0.1

Use case : We want to update our app content while the app is in the background. We want to download some json data from our backend server(HTTP GET) and update the content of the application so that next time when user launches the app he see updated content. We are using apple’s BackgroundTasks framework API, specially BGAppRefreshTask and BGProcessingTask. Pretty standard Problem → HTTP request via URLSession does not work. We register and schedule BGAppRefreshTask and BGProcessingTask. Our application is launched in the background by iOS. But when we make an HTTP request to a web server, we do not get any response callback. With default configuration, after making the request the response callback or the URLSessionDataDelegate methods are not called at all. (I also tried with google url. just to be sure the problem is not only with our backend) . Every thing works fine when I check entire flow while debugging and I am connected to Xcode and trigger a background launch by using this command e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"com.background_cloud_sync_apprefresh"] I am kind of stuck with this issue and have run out of ideas to try. So I am reaching out to expert here if you have faced any such issue on iOS. I have tried URLSession with callback as well as with URLSessionDataDelegate.

Hello fellow developers. I'm working on adding background tasks to my SwiftUI app and running into some issues. I have added the capabilities for background modes (fetch and processing) and the correct identifiers in "Permitted background task scheduler identifiers" When I test the background tasks on my device, it seems to only schedule the first task and ignoring the rest. I can run the first background task just fine with the command: e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"spotpricesRefresh"] But it only works for the first task since no other tasks seem to be scheduled. My code looks as below: .onChange(of: phase) { if (phase == .background) { scheduleSpotpricesRefresh() scheduleEmissionsRefresh() scheduleSourcesRefresh() BGTaskScheduler.shared.getPendingTaskRequests(completionHandler: { request in print("Pending task requests: \(request)") }) } } .backgroundTask(.appRefresh("spotpricesRefresh")) { await refreshSpotprices() } .backgroundTask(.appRefresh("emissionsRefresh")) { await refreshEmissions() } .backgroundTask(.appRefresh("sourcesRefresh")) { await refreshSources() } func scheduleSpotpricesRefresh() { let request = BGAppRefreshTaskRequest(identifier: "spotpricesRefresh") request.earliestBeginDate = Date(timeIntervalSinceNow: 60 * 60) do { try BGTaskScheduler.shared.submit(request) print("Scheduling spotprice refresh task") } catch { print("Could not schedule spotprices refresh: \(error)") } } func scheduleEmissionsRefresh() { let request = BGAppRefreshTaskRequest(identifier: "emissionsRefresh") request.earliestBeginDate = Date(timeIntervalSinceNow: 60 * 62) do { try BGTaskScheduler.shared.submit(request) print("Scheduling emissions refresh task") } catch { print("Could not schedule emissions refresh: \(error)") } } func scheduleSourcesRefresh() { let request = BGAppRefreshTaskRequest(identifier: "sourcesRefresh") request.earliestBeginDate = Date(timeIntervalSinceNow: 60 * 61) do { try BGTaskScheduler.shared.submit(request) print("Scheduling sources refresh task") } catch { print("Could not schedule sources refresh: \(error)") } } func refreshSpotprices() async { do { scheduleSpotpricesRefresh() ... } catch { print("Error occurred refreshing spotprices with error: \(error)") } } func refreshEmissions() async { do { scheduleEmissionsRefresh() ... } catch { print("Error occurred refreshing emissions with error: \(error)") } } func refreshSources() async { do { scheduleSourcesRefresh() ... } catch { print("Error occurred refreshing sources with error: \(error)") } } Here is the output when debugging the app: Scheduling spotprice refresh task Scheduling emissions refresh task Scheduling sources refresh task Pending task requests: [<BGAppRefreshTaskRequest: spotpricesRefresh, earliestBeginDate: 2023-11-14 10:24:51 +0000>] I hope someone can point me in the right direction. Thank you in advance. Best regards, Casper

In the WWDC 2020 session "Background execution demystified", it was mentioned that the runtime of non-discretionary Background URL Sessions (using URLSession background transfer) is influenced mainly by factors such as the App Switcher and rate limits. Based on this information, I'm curious to know if there are specific factors that similarly affect the runtime of UIApplication.shared.beginBackgroundTask(). Are there any documented constraints or system behaviors that impact how long a background task initiated by this method can run? I would appreciate any documentation or insights that could help clarify this aspect of background task management in iOS.