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.

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 One of the new Family Control API's requires the new "Family Controls App & Website Usage" capability but it appears to be missing in the latest Xcode beta (26.4 B2). MacOS and iOS all running 26.4 Beta 3. Does anyone know if we have to wait for Xcode 26.4 Beta 3 and it's associated SDK's for this one to become available?

Hello, I submitted a Family Controls (Distribution) entitlement request on February 25, 2026 for my prayer/productivity app that uses the Screen Time API to block distracting apps. I also submitted requests for two extensions on March 6, 2026: com.prayfirst.prayFirst.ShieldAction com.prayfirst.prayFirst.ShieldConfiguration All three requests still show "Submitted" status in the Certificates, Identifiers & Profiles portal with no progress. I contacted Apple Developer Support (Case #102839422791), and they mentioned I should have received a "follow-up number" after submission — but I never received one. This entitlement is the only blocker preventing me from building and distributing my app. Could a DTS engineer please assist or escalate this? Team ID: BH752TBX9L Thank you.

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'm experiencing a contradictory validation issue with DeviceActivityReportExtension that creates an impossible situation: The Problem: Without NSExtensionPrincipalClass in Info.plist → App Store Connect rejects upload with: "Missing Info.plist values. No values for NSExtensionMainStoryboard or NSExtensionPrincipalClass found" With NSExtensionPrincipalClass → Local install fails with: "defines either an NSExtensionMainStoryboard or NSExtensionPrincipalClass key, which is not allowed for the extension point com.apple.deviceactivityui.report-extension" Setup: Extension point: com.apple.deviceactivityui.report-extension Using SwiftUI with @main attribute and DeviceActivityReportExtension protocol Xcode 16.2, iOS 17.6 deployment target Code structure: @main struct SpoolReport: DeviceActivityReportExtension { var body: some DeviceActivityReportScene { // Report scenes here } } The extension builds and runs perfectly without NSExtensionPrincipalClass, but cannot be uploaded to App Store Connect. Adding the key allows upload but breaks local installation. Is this a known issue? Is there a workaround or correct Info.plist configuration for DeviceActivityReportExtension? Thank you!

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 have gotten all necessary entitlements for all my extensions, but screen time still does not work in Testflight. our app blocks social apps for a particular period of time.. This feature works in my Xcode physical device but fails in testflight

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!