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.

Hi, We’re building an iOS app that uses the Screen Time APIs (FamilyControls and DeviceActivity) to display a user’s own usage metrics inside the app. With the appropriate permissions granted, we are successfully reading and presenting metrics such as: Total screen time Device pickups These metrics are already visible to the user inside our app. We would now like to introduce a user-initiated “Share” feature. The idea is to: Render selected Screen Time metrics into a shareable image card generated locally on device. Present the standard iOS share sheet (UIActivityViewController). Allow the user to share that image to Messages, social apps, etc., if they choose. Important clarifications: This is fully user-initiated. The app does not automatically transmit Screen Time data. The metrics are already displayed in-app with user permission. The share asset would be generated locally. No background export or server-side posting would occur unless explicitly triggered by the user via the share sheet. We are seeking clarification on whether there are any policy or API restrictions around: Rendering Screen Time-derived metrics into a user-facing share card Allowing user-initiated export of those metrics via the standard iOS share flow Are there any additional privacy requirements, entitlement constraints, or App Review considerations we should be aware of when implementing this? Thanks in advance for any guidance.

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, 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?

Hi everyone, I’m looking for advice on a repeated App Store rejection under Guideline 2.5.1. Background: We initially explored using Family Controls for a planned feature. That feature has now been fully removed from the app. We no longer provide any Screen Time related functionality. What we already cleaned up: Removed all FamilyControls / ManagedSettings / DeviceActivity code usage. Removed commented-out code and all related references from the project. Removed related capabilities and entitlements from targets. Removed related frameworks/dependencies. Performed a clean rebuild and submitted a new archive. However, App Review still says the app includes ScreenTime API in an unapproved manner and suggests removing those APIs. Questions: What are the most common hidden places where Screen Time / Family Controls traces remain? Has anyone seen this triggered by transitive dependencies or stale build artifacts? What evidence/details should I provide in App Review Notes to help the reviewer verify cleanup? Is there a recommended way to ask App Review to share the specific symbol/framework/target they detected? Any practical checklist or experience would be greatly appreciated. Thank you.

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.

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.

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

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, 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.

DeviceActivityReportExtension sandbox blocks all output channels — how to export resolved Application.bundleIdentifier? Application.bundleIdentifier only resolves to a non-nil value inside a DeviceActivityReportExtension (ExtensionKit/XPC). The main app and DeviceActivityMonitor extension always return nil. However, the Report Extension's sandbox silently blocks every output channel I've tested: UserDefaults (App Group): Reads succeed, writes silently dropped File writes (App Group container): Fail silently or throw HTTP requests: Network blocked entirely Local Notifications: "Couldn't communicate with a helper application" UIPasteboard: Writes silently fail iCloud KVS: synchronize() returns false Both targets share the same com.apple.security.application-groups entitlement and group identifier. The main app reads and writes to the shared container normally — only the extension's writes fail. This means resolved bundle identifiers can only be rendered in the extension's own SwiftUI view and cannot be communicated anywhere else. My question: Is this sandbox restriction intentional? If so, what is the recommended mechanism for the host app (or a backend) to obtain the resolved bundle identifiers that only the Report Extension can access? Environment: Xcode 16.3, iOS 18.3, physical device. Sample project: https://drive.google.com/file/d/1DPyN2BCUt5p-RKEPA0zsDFFEvgZVHlS_/view?usp=sharing — a minimal two-target project that demonstrates every failing channel. Run on a physical device, grant Screen Time access, select apps, and observe that bundle ID resolution shows PASS but all write channels show FAIL.