Hey ! This is prohbited for privacy reasons, the DeviceActivityExtension can only read from the shared app group, but cannot write. You can write inside the extension sandbox, but those won't be readable by the main application.

We observed the same behavior with iOS 18.4, it's also impacting modally presented UIKit UIHostingController presenting a FamilyAcitivityPicker, they are dismissed alongside the FamilyPicker.

Hey ! This is by design, you cannot access app names or bundle identifier outside of the ActivityReport or shield extension sandbox for privacy reasons, you can only store and send opaque tokens in your app, not the actual apps.

Hey, the issue was already described here -> https://developer.apple.com/forums/thread/764457 And some workarounds were mentioned :) In the mean time, would be nice If you could open a bug report, the more there are, the most likely apple will fix it ! Regards

Hey, the issue was already described here -> https://developer.apple.com/forums/thread/764457 And some workarounds were mentioned :) In the mean time, would be nice If you could open a bug report, the more there are, the most likely apple will fix it ! Regards

Hey ! We opened an Apple bug report for this exact issue 2 years ago with id FB11400221, can you open a report yourself to get this fixed by apple ? We have a lot of user reports about it, and we didn't find a workaround. We found a way to detect the crash though, and we show am explanation dialog when it happens.

Hey, To my knowledge, you cannot create Tokens from bundle ID, only get them from the FamilyActivitiyPicker. I can also confirm that tokens are not portable across devices, an Instagram token on device A is not the same as on device B, using it to block apps will just do nothing on device B. I'm almost certain you cannot achieve what you are trying to do with the current set of APIs provided by Apple. I believe this is behaving as designed by apple for privacy reasons. Good luck !

We had multiple reports of this exact issue as well from Opal users, we didn't open a bug report because we weren't able to reproduce the issue on our own devices 😢

I concur ! This would make perfect sense. We also opened a radar for it -> https://feedbackassistant.apple.com/feedback/14051075

Hello ! Yay we noticed a similar behaviour, and added it to our FAQs. I invite you to open an Apple bug report if you can, to increase chances this issue could be fixed ! We opened one in .... november 2022 🫣 (FB11799302) you can reference it in your bug report. Regards !

Hey ! the answer is no, finegrain data is sandboxed for privacy purposes, and can only be displayed in views, but without letting you access it in your app

Hey ! I invite you to open a bug report if you can, mentioning FB11400221 ... we opened it almost 2 years ago with no answers ^^' There is no official way to detect the crash and reload the view, but you can do it using side roads like introspection Good luck !

Here's Apple answer to the DTS, basically we don't care, manage the problem yourself : According to the latest update in Feedback ID #FB12416769, the reported problem will not be fixed in iOS 16. We recommend that your company takes whatever steps it can to have the remainder of the App user base update to iOS 17 or higher.

I have a sad news for you guys, I've got an answer on my radar following my DTS, this issue won't be fixed. No answer yet on the DTS itself yet

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).