Hi, I'm developing a Live Activity Widget that shows a count down timer. In the current solution I have a stop watch that is responsible for handling the start, stop, resume, reset function. When the stop watch starts I have timer that calls on an updateTime function every 0.2 seconds. This works well. The problems comes when I try to use my stop watch in the Live Activity Widget. I have a timer that updates the live activity attributes with content every 0.5 second. // Start the activity let activity = try? Activity.request(... DispatchQueue.main.async { self.logger.log("Start internal timer") self.timer = Timer.scheduledTimer(withTimeInterval:0.5, repeats: true) { _ in self.logger.log("Update activity widget.") self.updateActivity() } } Is this a correct approach? If not what should I use to implement a stop watch with a count down timer and a corresponding progress bar/view?

DeviceActivityReport presents statistics for a device: https://developer.apple.com/documentation/deviceactivity/deviceactivityreport The problem: DeviceActivityReport can present statistics with a delay for a parent device (when DeviceActivityReport is presenting, the DeviceActivityReportExtension is called to process the statistics). One possible solution is to call DeviceActivityReport periodically throughout the day in a child device. However, the app will not be available all day. Is there any way to run DeviceActivityReport in the background? I have tried the following approach, but it didn’t work (DeviceActivityReportExtension didnt call): let hostingController: UIHostingController? = .init(rootView: DeviceActivityReport(context, filter: filter)) hostingController?.view.frame = .init(origin: .zero, size: .init(width: 100, height: 100)) hostingController?.beginAppearanceTransition(true, animated: false) hostingController?.loadView() hostingController?.viewDidLoad() try? await Task.sleep(for: .seconds(0.5)) hostingController?.viewWillAppear(true) hostingController?.viewWillLayoutSubviews() try? await Task.sleep(for: .seconds(0.5)) hostingController?.viewDidAppear(true) try? await Task.sleep(for: .seconds(0.5)) hostingController?.didMove(toParent: rootVC) try? await Task.sleep(for: .seconds(0.5)) hostingController?.viewWillLayoutSubviews() hostingController?.viewDidLayoutSubviews() hostingController?.view.layoutIfNeeded() hostingController?.view.layoutSubviews() hostingController?.endAppearanceTransition() Is there any way to run DeviceActivityReport in the background? (when app is not visible/closed). The main problem is call DeviceActivityReport

Hello Apple Developer Team, I am facing an issue with remote notifications in my iOS app. When the app is in a terminated (kill) state, notifications are successfully received by the device, but none of the app's handlers (like _firebaseMessagingBackgroundHandler in Flutter) are invoked. This is impacting our ability to process silent notifications or perform background tasks reliably when the app is not running. Steps to reproduce: Send a remote notification with content-available: 1 in the payload. Confirm the notification is received by the device while the app is in kill mode. Observe that no background or foreground notification methods are triggered in the app. Expected Behavior: The app should invoke the background handler to process the notification payload, even in a terminated state. Observed Behavior: The notification is delivered to the device, but no app-level processing occurs because none of the methods are triggered. Can you please confirm if this is the intended behavior due to iOS limitations, or if there is a configuration or alternative solution to allow background handlers to execute in such scenarios? Any guidance or clarification would be highly appreciated. Thank you!

The application was initially written in Swift, and we released an update where the app was rewritten in Flutter. Currently, we are adding a widget natively written in SwiftUI to the Home screen. The widget updates are managed by BGTaskScheduler. In BGTaskScheduler, an API request is made to fetch the latest data. The data is then processed to calculate an average value, which is subsequently sent to UserDefaults. The widget displays data fetched from UserDefaults. The minimum update interval is set to 30 minutes. When testing the widget updates through a build in Xcode, the widget updates as expected at the specified interval. However, when this build was provided to users via TestFlight, the widget does not update for them. Could this issue be related to TestFlight’s resource limitations? Is there any guarantee that releasing this version will ensure the widget updates correctly for users?

Hello, I have a some problem with background fetch. In my app I use background modes for fetch data and display on my home widget iPhone. Its working correct when I built app on my phone from Xcode but when I distribute my app on TestFlight my home widget not updating at all. Help me understand if this issue is only due to TestFlight resources, or should I try releasing the app and hope that it will work in the release version?

We run simple iOS Swift code triggered by a remote notification: UserDefaults.standard.set("key", forKey: "value") It runs fine when the app is active or inactive, but when the device is closed/locked and the code is triggered, we see a warning in Xcode: Couldn't write values for keys ( key ) in CFPrefsPlistSource<0x3018802d0> (Domain: com.example, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No): Path not accessible Not updating lastKnownShmemState in CFPrefsPlistSource<0x3018802d0> (Domain: com.example, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No): 767 -> 767 The issue is that there seems to be no way to catch that warning. The value is set, when it's re-read the value is correct. But the value is never written to disk, so after an app restart/update the value is gone, potentially has an old wrong value. This code runs without any interruption, it's just showing the warning on iOS 17.7.1 on iPad: UserDefaults.standard.set("key", forKey: "value") UserDefaults.standard.synchronize() print("value: \(UserDefaults.standard.string(forKey: "key"))") Should there not be a way to catch this, so the code can act accordingly to the circumstances? It would be good to know inside the code that the value is not persisted. I would expect that an exception is generated somewhere which can be caught. It seems .completeFileProtectionUntilFirstUserAuthentication enables files to be written to disk while the device is closed/locked, can something similar be used for UserDefaults.standard?

Does anyone know how battery state notification (UIDevice.batteryStateDidChangeNotification) is supposed to work regarding app foreground/background state? Assume there is no other reason why the app is running in the background. I have enabled UIDevice.current.isBatteryMonitoringEnabled when the app was in the foreground. What should happen if the external power is later connected or removed when the app is in the background? The docs don't mention this. Possibilities include I don't get a notification, so I should check the state myself when the app next comes to the foreground. I'll get a notification when the app next comes to the foreground, if the state changed while it was in the background. The app will be woken up in the background to receive the notification. The app will be kept running in the background while isBatteryMonitoringEnabled is true. It looks as if it's doing either 3 or 4, which I find a bit surprising. But is this influenced by the fact that it's connected (wirelessly) to the debugger?

Hi team, I'm working on an MQTT client for Apple platforms (macOS, iOS, and possibly tvOS and watchOS). I would like the client to listen to messages even when the application is in the background. I would appreciate any suggestions on the best approach to achieve this. Based on iOS Background Execution Limits, it seems that my best bet is to use a long-running background process with BGProcessingTaskRequest while setting up the connection. Does that sound like the right approach? Is there any limits for the bg tasks? I currently have a working BSD socket. I'm not sure if it is necessary to switch to the Network Framework to have the background task working, but I'm open to switching if it's necessary. If the approach works, does that mean I could built a http client to process large upload/download tasks without using NSURLSession? As I'm working on a cross platform project, it would be benefit if I dont need a separate http client implementation for Apple. Any insights on this topic would be greatly appreciated. Additionally, it's off topic, but the link to "WWDC 2020 Session 10063 Background Execution Demystified" (https://developer.apple.com/videos/play/wwdc2020/10063/) is broken. Is there a way to access the content there? Thanks in advance for your help and insights!

Within the output of command "sudo sfltool dumpbtm", in addition to records for UID 0/501/502/..., at the top of the output, there are also records for "UID -2" listed. ======================== Records for UID -2 : FFFFEEEE-DDDD-CCCC-BBBB-AAAAFFFFFFFE ======================== ServiceManagement migrated: true SharedFileList migrated: false LaunchServices registered: false Items: #1: UUID: FC60A3EA-E4B0-4D8C-BA07-1C6E2DF3AA52 Name: (null) Developer Name: (null) Type: developer (0x20) Flags: [ ] (0) Disposition: [disabled, allowed, visible, not notified] (0x2) Identifier: Unknown Developer URL: (null) Generation: 0 Embedded Item Identifiers: #1: 16.com.microsoft.teams.TeamsUpdaterDaemon But a uid with -2 should be invalid, and the guid "FFFFEEEE-DDDD-CCCC-BBBB-AAAAFFFFFFFE" followed looks also strange.

Hi, I would like to know if it is safe to call the uploadTask from URLSession from the main thread ? We've a user who is reporting repeated crashes at startup, here is the stack we see: Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: app<com.appspot.myApp(E7590BB1-722C-491D-9199-F867DE4B880A)>:2212 exhausted real (wall clock) time allowance of 10.00 seconds ProcessVisibility: Background ProcessState: Running WatchdogEvent: scene-update WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 21.260 (user 10.230, system 11.030), 35% CPU", "Elapsed application CPU time (seconds): 0.006, 0% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive> Triggered by Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x1def7a688 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1def7dd98 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1def7dcb0 mach_msg_overwrite + 424 3 libsystem_kernel.dylib 0x1def7dafc mach_msg + 24 4 libdispatch.dylib 0x1968d8f14 _dispatch_mach_send_and_wait_for_reply + 544 5 libdispatch.dylib 0x1968d92b4 dispatch_mach_send_with_result_and_wait_for_reply + 60 6 libxpc.dylib 0x21714a930 xpc_connection_send_message_with_reply_sync + 256 7 Foundation 0x18d80a3ac __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ + 16 8 Foundation 0x18d806b14 -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2160 9 CoreFoundation 0x18eb868dc ___forwarding___ + 1004 10 CoreFoundation 0x18eb86430 _CF_forwarding_prep_0 + 96 11 CFNetwork 0x1900c71e0 -[__NSURLBackgroundSession setupBackgroundSession] + 800 12 CFNetwork 0x1900b3e80 -[__NSURLBackgroundSession initWithConfiguration:delegate:delegateQueue:delegateDispatchQueue:] + 552 13 CFNetwork 0x1900b4784 +[NSURLSession _sessionWithConfiguration:delegate:delegateQueue:delegateDispatchQueue:] + 1496 14 MyApp 0x1054210b4 CombineBgXferRepository.session.getter (in MyApp) (CombineBgXferRepository.swift:62) + 7966900 15 MyApp 0x105422fa4 CombineBgXferRepository.startUploadTask(fileURL:request:) (in MyApp) (CombineBgXferRepository.swift:310) + 7974820 If it is ok to call this uploadTask from the main thread, does this crash indicate a problem with the operating system? Are there scenarios where the background upload service does not respond to requests?

Our application has seen a surge in the volume of background launches starting from April and May, and we want to know under what circumstances the application can be launched from the background. First, here's how I determined background launches: we analyze user logs and append UIApplication.appState to each line of log, finding that every log from the start to the end of user sessions has an appState of UIApplicationStateBackground. By checking the "ActivePrewarm" in main() and printing the launch options from application:didFinishLaunchingWithOptions:, we found several scenarios for background launches: launchOptions has a value with the key UIApplicationLaunchOptionsRemoteNotificationKey. launchOptions has no value and there is no "ActivePrewarm." launchOptions has no value but has "ActivePrewarm." I would like to know: Under what circumstances will notifications trigger a background launch (I cannot replicate this locally)? Under what circumstances does an application launch in the background and trigger application:didFinishLaunchingWithOptions: but without any launch options? I hope informations below can provide some insights. Regarding "ActivePrewarm," I've read various questions and answers in the Apple Developer Forums, such as this thread, which states that "ActivePrewarm" does not trigger application:didFinishLaunchingWithOptions: but occurs due to certain behaviors in the application. I would like to know what behaviors may cause this background launch, as there is no information in the launch options, or how I can identify what behaviors triggered it. Specifically, based on that same thread, I've tried to gather more information using runningboardd, and I've currently identified two special cases: When I restart my phone and unlock it after a short period, there is information: &lt;RBSDomainAttribute| domain:"com.apple.dasd" name:"DYLDLaunch" sourceEnvironment:"(null)"&gt; ]&gt; Every day, at intervals of a few hours, there is information: &lt;RBSDomainAttribute| domain:"com.apple.dasd" name:"DYLDLaunch" sourceEnvironment:"(null)"&gt; ]&gt; Then, the following similar information follows: 12:15:56.047625+0800 runningboardd Executing launch request for app&lt;{my_bundle_id}((null))&gt; (DAS Prewarm launch) 12:15:56.050311+0800 runningboardd Creating and launching job for: app&lt;{my_bundle_id}((null))&gt; 12:15:56.050333+0800 runningboardd _mutateContextIfNeeded called for {my_bundle_id} 12:15:56.080560+0800 runningboardd app&lt;{my_bundle_id}((null))&gt;: -[RBPersonaManager personaForIdentity:context:personaUID:personaUniqueString:] required 0.000954 ms (wallclock); resolved to {1000, 39E408CF-2E67-4DB0-BF73-CFC5792285CD} 12:15:56.080632+0800 runningboardd 'app&lt;{my_bundle_id}(39E408CF-2E67-4DB0-BF73-CFC5792285CD)&gt;' Skipping container path lookup because containerization was prevented (&lt;RBSLaunchContext: 0xcd8cc9180&gt;) 12:15:56.080939+0800 runningboardd 'app&lt;{my_bundle_id}(39E408CF-2E67-4DB0-BF73-CFC5792285CD)&gt;' Constructed job description: &lt;dictionary: 0xcd8aa2a00&gt; { count = 19, transaction: 0, voucher = 0x0, contents = *** } 12:15:56.084839+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] Memory Limits: active 4096 inactive 4096 &lt;private&gt; 12:15:56.084861+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] This process will be managed. 12:15:56.084882+0800 runningboardd Now tracking process: [app&lt;{my_bundle_id}((null))&gt;:1649] 12:15:56.084928+0800 runningboardd Calculated state for app&lt;{my_bundle_id}((null))&gt;: running-active (role: Background) (endowments: (null)) 12:15:56.086762+0800 runningboardd Using default underlying assertion for app: [app&lt;{my_bundle_id}((null))&gt;:1649] 12:15:56.086977+0800 runningboardd Acquiring assertion targeting [app&lt;{my_bundle_id}((null))&gt;:1649] from originator [app&lt;{my_bundle_id}((null))&gt;:1649] with description &lt;RBSAssertionDescriptor| "RB Underlying Assertion" ID:33-33-23101 target:1649 attributes:[ &lt;RBSDomainAttribute| domain:"com.apple.underlying" name:"defaultUnderlyingAppAssertion" sourceEnvironment:"(null)"&gt;, &lt;RBSAcquisitionCompletionAttribute| policy:AfterApplication&gt; ]&gt; 12:15:56.087203+0800 runningboardd Assertion 33-33-23101 (target:[app&lt;{my_bundle_id}((null))&gt;:1649]) will be created as active 12:15:56.087946+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] reported to RB as running 12:15:56.088053+0800 runningboardd Calculated state for app&lt;{my_bundle_id}((null))&gt;: running-active (role: Background) (endowments: (null)) 12:15:56.088114+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] Set jetsam priority to 0 [0] flag[1] 12:15:56.088136+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] Resuming task. 12:15:56.088211+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] Set darwin role to: Background 12:15:56.088449+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] set Memory Limits to Hard Inactive (4096) 12:15:56.089314+0800 runningboardd Successfully acquired underlying assertion for [app&lt;{my_bundle_id}((null))&gt;:1649] 12:15:56.589755+0800 runningboardd Invalidating assertion 33-76-23100 (target:app&lt;{my_bundle_id}((null))&gt;) from originator [osservice&lt;com.apple.dasd&gt;:76] 12:15:56.590332+0800 runningboardd Removed last relative-start-date-defining assertion for process app&lt;{my_bundle_id}((null))&gt; 12:15:56.593760+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] Suspending task. 12:15:56.594120+0800 runningboardd Calculated state for app&lt;{my_bundle_id}((null))&gt;: running-suspended (role: None) (endowments: (null)) From these logs, I understand that the system is accelerating the launch speed of the application. But the time interval between these two logs below is very short, which suggests that the prewarm is executed just before main, and then the process is suspended. Is this understanding correct? 12:15:56.089314+0800 runningboardd Successfully acquired underlying assertion ... 12:15:56.589755+0800 runningboardd Invalidating assertion ... Regarding "DAS DYLD3 Closure Generation," I speculate that after a user restarts their phone, the system uses DYLD3 to prepare closures for frequently used applications, allowing for faster application launches. Is this assumption correct?

Can I integrate Timer along with liveUpdates(_:) in order to manipulate the frequency. Let say for example I need the user location ever 1 min. Is it possible to do so?

We developed a app in which the I need the app to update the User's location even in background( even after terminating from the recent UI ), Currently I am receiving the location updates when the user has kept the app in open and if minimised, But I want that it should update the location even when it is removed from recent app (minimised UI)(after terminating the app) Is it possible to do so.???

Greetings, does anyone know if can I use background capabilities to refresh auth token safely without be aware of the OS kill this task? Is there any Apple Oficial recommended flow to handle that? thanks

Per Quinn the Eskimo's great summary post I am looking for the WWDC 2020 Session 10063 "Background execution demystified" but all links seem to be broken or redirecting elsewhere. Does anyone know where one could find a reputable copy of the video to watch as we explore background execution?