I have been building an app where I have the user select what apps they would like to track and then I display a device activity report of only those apps. The device activity report shows data perfectly for the selected apps if the users apple account is "Adult". If the users apple account is "Parent/Guardian" or "Organizer" randomly the device activity report will show 0 minutes (no screen time data). Among randomly happening I have found a trigger for the bug to be opening any FamilyActivityPicker (even not the one used for filtering the device activity report extension) then going back to the device activity report extension on the profile page anywhere from 3-50 times. Once the bug happens repeating that process 1-2 times fixes it or removing screen time restrictions permission then adding it back.

I've been stuck on Guideline 2.3 for two weeks now and I'm running out of ideas. My app is iPhone-only (UIDeviceFamily = [1]) and has been on the App Store since January. Version 2.1.9 passed review fine. The only change in 2.1.10 is adding two DeviceActivity extensions — a DeviceActivityMonitor and a DeviceActivityReport — for screen time-based stress detection. Every build since then gets rejected with the same message: "The UIRequiredDeviceCapabilities key in the Info.plist is set up in such a way that the app will not install on the device used in review." Review devices: iPhone 14 Pro, iPhone 17 Pro Max, iPad Air M3. Here's what I've tried across 13+ submissions: UIRequiredDeviceCapabilities as ["arm64"] (array) — rejected Empty array [] — rejected Removed the key entirely — upload validation fails, Xcode re-injects arm64 anyway Post-build script to force ["arm64"] — rejected Dictionary format {"arm64": true} — rejected Added com.apple.developer.family-controls to extension entitlements — rejected Enabled Family Controls (Distribution) on extension bundle IDs — rejected Fixed CFBundleVersion mismatch between host app and extensions — rejected Set TARGETED_DEVICE_FAMILY=1 on all targets including extensions — rejected Tried GENERATE_INFOPLIST_FILE=YES with minimal plists — rejected Tried ExtensionKit type for the report extension — rejected In the exported IPA, every target has UIRequiredDeviceCapabilities = ["arm64"] and UIDeviceFamily = [1]. The entitlements, provisioning profiles, and code signing all look correct. arm64 is supported on every review device they listed. The previous version (2.1.9) without DeviceActivity extensions passes review with the exact same UIRequiredDeviceCapabilities and signing configuration. Has anyone shipped an app with DeviceActivityMonitor + DeviceActivityReport extensions successfully? Is there something specific about these extension types that affects device capability validation? Or is there a known issue with the review system and FamilyControls extensions? I've replied to the review team multiple times asking which specific capability is causing the failure, but the response is always the same generic template. Any guidance would be really appreciated — I'm completely blocked on shipping this update.

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.

Device: iPhone 15 Pro Max, iOS 26.4 Xcode: Latest version, development signing with "Automatically manage signing" Team: Registered Apple Developer Program (Organization) Problem DeviceActivityReport SwiftUI view renders completely blank. The Report Extension's makeConfiguration(representing:) is never called (confirmed via App Group counter that stays at 0). The DeviceActivityMonitorExtension callbacks (intervalDidStart, eventDidReachThreshold) also never fire. What works AuthorizationCenter.shared.requestAuthorization(for: .individual) → .approved DeviceActivityCenter().startMonitoring() → registers schedules successfully, center.activities returns them ManagedSettingsStore.shield.applications → blocks apps correctly from the main app process Screen Time is enabled and actively collecting data (Settings > Screen Time shows per-app usage: Clash Royale 2h 35m, etc.) App Group UserDefaults(suiteName:) read/write works from the main app What doesn't work DeviceActivityReportExtension.makeConfiguration() is never called (callCount stays 0 in App Group) DeviceActivityMonitorExtension.intervalDidStart() is never called No extension callbacks fire at all — the extension process is never launched by iOS Confirmed it's NOT our app's issue We created a brand new Xcode project from Apple's template: File > New > Project > App File > New > Target > Device Activity Report Extension Added Family Controls capability to both targets Embedded DeviceActivityReport view in ContentView with daily filter Built and ran on the same device Result: Same blank screen. The template project's Report Extension also never renders any data. Console errors Failed to locate container app bundle record. The process may not be entitled to access the LaunchServices database or the app may have moved. (501) personaAttributesForPersonaType for type:0 failed with error Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction." LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" What we've tried Deleting app, rebooting device, reinstalling Re-requesting FamilyControls authorization on every launch Embedding extensions with "Embed & Sign" (not just "Embed Without Signing") Verified all 3 .appex files are in PlugIns/ directory at runtime Verified App Group (group.com.parentguard.app) is accessible Verified all App IDs and capabilities registered in Apple Developer portal Tried different DeviceActivityFilter configurations (daily, hourly) Placed DeviceActivityReport view at root of view hierarchy Clean build, new provisioning profiles Extensions embedded [Diagnose] Found extension: DeviceActivityReportExtension.appex [Diagnose] Found extension: DeviceActivityMonitorExtension.appex [Diagnose] Found extension: ShieldConfigurationExtension.appex Question Has anyone gotten DeviceActivityReport or DeviceActivityMonitorExtension to work on iOS 26.4 with a development-signed build from Xcode? Is there a specific configuration or workaround that makes the extension process launch? The Sandbox restriction error (159) on usermanagerd.xpc seems to be the root cause — is there an entitlement or device setting we're missing?

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()     }   }   }

Hi all, Our team (D36U48VRGM) holds approved Family Controls (Distribution) entitlement on three bundles, all live on the App Store as part of the same app: com.strategieayoub.quranfocus (main app) com.strategieayoub.quranfocus.ShieldAction com.strategieayoub.quranfocus.ShieldConfiguration We've added a fourth target — a DeviceActivityMonitor extension at com.strategieayoub.quranfocus.DeviceActivityMonitor — to replace our current BGProcessingTaskRequest re-shield path. The BGTaskScheduler approach is unreliable for our use case: iOS routinely runs the task hours late or skips it entirely, leaving users' apps unblocked far past the unlock window we promised. DeviceActivityMonitor's intervalDidEnd callback is the only mechanism Apple provides that fires reliably regardless of app state. The new bundle ID is registered, has Family Controls (Development) provisioned, and intervalDidEnd works correctly during local on-device testing. The blocker is Distribution — Xcode's Signing pane shows: "Bundle identifier is using development only version of Family Controls (Development) capability. Please request access to Family Controls (Distribution) to avoid issues when distributing." Two questions: The previous per-asset Family Controls request form has been replaced with a single account-level form that contains no free-text field where I can specify a bundle ID. How does Apple now expect developers with already-approved teams to attach an additional child bundle to that approval? Phone Developer Support said they cannot make entitlement attachments and pointed me back to the form. Is there a documented escalation path? Thanks for any pointers.

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

⬇️ ANYONE ON APPLE'S SCREEN TIME TEAM, PLEASE READ THIS ⬇️ Let's summarize the situation. 3rd-party apps with screen time access can be disabled by going to Settings > Screen Time > Apps with Screen Time Access. That's fine. Now, if I want to make it harder to remove my restrictions, I can ask a friend to enter a Screen Time Passcode for me. Great idea! The problem is my Screen Time Passcode isn't requested when disabling permissions for a third-party app. It's required for modifying any other Screen Time setting EXCEPT permissions for 3rd party apps. This is frustrating. The Screen Time passcode is a great feature. Making it compatible with permissions granted through the Family Controls framework is our NUMBER ONE REQUEST from tens of thousands of users. This feature has been requested for a long time (iOS 16, iOS 17, …): https://forums.developer.apple.com/forums/thread/714651 https://forums.developer.apple.com/forums/thread/727291 https://discussions.apple.com/thread/255421819 FB13548526
 If you're a developer working on Screen Time, share your feedback below or file one using Feedback Assistant. It is very disappointing to see it wasn't implemented for iOS 18. I can't believe this would require tremendous work from the Screen Time team to make it happen, but it would be a significant improvement for the Family Controls Framework and a ray of sunshine for all the developers who have worked really hard to deliver high-quality apps using the Screen Time API. Could an Apple engineer or a Screen Time team member give us any updates? Implementing this before the public release of iOS 18 would make A LOT of developers happy.

Is there a way for me to persist my app usage that I can see 30 days worth under Screen Time indefinitely? I'd like to roll up monthly, quarterly, annual usage for mine and my kids devices.

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

Hi everyone, I have a question regarding the intended privacy limits of the DeviceActivityReportExtension. According to the documentation and the WWDC21 session "Meet the Screen Time API", this extension was created specifically to prevent the host application from accessing the user's underlying activity data (websites visited, app usage, screen time, etc). But I have found that my host app is actually able to reconstruct this raw activity data from the activity report. I am able to extract specific visited websites and app usage durations back into the main app. I reported this to Apple Security (Case ID: OE1100504480881 ), assuming it was a sandbox bypass. However, they closed the ticket stating that this is "expected behavior" and requires no fix. My question for Screen Time Engineers: Is the documentation incorrect? If my host app is expected to be able to read this data, is there a formal API we should be using instead of extracting it from the report extension? The current behavior contradicts the privacy limits described in the documentation, so I am confused if I should rely on this data access for my app features or if it will be patched later. Thanks.

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?

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.

On iOS 26.3.1, deviceactivityd produces zero log output and never wakes a DeviceActivityMonitor extension at the scheduled time, even when the schedule is successfully registered. The extension's intervalDidStart(for:) method is never called. Steps to Reproduce: Create an app with a DeviceActivityMonitor extension subclass Add the com.apple.developer.family-controls entitlement to both the main app and extension targets Add a shared App Group entitlement to both targets In the main app, call: let center = DeviceActivityCenter() center.stopMonitoring([.myActivity]) let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour: 17, minute: 30), intervalEnd: DateComponents(hour: 17, minute: 45), repeats: true ) try center.startMonitoring(.myActivity, during: schedule) Verify registration succeeds: DeviceActivityCenter().activities.contains(.myActivity) returns true Background the app completely and wait for the intervalStart time (5:30 PM in this example) Expected Result: intervalDidStart(for:) is called in the extension process at 5:30 PM. ManagedSettings shields are applied without any user interaction. Actual Result: intervalDidStart(for:) is never called. No extension process is launched. Filtering Console.app for deviceactivityd on the device returns 0 messages — the daemon produces no logs whatsoever despite an active registered schedule. Shields are never applied. Additional Evidence: Third-party apps using DeviceActivity (e.g. Prayer Lock) successfully apply shields at scheduled times on the same device and OS version, confirming the framework is not universally broken Filtering Console.app for the app's bundle ID at the trigger time shows the main app process applying shields via a UNCalendarNotificationTrigger fallback — but no extension process activity DeviceActivityCenter().activities correctly lists the registered activity before and after the trigger time, confirming the schedule registration API is functional Environment: iOS 26.3.1 Physical device (required for FamilyControls) Development-signed build with com.apple.developer.family-controls entitlement provisioned App Group shared between main app and extension targets

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

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.

Similar Issue to FB13556935: On iOS 26.3.1, deviceactivityd produces zero log output and never wakes a DeviceActivityMonitor extension at the scheduled time, even when the schedule is successfully registered. The extension's intervalDidStart(for:) method is never called. Steps to Reproduce: Create an app with a DeviceActivityMonitor extension subclass Add the com.apple.developer.family-controls entitlement to both the main app and extension targets Add a shared App Group entitlement to both targets In the main app, call: let center = DeviceActivityCenter() center.stopMonitoring([.myActivity]) let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour: 17, minute: 30), intervalEnd: DateComponents(hour: 17, minute: 45), repeats: true ) try center.startMonitoring(.myActivity, during: schedule) Verify registration succeeds: DeviceActivityCenter().activities.contains(.myActivity) returns true Background the app completely and wait for the intervalStart time (5:30 PM in this example) Expected Result: intervalDidStart(for:) is called in the extension process at 5:30 PM. ManagedSettings shields are applied without any user interaction. Actual Result: intervalDidStart(for:) is never called. No extension process is launched. Filtering Console.app for deviceactivityd on the device returns 0 messages — the daemon produces no logs whatsoever despite an active registered schedule. Shields are never applied. Additional Evidence: Third-party apps using DeviceActivity (e.g. Prayer Lock) successfully apply shields at scheduled times on the same device and OS version, confirming the framework is not universally broken Filtering Console.app for the app's bundle ID at the trigger time shows the main app process applying shields via a UNCalendarNotificationTrigger fallback — but no extension process activity DeviceActivityCenter().activities correctly lists the registered activity before and after the trigger time, confirming the schedule registration API is functional Environment: iOS 26.3.1 Physical device (required for FamilyControls) Development-signed build with com.apple.developer.family-controls entitlement provisioned App Group shared between main app and extension targets

Hi, I’m building an iOS app called SocialLite using Apple’s Screen Time APIs, primarily FamilyControls and ManagedSettings. My goal is to block access to the Instagram app itself, while still allowing the user to receive and see Instagram notifications. Right now, when I apply the shield/block using the Screen Time API, the Instagram app is blocked as expected, but its notifications also appear to be blocked/suppressed at the same time. What I’m trying to achieve: Block the Instagram app from being opened Still allow Instagram notifications to come through normally Current behavior: The app is blocked Notifications are also blocked or no longer visible My question: Is there any supported way with Apple’s Screen Time API / ManagedSettings to shield or block an app while still allowing that app’s notifications? Or are app access and notifications tied together by design when a shield is applied? If this behavior is expected, I’d appreciate confirmation from Apple or guidance on whether there is another supported approach. Thanks.