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

Hello, I am facing a critical technical blocker regarding the Family Controls (Screen Time API) entitlement for my app extensions. Current Situation: My parent app (com.hayashikento.FocusPact) is already approved for the Family Controls (Distribution) entitlement. However, the associated DeviceActivityMonitorExtension (com.hayashikento.FocusPact.FocusPActMonitor) and ReportExtension (com.hayashikento.FocusPact.ReportExtension) are still pending entitlement approval. Technical Issue: Because the extensions lack the Distribution entitlement, ManagedSettings and DeviceActivity triggers (like intervalWillEndWarning) are ignored by the system when testing via TestFlight or in a non-development environment. As a result, I am unable to verify the core "automatic re-blocking" logic and "usage reporting" features in a real-world scenario. This has completely halted the final QA and TestFlight phase of my project. Requests: Could an Apple engineer verify if these extension IDs can be linked to my existing approved parent app entitlement? Is there a specific process to expedite the "linking" of extensions when the main app is already authorized? App Details: Parent App Bundle ID: com.hayashikento.FocusPact Extension IDs: com.hayashikento.FocusPact.FocusPActMonitor, com.hayashikento.FocusPact.ReportExtension Apple ID (App)6759132649 I have already submitted the web request forms, but the lack of synchronization between the parent app and extensions is preventing my MVP launch. Any assistance would be greatly appreciated. Thank you.

Hello, I am facing a critical technical blocker regarding the Family Controls (Screen Time API) entitlement for my app extensions. Current Situation: My parent app (com.hayashikento.FocusPact) is already approved for the Family Controls (Distribution) entitlement. However, the associated DeviceActivityMonitorExtension (com.hayashikento.FocusPact.FocusPActMonitor) and ReportExtension (com.hayashikento.FocusPact.ReportExtension) are still pending entitlement approval. Technical Issue: Because the extensions lack the Distribution entitlement, ManagedSettings and DeviceActivity triggers (like intervalWillEndWarning) are ignored by the system when testing via TestFlight or in a non-development environment. As a result, I am unable to verify the core "automatic re-blocking" logic and "usage reporting" features in a real-world scenario. This has completely halted the final QA and TestFlight phase of my project. Requests: Could an Apple engineer verify if these extension IDs can be linked to my existing approved parent app entitlement? Is there a specific process to expedite the "linking" of extensions when the main app is already authorized? App Details: Parent App Bundle ID: com.hayashikento.FocusPact Extension IDs: com.hayashikento.FocusPact.FocusPActMonitor, com.hayashikento.FocusPact.ReportExtension Apple ID (App)6759132649 I have already submitted the web request forms, but the lack of synchronization between the parent app and extensions is preventing my MVP launch. Any assistance would be greatly appreciated. Thank you.

I am developing a productivity app called "FocusPact" using the Screen Time API (Family Controls). Current Status: The parent app bundle ID (com.hayashikento.FocusPact) has already been approved for the Family Controls (Distribution) entitlement. I have recently submitted a new request for the DeviceActivityMonitorExtension bundle ID: com.hayashikento.FocusPact.FocusPActMonitor. The Issue: Currently, the extension only works while debugging with Xcode (Development entitlement). When the device is disconnected, the intervalWillEndWarning and intervalDidEnd triggers are ignored by the system because the Extension ID lacks the Distribution entitlement. This is a critical blocker for my MVP testing phase on TestFlight, as I cannot verify the core "automatic re-blocking" logic in a real-world environment. Request: Could any Apple staff or engineers help expedite the linking of this extension ID to my existing approved entitlement? Parent App ID: com.hayashikento.FocusPact Extension ID: com.hayashikento.FocusPact.FocusPActMonitor I would greatly appreciate any guidance or assistance to resolve this so I can proceed with user testing. Thank you.

Hi everyone, I'm building an iOS app that uses a DeviceActivityMonitor app extension as part of the Screen Time / Family Controls API. Every time I try to upload my IPA to App Store Connect, the validation fails with this error: "Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.deviceactivity.monitor, in the Info.plist of 'Alexandria.app/PlugIns/AlexandriaActivityMonitor.appex' is invalid." Error Domain=IrisAPI Code=-19241, iris-code=STATE_ERROR.VALIDATION_ERROR What I have verified (everything looks correct): NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = AlexandriaActivityMonitor.AlexandriaActivityMonitorExtension (correctly resolved in the compiled binary, verified with plutil -p) The Swift class correctly subclasses DeviceActivityMonitor CFBundleShortVersionString matches the main app Both the main app and extension provisioning profiles explicitly contain com.apple.developer.family-controls = true (verified by inspecting embedded.mobileprovision inside the IPA) The binary code signature itself contains com.apple.developer.family-controls = true (verified with codesign -d --entitlements :-) Family Controls entitlement was requested and approved in the Developer Portal for both App IDs Tested with both Xcode 26.2 (iOS 26 SDK) and Xcode 16.4 (iOS 18 SDK) — same error in both cases The IPA is structurally correct. The error comes purely from Apple's server-side IrisAPI validator and does not correspond to anything I can identify or fix in the code or configuration. Has anyone successfully submitted an app with a DeviceActivityMonitor extension to App Store Connect recently? Is there a backend approval requirement for com.apple.deviceactivity.monitor beyond the standard Family Controls entitlement approval? Could this be a known validator bug for this specific extension type? Any help appreciated.

I’m building an iOS app that uses FamilyControls + ManagedSettings + DeviceActivity. Goal: temporarily “unlock” a shielded app for N minutes, then automatically re-apply the shield when the timer expires. What I do: In the main app, when user picks an expiry (e.g. 15 min, 30 min). I start a non-repeating DeviceActivity schedule and remove the app’s ApplicationToken from ManagedSettingsStore().shield.applications. I also store activeUnlockBundleID etc. in an App Group so the DeviceActivityMonitor extension can re-lock at the end. Expected: DeviceActivityMonitor.intervalDidEnd(for:) is invoked when the non-repeating interval ends, and I re-add the token to the shield set. Actual: The app does not re-lock when the interval expires. I added OS logs as well as “debug local notifications” from the DeviceActivityMonitor extension in: init() intervalDidStart intervalDidEnd eventDidReachThreshold None of these logs or notifications ever appear, which suggests the extension is never invoked (or cannot schedule local notifications or OS logs). Environment: Device: iPhone 17 Pro iOS 26.3.1 Xcode 26.4 Running on a physical device Notification permissions for the app: granted App + extensions are in the same App Group entitlement. Extension Info.plist has: NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = $(PRODUCT_MODULE_NAME).DeviceActivityMonitorExtension Questions: Are there known limitations/requirements for DeviceActivityMonitor callbacks where intervalDidEnd doesn't to fire? Is posting local notifications / OS Logs from a DeviceActivityMonitor extension supported/reliable? If not, what’s the recommended way to verify the extension is invoked? If this looks like a platform bug, should I file Feedback Assistant? If so, what logs/artifacts are most useful?

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

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.

Hello, I am the developer of an app called one sec which helps users to spend less time on social media: https://one-sec.app Therefore, we make heavy use of the Screen Time API, and thus ManagedSettings and ShieldActionDelegate. One feature of one sec is the so-called “Doom Scroll Emergency Brake”. This blocks a target app after a certain usage threshold (e.g. 5 minutes) and requires going through an intervention (e.g. breathing exercise) to unlock more time. That added friction makes it very effective in reducing time spent on apps. One thing that is confusing for our users is the way they are prompted to unlock more time, if they want to. They have to: Have Push Notifications enabled for one sec Exempt one sec’s notifications from being delayed by AI prioritization (otherwise they are delayed by ca. 10s) Ensure that push notifications can be delivered during foci. Understand that they have to tap on the notification, which is not very straight-forward because it does not make sense from the user’s UX perspective. This is an artificial limitation of Apple’s screen time framework which has no reason (no security / privacy implications here…). Screenshots of the current flow attached. If would be much more reasonable if there was a new ShieldActionResponse.openParentApp value that can be returned from the completion handler of the ShieldActionDelegate.handle(…) callback. We have seen different apps use private API to achieve this, but we are afraid to do the same to avoid getting banned from the App Store. It would be fair if Apple would level the playground for all apps and offer such an API officially. – Frederik PS: Tracked under FB22347946, FB18846650, FB15500681, FB15079668, FB10393561 (all without responses so far…)

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

I am developing a productivity app called "FocusPact" using the Screen Time API (Family Controls). Current Status: The parent app bundle ID (com.hayashikento.FocusPact) has already been approved for the Family Controls (Distribution) entitlement. I have recently submitted a new request for the DeviceActivityMonitorExtension bundle ID: com.hayashikento.FocusPact.FocusPActMonitor. The Issue: Currently, the extension only works while debugging with Xcode (Development entitlement). When the device is disconnected, the intervalWillEndWarning and intervalDidEnd triggers are ignored by the system because the Extension ID lacks the Distribution entitlement. This is a critical blocker for my MVP testing phase on TestFlight, as I cannot verify the core "automatic re-blocking" logic in a real-world environment. Request: Could any Apple staff or engineers help expedite the linking of this extension ID to my existing approved entitlement? Parent App ID: com.hayashikento.FocusPact Extension ID: com.hayashikento.FocusPact.FocusPActMonitor I would greatly appreciate any guidance or assistance to resolve this so I can proceed with user testing. Thank you.

Hi, we are developing a screen time management app. The app locks the device after it was used for specified amount of time. After updating to iOS 26.2, we noticed a huge issue: the events started to fire (reach the threshold) in the DeviceActivityMonitorExtension prematurely, almost immediately after scheduling. The only solution we've found is to delete the app and reboot the device, but the effect is not lasting long and this does not always help. Before updating to iOS 26, events also used to sometimes fire prematurely, but rescheduling the event often helped. Now the rescheduling happens almost every second and the events keep reaching the threshold prematurely. Can you suggest any workarounds for this issue?

Hello, I am facing a critical issue where the Family Controls (Distribution) entitlement is not being applied to my app extensions, despite the main app ID being approved. Main App ID: com.hayashikento.focuspact (Approved on March 13) Extension ID 1: com.hayashikento.focuspact.ShieldActionExtension (Pending/Not visible) Extension ID 2: com.hayashikento.focuspact.ShieldConfigurationExtension (Pending/Not visible) I have submitted requests multiple times, but the entitlement does not appear in the "Capability Requests" for these extensions in the Certificates, Identifiers & Profiles portal. Furthermore, I am unable to contact Developer Support because the "Contact Us" form on the developer website consistently shows a "Request error" or freezes on the submission page. Since I am completely blocked from TestFlight distribution, could someone from Apple please look into my account (Team ID: UHG4J7F7NH) and manually sync these entitlements? Thank you for your help.

Hi, I’m requesting the Family Controls distribution capability for my app and its extensions. The main app bundle ID was approved within 1 day. However, I later realized the associated extensions (Shield Configuration, Device Activity Monitor, Device Activity Report) also require separate approval. I submitted those extension requests 4 days ago, and they are still in "Submitted" with no updates. This is currently blocking me from proceeding with TestFlight/App Store submission, since the extensions require the approved capability. Is this delay expected for extension bundle IDs? Thanks for your help.

Hello, I have a critical issue regarding the "Family Controls (Distribution)" entitlement. My app "FocusPact" was approved for the entitlement, but there is a technical mismatch in the Bundle IDs that prevents distribution via TestFlight. [Current Situation] Parent App ID: com.hayashikento.FocusPact (Approved / Capitalized) Approved Extension ID: com.hayashikento.focuspact.ShieldConfigurationExtension (Approved / Lowercase) [The Issue] Due to the case-sensitivity difference (FocusPact vs focuspact), Xcode throws a "Bundle identifier prefix mismatch" error. Since the parent app identifier is already established as capitalized, I cannot change it to lowercase without breaking the existing configuration. [Request] I have submitted a new entitlement request with the corrected capitalized Bundle ID: Corrected Extension ID: com.hayashikento.FocusPact.ShieldConfigurationExtension Could a DTS engineer please help me synchronize the approved status to this capitalized ID? This is purely a technical correction of an already authorized functionality. Team ID: UHG4J7F7NH App Apple ID: 67591326449 Thank you for your assistance. I am a student developer eager to start MVP testing as soon as this is resolved.

A screen time app I'm making has started telling users that their limit was reached even when they're far below their limit for the day (sometimes even at 0 minutes for the day). This issue only started happening after upgrading my software to iOS 26.2. Is this happening to anyone else? If so how have you found any solutions or does anyone know of any changes that could be causing this? Any help would be appreciated.

Hello, my app is frequently loosing / forgetting the Screen Time Permission that had been granted previously on iOS 26. I have experienced it myself, sysdiagnose is in this radar: FB18997699 But also also my App Store users who have updated to iOS 26 already have reported this bug. It would be great if Apple could ensure that this bug is addressed before iOS 26 is released to the public.

Hello, iOS 26.4 has new APIs which is great. This brings new capability and updated permissions "flow". However as soon as we add the "Family Controls App and Website Usage" capability, then anyone on iOS 26.4 and above can either only approve full access or no access at all. (https://developer.apple.com/documentation/familycontrols/authorizationstatus/approvedwithdataaccess) The previous permission is impossible to obtain. Am I missing something? Is this intended behavior? We can imagine a situation where the user doesn't want to give full access (perhaps because the permissions screen says the app is able to see usage - which is not correct) but they still want to approve Screen Time permissions so the app can apply shields and what not. Thanks.

Hey there, We are being incorrectly blocked by Time Limits since the iOS 26 update released earlier this year. We are receiving complaints from parents that set a screentime limit for "All apps", and then add an exception for us, that they are still getting blocked by the OS after a certain period of time. While we originally thought this was fixed in 26.1, we have recently been made aware it still occurs. Has anyone else experienced this issue? Is there something we can do from our side to protect ourselves from this? Telling customers to remove their "All app" limit isn't really practical given our customer base, so we're looking to see if there's something on Apple's end or our end that can alleviate this.

[Reply to DTS Engineer] Thank you for looking into this. I have identified the root cause of the issue: it is a Bundle ID case-sensitivity mismatch. My parent app was approved as com.hayashikento.FocusPact (Capitalized), but I accidentally requested the Configuration Extension with a lowercase ID (com.hayashikento.focuspact...). This causes a "Prefix Mismatch" error in Xcode, preventing me from archiving the app. To fix this, I have just submitted a new entitlement request with the corrected capitalized ID: com.hayashikento.FocusPact.ShieldConfigurationExtension Since the core functionality was already approved under the lowercase ID, could you please expedite the approval for this capitalized version? This technical correction is the only thing blocking my TestFlight distribution. Thank you for your support!

Hello, I have a critical issue regarding the "Family Controls (Distribution)" entitlement. My app "FocusPact" was approved for the entitlement, but there is a technical mismatch in the Bundle IDs that prevents distribution via TestFlight. [Current Situation] Parent App ID: com.hayashikento.FocusPact (Approved / Capitalized) Approved Extension ID: com.hayashikento.focuspact.ShieldConfigurationExtension (Approved / Lowercase) [The Issue] Due to the case-sensitivity difference (FocusPact vs focuspact), Xcode throws a "Bundle identifier prefix mismatch" error. Since the parent app identifier is already established as capitalized, I cannot change it to lowercase without breaking the existing configuration. [Request] I have submitted a new entitlement request with the corrected capitalized Bundle ID: Corrected Extension ID: com.hayashikento.FocusPact.ShieldConfigurationExtension Could a DTS engineer please help me synchronize the approved status to this capitalized ID? This is purely a technical correction of an already authorized functionality. Team ID: UHG4J7F7NH App Apple ID: 67591326449 Thank you for your assistance. I am a student developer eager to start MVP testing as soon as this is resolved.