Can an internal dev please address this issue in some way? It was introduced in later versions of iOS 17, still happening in latest version of iOS 18, and many other devs have reported the same issue. This is a core problem with the Screen Time API that should be addressed as it renders the monitoring schedule fundamentally unusable for affected users. Would really appreciate some kind of response from the internal devs, thanks!

Another Update: for many users, turning off Screen Time completely on their other iOS devices has fixed the issue for them (while "Share Across Devices" was still always turned off). Still for some users, this has not fixed it. And for other users, they never had other iOS devices to begin with but they were still experiencing the issue. So I would assume that this issue has something to do with screen time being shared incorrectly across devices, but still can be experienced without other iOS devices sharing screen time. Also this issue is still happening on iOS 18.

Update: I've noticed that part of the issue is it seems to be "double counting" usage from Safari. As stated in the previous comment, the events target only category tokens, and not specific app or website tokens. Using the website x.com on Safari for 10 minutes caused the event threshold to fire 10 minutes early - so my hunch is it is counting Safari and the website x.com separately. However, this is likely NOT the only thing that causes the overcounting, since users experience thresholds showing much higher screen time than can be only explained by their Safari usage. But I think this info can help point toward the root cause. Also have submitted a bug report: https://feedbackassistant.apple.com/feedback/15103784

Maybe some more relevant information: all DeviceActivityEvents are defined by tracking categories, not apps or websites. Here is an example of one of the events: DeviceActivityEvent(categories: categories, threshold: DateComponents(hour: 2, minute: 30), includesPastActivity: true)

What are you doing in the DeviceActivityMonitor callback functions?

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

Also having the exact same problem.

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.

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

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

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

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

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?

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?

Having the exact same issue in the sandbox