I am running iOS 16.2, and this is occurring for all my users, who are also all running iOS 16 which is the minimum required iOS version to run my app. I've filed https://feedbackassistant.apple.com/feedback/11875956 using Feedback Assistant.

From Kmart's comment, it seems like this is a known issue. Is there a known workaround that I could use before the bug is fixed?

Thank you for your reply, and for all your replies on my questions on the DeviceActivity Framework! I've filed https://feedbackassistant.apple.com/feedback/11901286. But do you have any information about apps or websites that do not fall under a specific category, but are still monitored by DeviceActivityMonitor by default (without selecting any categories, apps, or websites). I am particularly suspicious of FaceTime, which does not show up anywhere in a breakdown inside iOS' native Screen Time app, but does add to total Screen Time reported. Settings and Safari also appear to have non-typical behavior like this. Can you provide any knowledge you have about these apps that do not appear under a specific category, and how they behave under the DeviceActivity Framework?

Thank you for the solution, and it almost works perfectly! However, I am trying to wait for two network requests, and only the first one is running. Here is a sample of my code: let waitForMyNetworkRequest = DispatchGroup() waitForMyNetworkRequest.enter() Task { // This request successfully hits my server     await pushScoreUpdate() // These log statements and requests don't run     logger.log("Successfully pushed score update")     await pushHistory(since: since)     logger.log("Successfully pushed history")     waitForMyNetworkRequest.leave() } // Force the system to wait for your network request. waitForMyNetworkRequest.wait(timeout: .now() + 60.0) Also, I'm not even able to read the response from my first request, even though I've confirmed that it hits my server. Here's a sample of my networking code: ... let configuration = URLSessionConfiguration.default configuration.sharedContainerIdentifier = "group.core.data.Present" configuration.isDiscretionary = false         let (data, _) = try await URLSession(configuration: configuration).data(for: request) logger.log("Got response") ... Maybe I'm not setting up the DispatchGroup right to wait for multiple async functions? Or maybe it's the way I'm configuring my URLSession that automatically exits the dispatch group? It appears that I've made progress in being able to send the initial request, but the extension is still terminating before I'm able to read the response.

I'm having this same issue within a TabView - was a bug ever filed or a solution found?

Having the exact same issue in the sandbox

I'm storing timestamps of certain screen time thresholds with DeviceActivityMonitor. Whether or not this is its intended use, something is still off. DeviceActivityMonitor is part of an app extension that is invoked and terminated by the system. Once its functions return, the extension is immediately terminated, meaning there may be data in UserDefaults that never gets persisted. The also docs don't say it's a no-op just that it's "unnecessary" - but maybe it's necessary inside an app extension?

Additionally, this issue seems to occur much less often for my device using a developer-signed build. But for my users it seems to be very common, and get worse over time the longer they have the same version of the app. Could this be related to the problem - maybe a developer device, or a more recent build has some extra priority?

Attached is a crash report from the user. Looks like the app is terminated by the system because it's not able launch to in the allotted time allowed by the system. The stack trace includes FamilyControls waiting for a reply from an XPC connection. FamilyControls is the framework that gives the app access to screen time. So it looks like the app is not able to get Screen Time access, and is never able to launch. Screentox-2023-09-25-145504.ips

Here's the stack trace: Incident Identifier: 6C0573D4-F450-4A78-B38E-C7E6CF50ADAD CrashReporter Key: 80a1fd48b3726682cb61f1a1601274c8db219668 Hardware Model: iPhone14,3 Process: Screentox [424] Path: /private/var/containers/Bundle/Application/43D2455A-475E-493F-A572-C6FACF0C970F/Screentox.app/Screentox Identifier: com.getpresentapp.Present Version: 0.16.9 (1) AppStoreTools: 15A240a AppVariant: 1:iPhone14,3:16 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.getpresentapp.Present [633] Date/Time: 2023-09-25 14:55:04.0676 -0400 Launch Time: 2023-09-25 14:54:44.0389 -0400 OS Version: iPhone OS 17.0.1 (21A340) Release Type: User Baseband Version: 3.06.01 Report Version: 104 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:process-launch watchdog transgression: app<com.getpresentapp.Present(ACC88C7D-C780-43BD-8673-FD53A5E00BEA)>:424 exhausted real (wall clock) time allowance of 20.00 seconds ProcessVisibility: Foreground ProcessState: Running WatchdogEvent: process-launch WatchdogVisibility: Foreground WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 88.660 (user 65.380, system 23.280), 74% CPU", "Elapsed application CPU time (seconds): 0.050, 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 0x1fd2401d8 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1fd23ff70 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1fd23fe88 mach_msg_overwrite + 436 3 libsystem_kernel.dylib 0x1fd23fcc8 mach_msg + 24 4 libdispatch.dylib 0x1be5adf00 _dispatch_mach_send_and_wait_for_reply + 540 5 libdispatch.dylib 0x1be5ae2a0 dispatch_mach_send_with_result_and_wait_for_reply + 60 6 libxpc.dylib 0x21f8a06d0 xpc_connection_send_message_with_reply_sync + 264 7 Foundation 0x1b56396c0 __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ + 16 8 Foundation 0x1b56213bc -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2160 9 Foundation 0x1b564c6cc -[NSXPCConnection _sendSelector:withProxy:arg1:] + 116 10 Foundation 0x1b564c604 _NSXPCDistantObjectSimpleMessageSend1 + 60 11 FamilyControls 0x21de515a8 0x21de16000 + 243112 12 FamilyControls 0x21de50848 0x21de16000 + 239688 13 libdispatch.dylib 0x1be593300 _dispatch_client_callout + 20 14 libdispatch.dylib 0x1be594b3c _dispatch_once_callout + 32 15 FamilyControls 0x21de50a50 0x21de16000 + 240208 16 Screentox 0x1006ca3a8 0x10056c000 + 1434536 17 SwiftUI 0x1bb0ec424 0x1ba322000 + 14459940 18 Screentox 0x100573214 0x10056c000 + 29204 19 dyld 0x1d8e7fd44 start + 2104 Thread 1: 0 libsystem_pthread.dylib 0x21f84e9fc start_wqthread + 0 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000010004005 x1: 0x000000040700420e x2: 0x0000000000000000 x3: 0x0000000000001903 x4: 0x0000000000000000 x5: 0x00000b0300000000 x6: 0x0000000000004000 x7: 0x0000000000000000 x8: 0xfffffffffffffbbf x9: 0x0000000000000b03 x10: 0x0000000000000000 x11: 0x0000000000000001 x12: 0x0000000000000b03 x13: 0x0000000000000b03 x14: 0x0000000000100231 x15: 0x0000000000000001 x16: 0xffffffffffffffd1 x17: 0x0000000207da1240 x18: 0x0000000000000000 x19: 0x0000000000000000 x20: 0x0000000000004000 x21: 0x00000b0300000000 x22: 0x0000000000000000 x23: 0x0000000000001903 x24: 0x000000016f88e640 x25: 0x0000000000000000 x26: 0x000000040700420e x27: 0x000000040700420e x28: 0x000000000700420e fp: 0x000000016f88e4f0 lr: 0x00000001fd23ff70 sp: 0x000000016f88e4a0 pc: 0x00000001fd2401d8 cpsr: 0x00001000 far: 0x000000020d18ef90 esr: 0x56000080 Address size fault Binary Images: 0x10056c000 - 0x100cdbfff Screentox arm64 <5057c7ee92153fca873a4796b8254ee4> /private/var/containers/Bundle/Application/43D2455A-475E-493F-A572-C6FACF0C970F/Screentox.app/Screentox 0x1fd23f000 - 0x1fd277fff libsystem_kernel.dylib arm64e <86430e99b05536efb35ea547a63dc03f> /usr/lib/system/libsystem_kernel.dylib 0x1be58f000 - 0x1be5d5fff libdispatch.dylib arm64e <149ff9cd3e92321db92fef58717c70b6> /usr/lib/system/libdispatch.dylib 0x21f890000 - 0x21f8d4fff libxpc.dylib arm64e <8e13493aac3e3eef8b3e102a3d715b23> /usr/lib/system/libxpc.dylib 0x1b5600000 - 0x1b616afff Foundation arm64e <60f744f41345325e8970d37bb5a1a31d> /System/Library/Frameworks/Foundation.framework/Foundation 0x21de16000 - 0x21de63ff2 FamilyControls arm64e <3064b22ed47e379c960cf39982bb1982> /System/Library/Frameworks/FamilyControls.framework/FamilyControls 0x1ba322000 - 0x1bc1fdfff SwiftUI arm64e <7bbaf70522f73edc9a764c8c1730188c> /System/Library/Frameworks/SwiftUI.framework/SwiftUI 0x1d8e7a000 - 0x1d8f0109f dyld arm64e <c8bdb7d45c573429b5bf707b7cc0f494> /usr/lib/dyld 0x0 - 0xffffffffffffffff ??? unknown-arch <00000000000000000000000000000000> ??? 0x21f84d000 - 0x21f858ff3 libsystem_pthread.dylib arm64e <2ef84a6982123e06ac6df9a9e43d87f6> /usr/lib/system/libsystem_pthread.dylib

It's possible that the function fails before it returns and is retried. Does anyone know the retry policy for DeviceActivityMonitor override functions?

@_lilpit , @thomas_maht - have Opal and Jomo implemented any special tricks / hacks to improve the performance of DeviceActivityReport - your apps display screen time especially well on my device.

This issue seems to be getting worse with each new iOS 17 release. From my debugging, it appears that certain activities like reading / writing to User Defaults, sending analytics events, etc cause the callback functions to terminate early. However the issue is still intermittent. Would love to hear other developers' experience with this issue.

Also having the exact same problem.

I'm experiencing the exact same issue. Seems to have been introduced in iOS 17.5.1