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.

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 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’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

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.

Hi everyone, I'm running into what appears to be a stuck Family Controls entitlement request and wanted to see if anyone has experienced something similar. Request ID: 9D7MU547QH The request is still showing a status of "Submitted". Context: • Our main app bundle ID was already approved for the Family Controls entitlement. • Two related extensions (ShieldConfiguration and DeviceActivityMonitor) were also approved within a few days. • The remaining request is for a ShieldAction extension, which handles button taps from the shield UI. This entitlement is currently blocking our business's beta testing, so we’re trying to understand whether this is just normal queue delay or if the request might be stuck. Has anyone seen a case where the main app and other extensions were approved but a ShieldAction request remained in "Submitted" for an extended period? If an Apple engineer happens to see this, I’d greatly appreciate any guidance on whether the request might be stuck in the review queue. Thank you!

I am building a simple iOS app that shows the total phone usage time for today using the Screen Time APIs. Architecture: Main app → requests authorization using AuthorizationCenter.shared.requestAuthorization(for: .individual) → displays a DeviceActivityReport Report extension → DeviceActivityReportExtension → calculates total usage using DeviceActivityResults<DeviceActivityData> → shows the number in a SwiftUI view The report works correctly. The extension successfully calculates the total usage and displays it on screen. Example logic inside the report extension: for await activityData in data { for await segment in activityData.activitySegments { totalSeconds += segment.totalActivityDuration } } let totalMinutes = Int(totalSeconds / 60) The problem: I need the main app to access that number so I can store it daily in my own database. I tried to send the value from the extension to the main app using: App Group + UserDefaults(suiteName:) App Group + shared file (FileManager.containerURL) writing inside makeConfiguration(...) Example: if let defaults = UserDefaults(suiteName: "group.myapp") { defaults.set(value, forKey: "savedTotalActivity") } But the main app cannot read the value. The report extension displays the number correctly, but the data never appears in shared storage. Questions: Is DeviceActivityReportExtension intentionally sandboxed so Screen Time data cannot be exported to the containing app? Is there any supported way for the main app to access the total usage value calculated in the report extension? If exporting the value is restricted, what is the recommended architecture for apps that want to store daily Screen Time totals for later analysis? Goal: I want a simple app that records something like: 2026-03-08 → 244 minutes 2026-03-09 → 198 minutes and stores it inside the app database. Any guidance on the correct architecture would help.

On iOS 26.2 (23C55), DeviceActivityMonitor.eventDidReachThreshold fires intermittently for a daily schedule (00:00–23:59) even when iOS Screen Time shows 0 minutes for the selected apps that day. This causes premature shielding via ManagedSettings. Environment: iPhone 13 Pro Max, iOS 26.2 (23C55). Event selection: 2 apps. Threshold: 30 minutes. Multiple TestFlight users report the same behavior across various app selections and thresholds. Intermittent (~50% of days); sometimes multiple days in a row. Not observed in testing prior to iOS 26.2. Evidence: sysdiagnose + Screen Time screenshots (with 0 screen time on selected apps) + unified logs show UsageTrackingAgent notifying the extension that “unproductive from activity daily reached its threshold,” followed immediately by ManagedSettings shield being applied (extension reacting to the callback). Filed Feedback Assistant: FB21450954. Questions: Are others seeing this on 26.2? Does it correlate with restarting monitoring at interval boundaries or includesPastActivity settings?

I'm building an app that uses the Family Controls / Screen Time APIs (FamilyControls, ManagedSettings). My app has three targets, each with a distinct Bundle ID: Main App Shield Configuration Extension ShieldAction Extension All three have com.apple.developer.family-controls in their entitlements files, and they share an App Group. My question is about the distribution entitlement request form at developer.apple.com/contact/request/family-controls-distribution: does the form need to be submitted once per Bundle ID, or is a single submission for the main app sufficient to then enable Family Controls (Distribution) for the extension Bundle IDs in the developer portal as well? I've seen conflicting reports in other forum threads — some developers say one submission covers all targets, others say separate submissions are needed per Bundle ID. I've already submitted the main app, but now I am wondering whether I should submit one for each Shield extension. Thanks!

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

Description: I am developing a digital well-being application using the Screen Time API (FamilyControls, ManagedSettings, and DeviceActivity). I am encountering a critical issue where the ApplicationToken provided by the system to my app extensions suddenly changes, causing a mismatch with the tokens originally stored by the main application. The Problem: When a user selects applications via FamilyActivityPicker, we persist the FamilyActivitySelection (and the underlying ApplicationToken objects) in a shared App Group container. However, we are seeing frequent cases where the token passed into: ShieldConfigurationDataSource.configuration(shielding:in:) ShieldActionDelegate.handle(action:for:completionHandler:) ...does not match (using ==) any of the tokens previously selected and stored. IOS version: 26.2.1

Hi, I’m building an iOS self accountability app using FamilyControls and DeviceActivity. I can show the user’s real Screen Time correctly inside a DeviceActivityReport extension on a real device, but I want to use that same daily total inside the main app for today’s log and leaderboard. What I’m stuck on is getting that value back into the app. I tried App Groups, shared UserDefaults, a shared file in the app group container, and CFPreferences, but the report still only works as a display and the main app never receives the total. Is there any Apple supported way to use the daily Screen Time total from a DeviceActivityReport extension inside the containing app, or is this intentionally display only? Thanks.

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.