The issue persists when compiling on an iOS 16 device using Xcode 15.0 RC 1 (15A240d). This is incredibly frustrating because the public release of iOS 17 is imminent. Currently, we cannot submit builds that take advantage of the new features in iOS 17 without compromising the experience for a significant portion of our user base—until a majority of our users upgrade to iOS 17. For developers reading this thread: I invite you to file a bug report to Apple using the Feedback Assistant app and to upvote this thread massively. For anyone working on or related to the Screen Time API frameworks: Could you please provide us with an update on this situation? Thank you.

The issue still arises when compiling on an iOS 16 device with Xcode 15.0 beta 8 (15A5229m).

Have you tried to toggle off/on the screen time permission? You could also try a force restart. Tell me if that works.

Take a look at this: https://developer.apple.com/documentation/managedsettings/webcontentsettings/filterpolicy

What time range would you like? Your best bet would be to use a segment interval set to .hourly. This way, you can obtain hourly segments of screen time data on the interval of your choice. Unfortunately, you won't be able to get anything more precise than this.

You won't be able to do that. Your Device Activity Report extension runs in a sandboxed environment to protect user privacy. As stated in the documentation, "this sandbox prevents your extension from making network requests or moving sensitive content outside the extension’s address space". What this means is that even if you place your Core Data database in an app group container that is shared between your app and extension, you won't be able to write anything to it from the extension. You might be able to read from it, though I have never tried this with Core Data.

@Kmart @eskimo Any help on this will be appreciated :)

We have also filed a bug report (FB13056211) for the exact same issue. This is a MAJOR problem for all apps using DeviceActivityReport views. We hope it's going to be fixed in time for the iOS 17 official release!

No, it seems to be the limit for now and there is no way to increase it as far as I know. You can file an enhancement report for this.

Good question! According to the documentation, "FamilyActivitySelection provides tokens that devices within the same Family Sharing group can use to identify applications.". There is a good chance that tokens might be shared between different devices. I guess you can try this fairly easily by saving a token to a JSON file on one of your devices then trying to decode it on another device. Let me know if that works!

Seeing the same issue and will file a bug report too! @atalayasa Try to move your access to AuthorizationCenter.shared outside the main thread. That shouldn't be too problematic apart from from manipulating authorizationstatus which, according to the documentation, should only be accessed on the main thread.

You cannot initialize an ActivityCategoryToken directly. Instead, you must utilize the FamilyActivityPicker and obtain your category tokens via a FamilyActivitySelection. The example you provided is misleading for several reasons: The ellipsis "..." likely implies that the developer needs to figure out the implementation. However, this approach is problematic since it's not feasible to generate an ActivityCategoryToken from scratch. One must either retrieve it through a FamilyActivitySelection or decode it from a Data object. There's no method to determine if the ActivityCategoryToken instance you are dealing with belongs to the "Social" category. The only workaround would involve prompting the user to select the "Social" category in the FamilyActivityPicker and... trust him or her to do so.

No, you can't get that information from an ApplicationToken or through the Family Controls or Managed Settings frameworks. The only workaround I can think of is to find a way to ask your user to identify the ApplicationToken he or she just selected through the FamilyActivityPicker. If your user says he or she selected TikTok for example, you can "easily" find the matching url scheme － you will have to build your own custom list for those though.

Same issue here + displaying these labels can lead to severe hangs, basically making them unusable in production. These bugs have been around for months now.

Has anyone tested this on iOS 17? Was it fixed?