Why not just move your logic that apply shielding into the monitor extension ? I believe the darwin notification is working only when the app is running, and the monitor extension will not wakeup your app if it's not running. In debug mode, application stay in the running state much longer, but not in release mode, app are suspended as soon as a user background them (if not playing audio or using gps).

Hi everyone ! Apple just announced that Xcode 15 will be mandatory to publish app updates starting April 2024 (https://developer.apple.com/ios/submit/) This is making this bug critical as we will have to drop iOS 16 if we want to update our apps containing DeviceActivityReport.

Hey ! This is due to the fact that those views are rendered of process, you need to assign a fixed size to your view, and cannot assign a background color. We opened a bug report for those exact things a while ago but didn't get any answers (FB10819848 (DeviceActivityReportScene doesn't behave like a regular SwiftUI view in an undocumented way), opened 06/22/22) I invite you to open a bug report as well ! Regards

Hey ! We already opened a thread subject for this -> https://developer.apple.com/forums/thread/735915 I invite you to open a bug report so the issue has more chance to be fixed ! The workaround for now is to continue using Xcode 14 to publish your app, this issue only happens when you build with Xcode 15. Regards :)

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

Hi ! we already posted on this issue here -> https://developer.apple.com/forums/thread/735915 can you open a radar as well ?

Would love a solution here as well ! I have to disconnect my iPhone from the wifi if I want to debug, because even if plugged, debugging seems to prioritize network over usb. It also seems to slow down all my network connections on my phone which is a bummer. I observed a clear regression from beta 8, it was way faster on the prior iOS 17 / Xcode 15 betas.

Hey ! We encounter similar issues in the past, and didn't find any proper documented way to monitor the DeviceActivityReport extension state, or to prevent crashes from happening. You can provide a way for your user to reload the view himself in case of crash using regular SwiftUI methods. We've opened several radars, some of them more than a year ago, without any answer at the moment. I would suggest you to do the same, the more they are, the more likely they'll fix it ! Regards !

Hey ! Accessing AuthorizationCenter.shared is sometime hangging, blocking the thread on wish it was called. We've opened a bug report for this (FB11833456), and would be super nice if you could do the same, so this issue has more chance to be fixed ! The crash is not really a crash, since you do the call on the main thread at your app start, it's delaying your appLaunch. IOS has a mechanism called the Watchdog that kills app that take too long to launch, this is what's happening in your case.

hey ! We opened a radar for this a while ago, but it seems to have been fixed on iOS 16.4, are you testing on an iOS 16.4+ device ?

Hey ! Granting screentime authorization doesn't work on the simulator, only on real devices. You cannot really test the screentime apis on a simulator, but you can add #if targetEnvironment(simulator) checks if you need to other parts of your app.

We experience the same issue on our app, and we filled a bug report as well -> FB12235755. The issue seems to happen when screentime permission have been granted prior to iOS 17. In our testing, everything based on DeviceActivityReport fails to render until you reinstall the app. here's what we see in the logs: Failed to discover the client's extension: Error Domain=DeviceActivityReportService.ReportViewController.ClientError Code=2 "(null)" VS terminated with error: Error Domain=_UIViewServiceErrorDomain Code=1 "(null)" UserInfo={Terminated=disconnect method} I agree this is a big concern for us as well, we don't want to ask all of our users to reinstall the app after updating to iOS 17. This is also showing how little control we have on DeviceActivityReport views, we cannot know if they are loading, if they errored with the public API, we opened a enhancement radar on this about a year ago (FB10754858).

yay the limit is 49 domains / 49 apps, if you cross it, it just stops blocking. This limit is not documented. We reported the issue in June last year -> FB10511690. Can you do the same to help getting this issue fixed ?

Definitely working for us with the individual permission ! did you try to repro your issue in a sample project ?

Hey ! We experience the same issue, we created an improvement bug report for it, you could do the same to increase chances it's being looked at : FB10754858 -> Provide a way to monitor data loading / error states on DeviceActivityReportScene