General: Forums topic: Family Controls Forums tag: Family Controls Configuring Family Controls documentation Requesting the Family Controls entitlement documentation Screen Time Technology Frameworks documentation FamilyControls documentation What's new in Screen Time API video Meet the Screen Time API video

App Store Connect returns the following message when the NSExtensionPointIdentifier key in the Info.plist of a Device Activity Monitor extension contains an invalid value: ITMS-90349: Invalid Info.plist value - The value of the NSExtensionPointIdentifier key, <value>, in the Info.plist of ".../PlugIns/...appex" is invalid. To resolve this issue, set NSExtensionPointIdentifier to com.apple.deviceactivity.monitor-extension. The expected Info.plist structure for a Device Activity Monitor extension is: <plist version="1.0"> <dict> <key>NSExtension</key> <dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.deviceactivity.monitor-extension</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).DeviceActivityMonitorExtension</string> </dict> </dict> </plist> After you apply this fix, build and archive your app, then re-upload to App Store Connect to confirm the error is resolved.

Title: Screen Time displaying unresolved app entry — blank icon, no developer/category metadata, not present in iPhone Storage, persists after factory reset Device/OS: iPhone 16 Plus / iOS 26 (latest) Description: Screen Time is showing daily usage for an app entry with no resolvable identity: • Icon: blank/wireframe placeholder (does not render) • Category: “Other” • Age Rating: “No Rating” • Developer: listed as “Apple” (appears to be a fallback default, not accurate) • Daily usage: ~2 minutes total, averaging 34s/day, logged in short discrete intervals (e.g. 38s from 10–11AM, 1 min from 11AM–12PM, 1 min 12PM–1PM) Steps taken to rule out causes: 1. Checked Settings → General → iPhone Storage — this app/entry does not appear anywhere in the installed apps list. 2. Checked Screen Time → Add Limit → Categories, Apps, and Websites → Edit List — entry still shows with blank icon and no name text. 3. Set a 1hr/day limit with “Block at End of Limit” enabled — the block does not appear to enforce. 4. Confirmed the entry does not appear under Mac or Apple Watch Screen Time activity — only on iPhone. 5. Performed a full factory reset with no backup restore (clean setup) — the entry still appeared with new activity the following day, ruling out leftover local data from before the reset. 6. Confirmed fresh activity is still being logged day-to-day, ruling out a stale/orphaned record from a previously deleted app. Expected behavior: Screen Time should either resolve the app’s real name/icon/developer from its bundle metadata, or if the entry has no corresponding installed app, it should not continue generating new daily usage intervals with an unresolvable identity. Actual behavior: Persistent unidentified usage entry with no way to determine which process is generating it, and App Limits set against it do not appear to block anything. Impact: Cannot identify what is generating this usage, cannot verify Screen Time limits are functioning against it, and cannot rule out it being tied to a background process/extension not visible through standard iOS UI. Related known issues: This may be conn

I'm building a consumer iOS app that helps users be more intentional about opening distracting apps. It never hard-blocks; it only nudges. I have Family Controls (Distribution) approved and a working TestFlight build using FamilyControls / DeviceActivity / ManagedSettings. I've confirmed from testing and the forums that: ShieldActionResponse is only .none / .defer / .close (no supported way to open my main app from the shield extension — threads 719905, 793060). ShieldConfiguration is a static snapshot (no countdown/animation; FB14237883). DeviceActivityMonitor events are threshold/schedule based and cannot hook "the app was just opened," and on iOS 26 eventDidReachThreshold fires immediately/incorrectly (thread 808470). I'd like to confirm the supported approaches for these UX patterns (each = every-app-open vs on-a-schedule): On app open, present my own full-screen UI (a brief non-blocking "pause") without requiring the user to manually create a Shortcuts personal automation. Is there any supported API for this, or is a user-created Shortcuts automation the officially recommended path? On app open, deliver a local notification (rather than UI) — supported only via a user-created Shortcuts automation, or is there another way? On a schedule / at fixed intervals, automatically bring my app's UI to the foreground (e.g., re-show a screen every N minutes) — I believe this is not allowed (apps can't self-foreground); can you confirm, and is a user-tapped notification the only path? On a schedule / at fixed intervals, send repeating local notifications while a usage limit is exceeded — given the iOS 26 eventDidReachThreshold regression, what's the recommended way to reliably detect "over limit" and drive repeating reminders? Some third-party apps appear to open their main app from a shield/monitor context. Is there any supported mechanism enabling that which I may have missed? I'd rather build on a supported path than risk anything review-sensitive. Guidance (or where to file an enhancement request) is appreciated. Thank you.

On iOS 26.4, I set a Screen Time passcode. However, when I go to Settings > Apps > [Our App] and turn off Screen Time Access for the app, the system asks for Face ID instead of the Screen Time passcode. As a result, Screen Time access can be disabled without entering the Screen Time passcode. Steps to Reproduce 1. Set a Screen Time passcode on iOS 26.4. 2. Open Settings > Apps > [Our App]. 3. Turn off Screen Time Access for the app. Expected Result The system should require the Screen Time passcode before allowing Screen Time access to be disabled. Actual Result The system asks for Face ID instead of the Screen Time passcode, and Screen Time access is disabled.

Hi everyone, I am currently working on a specialized analytics and time-tracking application, and I am trying to find a reliable way to detect which app the user currently has open in the foreground in real-time. On Android, this is typically handled via Accessibility Services or UsageStats, but I am well aware of iOS’s strict sandboxing rules and privacy protections. So far, I have researched and tested a few workarounds, but none perfectly fit the use case: Screen Time API (FamilyControls / DeviceActivity): This is fantastic for blocking apps or getting daily aggregate usage, but it does not provide real-time callbacks or the bundle ID of the app currently on the screen. MDM (Mobile Device Management): Requires enterprise enrollment and wiping the device, which isn't feasible for a consumer-facing app. ReplayKit (Broadcast Extension): We are currently utilizing RPBroadcastSampleHandler to screen record the device and using OCR and Core ML to visually identify the app (e.g., detecting the YouTube UI). However, this is incredibly resource-intensive and pushes the 50MB Jetsam limit for extensions. My Question: Is there any official API, restricted entitlement, or system notification (like NSWorkspace.shared.frontmostApplication on macOS) that allows a background process to simply read the bundleID of the active foreground app on iOS? If not, is ReplayKit combined with OCR or Machine Learning truly the only way to detect what app a user is actively viewing on iOS without a jailbreak? Thank you in advance for any insights!

Hi, I’m using FamilyControls + DeviceActivity. Users select apps/categories/web domains via FamilyActivitySelection. I need to show today’s total usage for that selected group only, not the device’s full Screen Time. Setup: A visible DeviceActivityReport shows today’s per-app list with a daily DeviceActivityFilter for the selected tokens. This visible list is usually accurate and updates quickly. A separate hidden DeviceActivityReport uses the same filter to compute an aggregate total by summing app.totalActivityDuration in makeConfiguration(representing:). The extension sends that total to the main app via notify_set_state + Darwin notification. DeviceActivityMonitor is only used as a fallback. Problem: The visible app list stays current, but the aggregate total for the same selected apps sometimes lags by several minutes or updates only after new selected-app usage occurs. Sometimes the total appears temporarily frozen while the app list still looks correct. Questions: Is a hidden DeviceActivityReport a supported way to compute a selected-app aggregate total? Is makeConfiguration expected to run often enough for a near-live total? Why would the visible per-app report update while a hidden report with the same filter does not? What is the recommended architecture for a reliable, non-inflated today total for selected apps only? Thanks!

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

I am the developer of a screen time awareness app currently on the App Store. It uses the Family Controls and DeviceActivity frameworks, with the distribution entitlement approved, to show users their own cumulative screen time since install. All tracking today is fully on-device and nothing leaves the user's phone. I am planning an optional social feature and I want to confirm Apple's position before building it, because I want to stay clearly within the Developer Program License Agreement, specifically Section 3.3.3(P) regarding data received through the Family Controls framework. Here is how the feature would work: The app monitors the user's own device activity via DeviceActivityMonitor threshold events. This is the same mechanism the app already uses for its on-device counter. On-device, that counter is converted into an abstracted, gamified score. The score is not expressed in hours, minutes, or any unit of time, and the app never displays it as time. If, and only if, the user opts in to the feature, the app uploads a self-chosen username, the date the user's count began, and the user's abstracted score values to my backend. Score values may be computed over different time windows, for example a lifetime score alongside daily, weekly, or monthly scores, but they are all the same abstraction: no raw time totals, no per-app or per-category data, no contacts, and no identifiers beyond what the account itself requires. Friends who have mutually opted in see each other's usernames and scores on a leaderboard. The app never displays another person's screen time, and no time values are stored server-side. The feature is off by default, data is encrypted in transit and at rest, and users can delete their account and all associated data from within the app at any time. The privacy policy will disclose all of this. My question: does transmitting this opt-in, abstracted score, derived on-device from DeviceActivity threshold events, comply with DPLA Section 3.3.3(P) and the intended use of the Family Controls framework? If this specific design is not acceptable, is there any form of opt-in social comparison feature that would be, and what constraints would it need to satisfy? I am aware of earlier threads here where sending screen time data off-device was flagged as non-conforming, which is exactly why I am asking before writing any code rather than after. I would rather design this correctly from the start than risk a rejection later. Thank you for your time. Happy to provide any additional detail about the design.

These days, we live our lives completely surrounded by and immersed in smartphones. It seems there isn't a single person among us who isn't. This is because we can find all kinds of information, meet friends, and enjoy our leisure time on our smartphones. However, there is one thing we are overlooking. It is the emotion you will feel toward the people around you as you die on the day you come to pass away. What is that emotion? It is regret. That regret is likely the longing to enjoy physical intimacy, conversation, travel, and everyday life more. That is why I am developing an app with a special feature. I am developing an app that helps users self-regulate and maintain moderation in their smartphone usage—something we are addicted to and love so much, yet often fail to realize that it is poison. This app is designed to encourage mutual moderation and provide rewards. Ironically, this app is designed to operate on the smartphone itself. The reason is that if the smartphone is a tiger's den, then to catch the tiger, one must enter the tiger's den. While conceptualizing and proceeding with development, I encountered a completely insurmountable wall. This is because the iPhone cannot accurately measure the screen-off time. I earnestly hope that if there is a team or developer working on the iPhone framework, you can resolve this issue. If you can extend the extension or take measures to allow access to that data within the SDK, I believe I will be able to complete this app. I look forward to your help.

Transitions inside ScreenTime Report is not working if phone locked when app is opened. It is starts working only after terminate and open the app.

Hello, I am developing a parental control app using FamilyControls, DeviceActivity, and DeviceActivityReport. My current setup is: The child device requests FamilyControls authorization with .child The parent device requests FamilyControls authorization with .individual The parent app displays reports through a DeviceActivityReportExtension The report filter uses users: .children and devices: .all I would like to clarify two questions: Can a third-party app use the Screen Time API to retrieve or display screen time activity per child or per child device from the parent app? For example: Child A's total screen time today Child A's iPhone screen time today Child A's iPad screen time today At the moment, I can only display an aggregated report using users: .children and devices: .all. I do not see a public API for selecting a specific child or a specific child device. Is this a current limitation of the public Screen Time API, or is there a recommended approach to implement this? Can the Screen Time API report activity data for family members aged 14-17? Specifically, if a family member is between 14 and 17 years old and their device has completed .child authorization, can the parent app still display their Screen Time data using DeviceActivityReport(users: .children)? Or are there restrictions related to Apple ID age, Family Sharing, or Screen Time permissions that prevent third-party apps from retrieving or displaying activity data for users in this age range? My goal is to understand what third-party apps can implement in a compliant way using the public APIs, without attempting to bypass any system limitations. Thank you.

Hello, I want to echo the DeviceActivityReport "concurrency" problems flagged in https://developer.apple.com/forums/thread/720549, and ask a related question. (Thanks to Kmart and other Apple dev support folks who have been monitoring these forums and responding diligently.) I would like to display daily and weekly stats in the same view, broken down by specific apps (as in the native Screen Time). However, instantiating multiple DeviceActivityReport objects with different filters and/or different contexts leads to confusion, where the two views will incorrectly and intermittently swap data or duplicate data where it shouldn't (seemingly upon some interval when the extension provides fresh data). There isn't documentation on how to display multiple reports at once. Is the idea that logic for multiple reports should be embedded within the extension itself in the makeConfiguration() function and there should only be a single DeviceActivityReport in the main App, or is this a bug? Even with a single DeviceActivityReport, I run into inconsistencies where the View provided by the extension takes multiple seconds to load or fails to load altogether. The behavior seems random...I will build the application with the same code multiple times and see different behavior each time. Finally, a plug for better support in the Simulator for the entire set of Screen Time APIs. Thanks!

I'm building a cross-device parental-control app: separate child and parent devices in the same Family Sharing group. I want to show the child's per-app (and per-category) Screen Time usage on the parent device. After extensive testing I can only get the child's total minutes across, and I'd like to confirm the supported architecture before building further on a path the framework may intentionally forbid. Authorization / setup Child device: AuthorizationCenter.shared.requestAuthorization(for: .child) — approved. Confirmed authorized: my app appears under Settings → Screen Time on the child, and the child's own DeviceActivityReport(users: .all) renders full per-app data. Parent device: separate device in the same family. Targets: main app + DeviceActivityReport extension + DeviceActivityMonitor extension, all with com.apple.developer.family-controls and a shared App Group. Physical devices, iOS 26.4.1. Xcode ⟦version⟧. What works: only the child's total minutes reach the parent — and only via my own relay: a DeviceActivityMonitor extension on the child writes aggregate totals to the App Group, the host app syncs them through CloudKit. No Screen Time API itself delivers the child's app/category breakdown to the parent. ⸻ Finding 1 — the report extension computes correct per-app data but cannot export it. On the child, makeConfiguration(representing:) iterates the results and produces correct per-app durations: LumicoActivityReport makeConfiguration done — 1 activityData, 1 segments, 5 apps, 17 min total Writing those aggregates to the shared App Group from inside the extension is then denied by the sandbox: Couldn't write values for keys ("screen_time_per_app_json") in CFPrefsPlistSource (Domain: group.servusjon.Lumico.shared …): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access (UserDefaults.set doesn't throw — the write silently no-ops; only this CFPrefs log reveals the denial.) Q1: Is there any supported way to surface aggregated, non-identifying per-app usage (app name + minutes + category) computed inside the DeviceActivityReport extension to the host app, given that App Group writes from the extension are denied? Or is the DeviceActivityMonitor extension (threshold events) the only supported way to get any usage signal out of the Screen Time sandbox? Finding 2 — on the parent, users: .children shows the parent's OWN data. On the parent I embed DeviceActivityReport(_:filter:) with DeviceActivityFilter(users: .children, …). The report renders, but shows the parent's own apps/categories — no child data. FamilyActivityPicker on the parent behaves the same (lists the parent's own apps). The identical code on the child (users: .all) returns the child's full data — so the pipeline works; only the cross-device delivery to the parent fails. Q2: What is required for DeviceActivityReport(users: .children) to deliver a child's activity to a third-party app on the parent device? Must the parent app hold a specific FamilyControls authorization (which FamilyControlsMember)? What conditions make FamilyActivityPicker surface a child's apps (not just categories) from the family on the parent device — authorization type, Family Sharing roles, child managed status, sync timing? ⸻ Already ruled out: physical devices (not Simulator); Screen Time data present on the child; extension correctly embedded (ExtensionKit com.apple.deviceactivityui.report-extension) and running makeConfiguration normally; family-controls + App Group present on app and both extensions; iCloud container named conventionally iCloud.. Core question: What is the supported architecture for showing a child's per-app usage on a parent's device in a third-party app? I want to build on the sanctioned path rather than a workaround. Thanks!

I am currently experiencing a bug where everyday at 5:30pm I have to manually go into Settings and turn off Screen Time's Downtime because it automatically locks me out of almost all of my apps. I am not able to toggle the "Scheduled" option, preventing me from editing Downtime. Is there any improvements with iOS27 that will be able to fix this bug? The goal is to not use Downtime anymore (aka it is not scheduled).

Dear Screen Time Team! The current 6 MB memory limit for the DeviceActivityMonitor extension no longer reflects the reality of modern iOS devices or the complexity of apps built on top of the Screen Time framework. When Screen Time APIs were introduced with iOS 15, hardware constraints were very different. Since then, iPhone performance and available RAM have increased significantly…but the extension memory limit has remained unchanged. My name is Frederik Riedel, and I’m the developer of the screen time app “one sec.” Our app relies heavily on FamilyControls, ManagedSettings, and DeviceActivity to provide real-time interventions that help users reduce social media usage. In practice, the 6 MB limit has become a critical bottleneck: The DeviceActivityMonitor extension frequently crashes due to memory pressure, often unpredictably. Even highly optimized implementations struggle to stay within this constraint when using Swift and multiple ManagedSettings stores. The limit makes it disproportionately difficult to build stable, maintainable, and scalable architectures on top of these frameworks. This is not just an edge case…it directly impacts reliability in production apps that depend on Screen Time APIs for core functionality. Modern system integrations like Screen Time are incredibly powerful, but they also require a reasonable amount of memory headroom to function reliably. The current limit forces developers into fragile workarounds and undermines the robustness of apps that aim to improve users’ digital wellbeing. We would greatly appreciate if you could revisit and update this restriction to better align with today’s device capabilities and developer needs. Thank you for your continued work on Screen Time and for supporting developers building meaningful experiences on top of it. Feedback: FB22279215 Best regards, Frederik Riedel (one sec app)

Dear Developer Technical Support, I wanted to ask for technical advice regarding the DeviceActivityMonitor which is part of the DeviceActivity framework: The DeviceActivityMonitor has a very strict memory limit of 6MB. That’s not a lot and it doesn't leave a lot of room for any kind of code that accesses permanently stored data. I would therefore like to ask for advice on best-practices on how to share information between the main app and that extension: Is UserDefaults a good idea to use here? Can/should we use CoreData or SwiftData? Should we build super small file-based data sharing (e.g. via .plists)? Why is it necessary to share data? This can be simple things that inform the decision of the device activity monitor in intervalDidStart, intervalDidEnd, eventDidReachThreshold, eventWillReachThresholdWarning. For example a setting where the user decides if they want to receive a push notification on eventWillReachThresholdWarning. Or the list of tokens that is supposed to be blocked in eventDidReachThreshold or intervalDidStart. I’m asking because even though we are super careful and conservative about memory allocations in our DeviceActivityMonitor we are regularly seeing it being killed due to memory pressure. What’s the best way to approach this? I’m grateful for any kinds of hints! Thanks a lot and have a great day! – Frederik

Hi everyone, I’m the developer of one sec, an app used by a large number of users globally to reduce time spent on social media and to build healthier digital habits. Because of this, we rely heavily on Apple’s Screen Time / DeviceActivity / FamilyControls, ManagedSettings APIs – and unfortunately, we’re seeing increasingly severe issues in production that directly impact hundreds of thousands of real iOS users. During the past years, we have been busy filing dozens of feedback requests for different Screen Time issues – and there has been no response from Apple at all. Developer Relations might be able to "confirm" that the bugs are present and that they ended up with the right team – but they are never addressed, neither are workarounds provided. Instead, the situation gets worse and worse. iOS 26 introduced a series of heavy regressions (which have been reported via Apple’s official bug report tool "Feedback Assistant" on iOS 26 beta 1 in June 2025 – and have not been addressed 10 Months later). This is very frustrating for us as developers, but also for our end-users who run into these issues every day. In the end this impacts our ability to build an amazing product and hurts revenue (which affects both us and Apple). 1. DeviceActivity thresholds are not firing at all This affects both: our app’s usage of the API and Apple’s own Screen Time limits Radars: FB22304617, FB20526837, FB15491936, FB12195437, FB15663329, FB18198691, FB18289475, FB19827144 2. Screen Time usage data is clearly corrupted Websites showing hundreds of hours per week Up to ~20 hours per day of usage reported for a single domain Radars: FB22304617, FB17777429, FB18464235 3. DeviceActivity thresholds reaching threshold immediately Newly introduced with iOS 26 Reported on iOS 26 beta 1 in June No response so far / no workaround DeviceActivity calls didReachThreshold immediately after creating the DeviceActivityEvent – instead of waiting till the defined threshold is actually reached. Radars: FB13696022, FB18351583, FB21320644, FB18927456, FB18061981 4. Randomly Randomizing ApplicationTokens From time to time, and without consistency, Screen Time suddenly provides new, random, unknown tokens to my app in the ShieldConfigurationDataSource and ShieldActionDelegate. This has been reported on many times before here on the dev forms, many many years back already: https://forums.developer.apple.com/forums/thread/756440 https://forums.developer.apple.com/forums/thread/758325 https://forums.developer.apple.com/forums/thread/758325?answerId=793267022#793267022 Radars: FB14082790 and FB18764644 5. Moving Tokens from one ManagedSettingsStore to Another Removing an ApplicationToken from one SettingsStore and then adding it to another while the target app remains in foreground leads to the re-use of the ShieldConfiguration. Which can be wrong in many scenarios. It is not possible to request a re-request of the ShieldConfiguration in that scenario. Radar: FB14237883 6. Unable to Open Parent App (one sec) from Shield Many times, when a target app is blocked by a shield, the user wants to perform some action (e.g. to unlock more time for the target app via an intervention). That means, that somehow I have to forward the user from a ShieldActionDelegate back into my target app. Unfortunately, there’s no API for that. Many apps on the App Store rely on private API to achieve that, but that’s too risky for a popular app like one sec. Radar: FB15079668 7. Unable to Open Target App from an ApplicationToken When a user has completed an intervention within one sec, and they indend to to continue to the target app, there is no way that one sec can open the target app just from the token alone. Sure, there are URL schemes, but that means the user has to manually assign URL schemes to each ApplicationToken. That is not a very user friendly process (and in many cases impossible, because not every app registers URL schemes). It would be better if there was a way that my app could open a target app directly from an ApplicationToken, e.g. via an AppIntent that can be run on a button press. This way, the selected apps would remain fully private while still offering advanced functionality: struct OpenTargetAppIntent: AppIntent, OpenAppFromApplicationTokenIntent { func perform() { return .result(openAppFromApplicationToken: applicationToken) } } Radar: FB15500695 Summary Thanks a lot for taking the time to read my feedback. If you have any questions, please feel free to reach out to me any time. I’m always happy to provide more details, logs, and steps to reproduce in my radars / feedback requests or in-person in Cupertino. It would be extremely helpful if someone from the Screen Time / DeviceActivity engineering team could: Take a look at the listed radars. Work on bug fixes and be transparent about when fixes will be shipped. Provide workarounds in the meantime. We genuinely want to build great, reliable experiences on top of Screen Time – but in its current state, it’s becoming very difficult to depend on. – Frederik

Our app uses WKWebView to load web pages, and we're encountering a crash with WKScreenTimeConfigurationObserver on iOS 26.1 and above. However, there are no WKScreenTimeConfigurationObserver-related code calls in our project. The crash log is as follows: NSInternalInconsistencyException Cannot update for observer <WKScreenTimeConfigurationObserver 0x13be821e0> for the key path "configuration.enforcesChildRestrictions" from <STScreenTimeConfigurationObserver 0x13be808e0>, most likely because the value for the key "configuration" has changed without an appropriate KVO notification being sent. Check the KVO compliance of the STScreenTimeConfigurationObserver class. We want to confirm if this is a system bug. How can we fix it?

Hi, I’m building an iOS app that uses FamilyControls to let users block distracting apps during study sessions. Everything works fine in Debug on a real device: the authorization request succeeds and app blocking works correctly. The problem is when I try to create an Archive for App Store Connect. Xcode gives me this error: “Provisioning profile ‘iOS Team Store Provisioning Profile: com.(ID)’ doesn’t include the com.apple.developer.family-controls entitlement.” I also get a warning saying that my bundle identifier is using the development-only version of the Family Controls capability and that I should request access to the distribution version. I’ve already added the Family Controls capability, enabled the required entitlements, and I’m using automatic signing. I also tried enabling the capability for my App ID in the Apple Developer portal, but it either doesn’t save or the distribution profile still doesn’t include the entitlement. Does the Family Controls distribution entitlement require approval from Apple before it can be used in an App Store build? If so, where do I request it? Has anyone successfully published an app using FamilyControls and run into this issue? Thanks.

We have developed a Parental/Self control app using Screen time API. We have used individual authentication to authorize the app, using the instructions here: https://developer.apple.com/documentation/familycontrols/authorizationcenter The problem is , that individual auth can be disabled easily , by the following steps: enter Settings app. in Settings app, click on the Parental/Self control app. click to disable screen time restriction. show the device owner's face/fingerprint. (or pin code) Why is that a problem: Parental control apps, or self-control apps, are about giving control to the software, To make it hard for the user to disable the restrictions. So using the flow I have introduced above, it's super-easy for a user to disable his Parental control restrictions, which misses the entire point of Parental/Self control idea. Furthermore, not only the user have the means to unlock his screen time restrictions, he also MUST have the means to unlock it. This makes Screen time (with individual auth) useless: I have a code ready to make a great parental control app for my clients, with amazing ideas, but I can't use the Screen time API unless this problem is fixed. Why child-parent auth is not enough: My clients are grownups people between ages of 15-40, that are interested in self-control, so they don't have iCloud child accounts. also, the child-parent auth solution forces my clients to give some control to other person, and my clients prefer their privacy. Some of them prefer self-control and not parental-control. What I suggest as a solution: 1: Give more options to users how to disable the Screen time restrictions. including: a second faceID / FingerPrint (that isn't the same as the one used to unlock the device) a second pin password. a string password 2: Give the users the option to choose to not have the device's owner Face/Finger/Pincode ID , as a method to disable the Screen time restrictions.