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

Hi, I submitted my Family Controls entitlement requests on April 21 for my iOS app, but I still haven’t received an approval, rejection, or any status update. This is blocking my ability to properly test and move forward with the app, since it depends on the Screen Time / Family Controls APIs. Has anyone had a similar delay recently? Is the recommended next step to file a code-level support request with my Team ID, or should I continue waiting? Thanks.

Hi, I'm building a wellness app called that helps users manage their phone usage based on their consumption, using the Screen Time API. I need the Family Controls (Distribution) entitlement to ship it. I've already submitted multiple requests across all my bundle IDs, but due to the lack of confirmation feedback after each submission, I may have submitted more than needed. Regardless, the oldest request submitted was on April 22nd (exactly 2 weeks ago), without any reply or change. Is this normal ? Also, I came across a forum post (https://developer.apple.com/forums/thread/821964?answerId=885672022#885672022) suggesting that the entitlement is now scoped at the team level rather than per bundle ID, and that I should resubmit a single request. I want to do the right thing here but I'm not sure whether to resubmit or wait and I don't want to make the situation worse than it already is. We're about a month away from our launch date and this is the last remaining blocker for both TestFlight and App Store submission. Any guidance on next steps, or help prioritizing this, would mean a lot. Thanks so much,

Hey . So i'm building a screentime app whereby users can add an accountability partner who will be able to see their total screentime.(no app breakdowns included) . This will require me to send the data to firebase realtime database and retrieve for the accountability partner to see. Problem is , I've literally tried everything but the screentime still shows 0m on the accountabiliy partner's end. I need the data to be displayed rounded down to the nearest 0.5 e.g 1hr43mins ->1.5hrs+ ,2.0hrs+ ,3.5hrs+ , meaning it only moves when a threshold is crossed by the user. (this is to save database costs). Anyway i'd really appreciate if someone could help me out here. Thanks

With the ScreenTime API Apple talks a lot about their focus on privacy and the data not leaving the device. Does that mean there would be a problem with an app where the users ScreenTime data is shared to a custom backend? Could this potentially cause an app to be rejected from the AppStore?

Summary We are seeing a recurring fatal NSInternalInconsistencyException on iOS 26.x devices. The crash originates entirely from system frameworks (Foundation / WebKit / Screen Time / NSXPCConnection) — there are no app frames in the stack. The exception is raised from an XPC reply on a worker thread, so the host app cannot wrap it in @try/@catch. The crash appears to be a KVO consistency check failing inside the platform's internal Screen Time observer (STScreenTimeConfigurationObserver) when it observes WKWebView's configuration.enforcesChildRestrictions key path. The exception message states the value of the intermediate key configuration changed without an appropriate KVO notification. Environment iOS versions: 26.2.1 (also seen on 26.0.x – 26.2.x) Devices: iPhone 13 (iPhone14,5), iPhone 16 Plus, others App orientation: portrait Process state at crash: BACKGROUND (most occurrences) App uses WKWebView in several screens (link preview, in-app web, 3rd-party SDK web views) Crash is recurring across multiple users on iOS 26.x and is reproducible at scale in production Exception Name: NSInternalInconsistencyException Reason: Cannot update for observer <WKScreenTimeConfigurationObserver 0x...> for the key path "configuration.enforcesChildRestrictions" from <STScreenTimeConfigurationObserver 0x...>, 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. Crashing thread (top frames) 0 CoreFoundation __exceptionPreprocess 1 libobjc.A.dylib objc_exception_throw 2 Foundation -[NSKeyValueNestedProperty object:withObservance:didChangeValueForKeyOrKeys:recurse:forwardingValues:] 3 Foundation NSKeyValueDidChange 4 Foundation -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:maybeNewValuesDict:usingBlock:] 5 Foundation -[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] 6 Foundation NSSetObjectValueAndNotify 7 CoreFoundation invoking 8 Foundation -[NSInvocation invoke] 9 Foundation 10 Foundation -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] 11 Foundation __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_5 12 libxpc.dylib _xpc_connection_reply_callout 13 libxpc.dylib _xpc_connection_call_reply_async 14 libdispatch.dylib _dispatch_mach_msg_async_reply_invoke 15 libdispatch.dylib _dispatch_root_queue_drain_deferred_item 16 libdispatch.dylib _dispatch_kevent_worker_thread (Every frame above frame 0 lives in the system. No app frames are present.) What we observed Crash fires asynchronously on a libdispatch kevent worker thread, triggered by an XPC reply from the Screen Time service. The exception is thrown while the platform updates a chained KVO key path (configuration.enforcesChildRestrictions) on a WKWebView instance. The intermediate key configuration apparently changed without a paired willChange/didChange notification, which Foundation's KVO machinery then flags as inconsistency. Because the throw happens on the XPC reply path, there is no app-level synchronous frame we can wrap to recover. The exception unwinds straight into std::__terminate. What we tried (no effect) Confirmed all WKWebView creation and release happens on the main thread. Stop loading and nil out navigationDelegate before releasing the WKWebView. Avoided mutating WKWebViewConfiguration after the WKWebView is created. Checked for any custom KVO on WKWebView.configuration in app code — none exists. The crash still reproduces; we have no path to mitigate it from the application side. Questions for Apple / the community Is STScreenTimeConfigurationObserver expected to observe WKWebView.configuration.enforcesChildRestrictions under all conditions on iOS 26, or only when Screen Time / Communication Limits / Child Restrictions are enabled on the device? 2. Is there a public API (WKWebViewConfiguration option, Info.plist key, etc.) to opt a WKWebView out of Screen Time observation for hosts that do not need Screen Time integration for their web content? 3. Is this a known regression in iOS 26.x KVO chained-key-path notification posting inside WebKit's Screen Time integration? If so, is a fix slated for an upcoming 26.x release? 4. Is there any recommended workaround on the application side that does not rely on swizzling private Foundation / NSXPCConnection methods? Reproduction notes We do not have a deterministic local repro. Crashes are heavily concentrated on: iOS 26.2.1 Devices with Screen Time / Communication Limits / Child Restrictions configured at the OS level App entering the BACKGROUND state shortly after a WKWebView session If anyone has a reliable local repro on a developer device, please share — we would also like to file a Feedback Assistant report with steps. Filed Feedback Will attach FB number once filed. Thanks in advance.

We are developing an MDM agent app that uses FamilyControls with .individual authorization to enforce Screen Time restrictions (app blocking, domain blocking via ManagedSettingsStore and DeviceActivityCenter). The Problem We are actively subscribing to AuthorizationCenter.shared.$authorizationStatus to detect authorization changes. However, when the user revokes the app's FamilyControls authorization through Settings (either via Settings > Screen Time > Apps With Screen Time Access, or Settings > Apps > [Our App]), the publisher does not emit any value. All ManagedSettingsStore restrictions are lifted immediately by the system, but our app receives no notification of this change. The only scenario where the publisher reliably emits is when a debugger is attached (i.e., running directly from Xcode). Without the debugger, the publisher is completely silent — even when the app returns to foreground. Code Example We tried subscribing directly to AuthorizationCenter.shared.$authorizationStatus with no intermediary, exactly as shown in the documentation: AuthorizationCenter.shared.$authorizationStatus .sink { status in print("[DIRECT] authorizationStatus emitted: \(status)") } .store(in: &cancellables) This subscription is set up at app launch and stored in cancellables. The result is the same — the publisher does not emit when the user revokes authorization in Settings without a debugger attached. Documentation Reference The documentation for authorizationStatus states: "The status may change due to external events, such as a child graduating to an adult account, or a parent or guardian changing the status in Settings." And: "The system sets this property only after a call to requestAuthorization(for:) succeeds. It then updates the property until a call to revokeAuthorization(completionHandler:) succeeds or your app exits." This suggests the publisher should emit when the status is changed via Settings, but in our testing it does not — unless a debugger is attached. What We Verified We tested with a development-signed build (which includes the com.apple.developer.family-controls entitlement), launched from Xcode, then disconnected the debugger, killed the app, and relaunched from the home screen. Scenario Publisher emits on revocation? Running from Xcode (debugger attached) Yes, immediately Development-signed build (no debugger) No — silent even on foreground return We also confirmed: MDM configuration profiles can disable Screen Time entirely, but cannot restrict the per-app authorization toggle — the user can always freely revoke the app's Screen Time access The Security Gap This creates a significant gap for parental controls use cases: User leaves the app (app goes to background) User goes to Settings and disables Screen Time access for the app All restrictions are immediately lifted User uses the device freely User re-enables Screen Time access and opens the app Everything syncs back to normal — administrator never knows Questions Is there any supported mechanism to receive a notification (background or foreground) when FamilyControls individual authorization is revoked? We are subscribing to AuthorizationCenter.shared.$authorizationStatus but it does not emit. Is the $authorizationStatus publisher expected to work only when a debugger is attached? Is this a known limitation or a bug? Can DeviceActivityMonitor extension detect authorization revocation? Based on documentation it appears limited to schedule/threshold events, but we haven't confirmed this. Is there a planned API improvement to address this gap? Environment iOS 26.2 Xcode 26.3 Swift 6.2.4 FamilyControls .individual authorization Related Threads Screen time API can be disabled easily Changing Screen Time Passcode does not protect apps

We came across reports on Medium and Apple Developer Forums suggesting that ApplicationToken and ActivityCategoryToken values issued by the FamilyControls framework are not guaranteed to be stable, that iOS may silently re-issue new tokens for the same apps after OS or app updates, making any previously stored tokens invalid. We are storing FamilyActivitySelection tokens encoded via JSONEncoder to a backend for long-term use, and relying on them inside a DeviceActivityMonitorExtension to restore and apply shields when a schedule fires. What we're trying to understand is: is this token instability still an active problem in iOS 16/17/18/26, and when a token does become invalid, does JSONDecoder actually throw a DecodingError giving us a clear signal, or does it decode successfully and ManagedSettingsStore just silently ignore the stale tokens with no error at all? On Medium, We Found That The Token Mutation Problem One of the more painful bugs in real production apps: application tokens are not guaranteed to be stable forever. iOS can silently issue new, different tokens for the same app. If your store contains the old token and the Shield delegate receives a new one, the delegate has no way to match them — it doesn’t know which store is responsible for the shield, or which blocking “profile” caused it. This has been reported by multiple developers of real Screen Time apps and confirmed across several Apple Developer Forum threads. There is no official fix yet. The workaround is defensive: when the ShieldConfigurationDataSource or ShieldActionDelegate receives a token you don't recognise, fall back to a generic shield UI rather than crashing or returning empty data. And never rely on token identity as a long-term stable key in your persistence layer — always re-derive from a fresh FamilyActivityPicker selection when the user re-activates a profile.

Hello, I have submitted the Family Controls Distribution entitlement request twice, but I have not received any confirmation email or follow-up number for either submission. App: parental control app Bundle ID: com.learnunlock.app Use case: We use FamilyControls (authorization), ManagedSettings (shield apps), and DeviceActivity (schedule restrictions) to help families manage screen time. Could anyone from Apple please check the status of my submissions, or advise on next steps? Thank you.

When I tap on one of the buttons in the ShieldAction extension I want to close the shield and open the parent app instead of the shielded app. Is there any way of doing this using the Screen Time API? class ShieldActionExtension: ShieldActionDelegate {      override func handle(action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void) {     // Handle the action as needed.           let store = ManagedSettingsStore()               switch action {     case .primaryButtonPressed:       //TODO - open parent app       completionHandler(.defer)     case .secondaryButtonPressed:       //remove shield       store.shield.applications?.remove(application)       completionHandler(.defer)         @unknown default:       fatalError()     }   }   }

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!

Hello, I submitted a request for Family Controls (Distribution) approval, and it has now been over 4 days without any update on the status. I understand that review times can vary, but I wanted to check if this delay is expected or if there’s anything I might need to do on my end to help move the process forward. Could anyone from the Apple team or the community provide insight into: Typical processing times for Family Controls distribution requests Whether delays beyond a few days are common Any steps I should take to follow up or expedite the review For reference: Status: Submitted Submission time: April 21, 2026 Any guidance would be greatly appreciated. Thank you!

I submitted a Family Controls Framework Entitlement request on April 16, 2026 for my iOS app (Team ID: U3BVGVPCEH). After 11 days, the request still shows "Submitted" with no status update or email communication. I submitted two additional requests on April 20 and April 23 thinking the first had failed (no confirmation email was ever received). All three show "Submitted": J5DLD62PNZ — April 16 VV8B272DHZ — April 20 D362NT677B — April 23 I also opened a Developer Support ticket on April 23 with no response yet. Can anyone help me a bit? I cannot distribute my app by Testflight and I need it for my PhD.

Hello, I have submitted multiple requests for the Family Controls Distribution Entitlement through this form: https://developer.apple.com/contact/request/family-controls-distribution After submitting my requests, I waited for about 1 week but did not receive any response. Since I heard nothing, I contacted Apple Developer Support by email. After that, I finally received a response from an advisor asking for additional information, including my follow-up number. I replied with all the requested information immediately, but it has now been 5 more days and I still have not received any further response. In total, I have been waiting for about 2 weeks for this entitlement request. My app is a Screen Time control / digital wellbeing application that helps users reduce screen time through exercise-based challenges and healthy habits. My app uses the FamilyControls, ManagedSettings, and DeviceActivity frameworks and requires the Distribution Entitlement for App Store release. Here are my details: Case Number: 102866460896 Request Type: Family Controls Distribution Entitlement I understand the team may be busy, but I would appreciate any help checking the status of my request or escalating it if possible. Thank you very much.

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.

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 am trying to implement a minimal DeviceActivityReport extension. Setup: iOS app with FamilyControls authorization (status = approved) DeviceActivityReport displayed in SwiftUI Report extension embedded in PlugIns Correct NSExtensionPointIdentifier: com.apple.deviceactivityui.report-extension No NSExtensionPrincipalClass or storyboard Entitlements: com.apple.developer.family-controls com.apple.developer.family-controls.app-and-website-usage The app installs and runs correctly. Authorization is granted. However, the extension is never loaded: No logs from the extension (init/body/makeConfiguration never called) Console shows: "Failed to discover the client's extension: DeviceActivityReportService... ClientError Code=2" Environment: Xcode 16.2 iOS device running iOS 18.x (latest available) The .appex is correctly embedded and signed. Question: Is there a known issue with DeviceActivityReport extensions not being discovered at runtime with this setup? Is additional configuration required beyond NSExtensionPointIdentifier? Thanks

I'm writing this post out of genuine desperation after exhausting every official support channel available to me. The situation: I've built a screen time / focus app for students called SınavKilidi, specifically designed for Turkish high school students preparing for the YKS university entrance exam — one of the most high-stakes exams in Turkey, taken by hundreds of thousands of students every year. The exam window is approximately 2 months away. This app is inherently seasonal: if it doesn't reach users before the exam season, an entire year of development becomes irrelevant. The main app binary was approved and is live. Everything on the App Store Connect side is fully ready — metadata, screenshots, pricing, in-app purchases, the works. The blocker: My app uses App Extensions that require the com.apple.developer.family-controls entitlement. The main app target received distribution entitlement approval. However, the extensions — which are architecturally inseparable from the core functionality — have not received the same entitlement. Without this, I cannot submit a working build. The app is literally unshippable in its current state despite the main entitlement being granted. This is not a configuration issue on my end. The entitlement is correctly set up in my provisioning profiles. The gap is purely on Apple's approval side for the extension targets. The support experience: I opened Case #102855522321 on March 29, 2026. Since then: I had a call with Apple Developer Support on April 1 I sent follow-up emails on April 1, April 2, April 3, and April 7 Not a single substantive response. Only automated acknowledgements. That is 10+ days, 4 follow-up emails, 1 phone call, and complete silence on an issue that is actively costing me my launch window. What I'm asking: I'm not asking for special treatment. I understand Apple receives thousands of requests. But this entitlement request is for a legitimate, already-partially-approved app, with a documented real-world deadline, in an educational category that Apple actively promotes. Can anyone from the App Review or Developer Relations team look into Case #102855522321 and provide an actual update? Or can anyone here share whether there's a known delay affecting FamilyControls entitlement approvals for extensions specifically? Any guidance would be deeply appreciated. Every day that passes without a resolution is a day closer to this app missing its entire reason for existing.

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 Screen Time Team! The Screen Time passcode can be brute-forced without rate limiting by repeatedly attempting guesses through the "Erase All Content and Settings" flow. This allows unlimited passcode attempts with no delay, lockout, or escalation, effectively defeating the purpose of the Screen Time passcode as a parental control mechanism. Impact: Children can bypass Screen Time protections by guessing the passcode No rate limiting enables trivial brute-force attacks (especially for 4-digit codes) Undermines trust in Screen Time as a parental control system Creates real-world safety risks for families relying on Screen Time restrictions Publicly shared methods (e.g. on TikTok) increase likelihood of widespread abuse Steps to Reproduce: Enable Screen Time and set a passcode Open Settings → General → Transfer or Reset iPhone → Erase All Content and Settings When prompted for the Screen Time passcode, enter an incorrect code Repeat the process with different guesses Expected Result: After a small number of incorrect attempts, the system should: enforce exponential backoff delays, or temporarily lock further attempts, or require Apple ID authentication Attempts should be rate-limited across system flows Actual Result: Unlimited passcode attempts are allowed No delay, lockout, or penalty is applied Enables rapid brute-force guessing of the Screen Time passcode Notes: This appears to bypass standard passcode protections that exist in other parts of iOS The issue is especially severe for 4-digit Screen Time passcodes (10,000 combinations) The attack surface is exposed through a system-level reset flow Suggested Fix: Introduce global rate limiting for Screen Time passcode attempts across all entry points Apply exponential backoff after failed attempts Require Apple ID authentication after multiple failures Consider enforcing 6-digit minimum passcodes for Screen Time Log and unify attempt counters across system components Severity: Critical (Security vulnerability enabling brute-force of parental control passcode) See TikTok: https://www.tiktok.com/@aldanaisthebest12170/video/7615053429500644621 Feedback request: FB22263276 – Frederik (one sec app)

Hello! I am experiencing some strange bugs around DeviceActivityEvents: When creating a DeviceActivityEvent we can assign a threshold and applicationTokens. The idea is, that after the user has spent said threshold on said apps, eventDidReachThreshold is called. includesPastActivity is set to false. On iOS 26 however, it happens (quite reliably after updating to a new beta seed) quite often that eventDidReachThreshold is called immediately (after a couple of seconds) instead of waiting for the threshold to be met. Is anyone else seeing similar issues on iOS 26? Only workaround I have found is to ask users to re-grant Screen Time permissions. This only holds for about two weeks though or at most until the next iOS 26 beta update is installed. Feedback filed under: FB18061981 FB18927456