Critical Bug in Screen Time Frameworks – User's Phone Rendered Unusable

Hello Apple Developer Community,

We're experiencing a critical issue with the Screen Time frameworks, and it's affecting one of our users severely. I'm hoping someone here can provide guidance or a potential solution.

Details:

  • Our app offers a feature using the ManagedSettings shield that lets users block all apps based on a set schedule.
  • After the scheduled block ends, the apps are expected to become accessible again.
  • In one case, a user reported that the apps did not unblock after the schedule ended.
  • Upon trying to manually end the session from within our app, the app only displays a blank white screen.
  • The user attempted to disable Screen Time access for our app via the iOS settings, but the apps remained blocked.
  • Even after completely disabling Screen Time from the settings or restarting the phone, the apps stayed blocked.

Interestingly, I attempted to replicate the issue on my end by toggling Screen Time settings and restarting, but everything worked as expected and I could not reproduce the problem.

This issue, though seemingly isolated, has rendered a user's phone virtually unusable, and highlights a potential high-impact bug within the Screen Time framework. It feels necessary for there to be a "master off-switch" or a fail-safe mechanism in these scenarios.

Any insights, solutions, or workarounds would be deeply appreciated. It's crucial for us to support our user and resolve this promptly.

Thank you in advance!

Post not yet marked as solved Up vote post of charleswinston Down vote post of charleswinston
1.2k views
Posted by
charleswinston
Reply
Add a Comment

Replies

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
Posted by
charleswinston
Up vote reply of charleswinston Down vote reply of charleswinston
Add a Comment

Given how critical it is for your user, I would advise you to use a DTS ticket. And provide much more code to support so that they can investigate.

Posted by
Claude31
Up vote reply of Claude31 Down vote reply of Claude31
Add a Comment

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
Posted by
charleswinston
Up vote reply of charleswinston Down vote reply of charleswinston
Add a Comment

Which version of iOS ? (see this thread : https://developer.apple.com/forums/thread/690574)

Do you make network call in at app startup ?

Posted by
Claude31
Up vote reply of Claude31 Down vote reply of Claude31
Add a Comment

Hi Charles,

I would recommend you start with a bug report via Feedback Assistant. It sounds like you have a line of communication with this user, so I'd suggest you perform the additional steps:

  1. Have the user run your app and try to remove the shielding. (That is, recreate the issue.)

  2. If necessary have the user record the date and time of the attempt. (If there's a crash or other log that includes a timestamp, at the time of the attempt, that will work,, or just have the user write down the current date and time as accurately as possible.)

  3. Have the user capture a sysdiagnose from their device and send it to you.

  4. Upload the sysdiagnose (along with the timestamp) to your bug report.

  5. Post the feedback number (FBxxxxxxxxx) here.

If you also want to open a TSI incident as Claude suggested, that would be fine too, but the initial steps would be to create the bug report with sysdiagnose anyway.

Posted by
Polyphonic
Up vote reply of Polyphonic Down vote reply of Polyphonic
Add a Comment

Hello, We also got multiple reports of this issue from our users, and we found a workaround:

  • Ask the user to reinstall the app,
  • Grant screentime permissions
  • Start shielding the apps that are stucked
  • Stop shielding them

It seems to allow the app to unblock from user devices.

In our experience, this issue seems to be related to an issue we reported were the Screentime authorisation is hanging, and just accessing the authorisation center is blocking everything. Even the screentime section in settings is not accessible.

Here the bug report : https://feedbackassistant.apple.com/feedback/11833456 opened about a year ago. We got some devices were this issue is present all the time, this issue seems to propagate through icloud, and also causing mal function in DeviceActivity extension based views.

We are glad this got Apple attention because it seems to be major issue that make our users very mad.

Regards

Posted by
_lilpit
Post not yet marked as solved Up vote reply of _lilpit Down vote reply of _lilpit

  • Yes, reinstalling the app and granting the permissions again worked for us as well. We're still facing this issue after 6 months, which means the issue is still persistent in newer versions of iOS.

    —
    therealgeekfruit
Add a Comment

Hi Charles,

What is the feedback number of your bug report? The sysdiagnose is a crucial component for investigation of what's gone wrong.

Posted by
Polyphonic
Up vote reply of Polyphonic Down vote reply of Polyphonic
Add a Comment

I've had this similar issue and made a bug report with a sample project replicating the same issue. FB13492170

Posted by
startover205
Up vote reply of startover205 Down vote reply of startover205
Add a Comment