Prevent access to the Screen Time API without guardian approval and provide opaque tokens that represent apps and websites.

All subtopics
Posts under Family Controls topic

Post

Replies

Boosts

Views

Activity

Urgent: Family Controls Entitlement for DeviceActivityMonitorExtension (Parent app already approved)
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.
0
0
28
1w
FamilyControls individual authorization: No way to detect revocation while app is backgrounded
We are developing an MDM agent app that uses FamilyControls with .individual authorization to enforce Screen Time restrictions (app blocking, domain blocking via ManagedSettingsStore and DeviceActivityCenter). The Problem We are actively subscribing to AuthorizationCenter.shared.$authorizationStatus to detect authorization changes. However, when the user revokes the app's FamilyControls authorization through Settings (either via Settings > Screen Time > Apps With Screen Time Access, or Settings > Apps > [Our App]), the publisher does not emit any value. All ManagedSettingsStore restrictions are lifted immediately by the system, but our app receives no notification of this change. The only scenario where the publisher reliably emits is when a debugger is attached (i.e., running directly from Xcode). Without the debugger, the publisher is completely silent — even when the app returns to foreground. Code Example We tried subscribing directly to AuthorizationCenter.shared.$authorizationStatus with no intermediary, exactly as shown in the documentation: AuthorizationCenter.shared.$authorizationStatus .sink { status in print("[DIRECT] authorizationStatus emitted: \(status)") } .store(in: &cancellables) This subscription is set up at app launch and stored in cancellables. The result is the same — the publisher does not emit when the user revokes authorization in Settings without a debugger attached. Documentation Reference The documentation for authorizationStatus states: "The status may change due to external events, such as a child graduating to an adult account, or a parent or guardian changing the status in Settings." And: "The system sets this property only after a call to requestAuthorization(for:) succeeds. It then updates the property until a call to revokeAuthorization(completionHandler:) succeeds or your app exits." This suggests the publisher should emit when the status is changed via Settings, but in our testing it does not — unless a debugger is attached. What We Verified We tested with a development-signed build (which includes the com.apple.developer.family-controls entitlement), launched from Xcode, then disconnected the debugger, killed the app, and relaunched from the home screen. Scenario Publisher emits on revocation? Running from Xcode (debugger attached) Yes, immediately Development-signed build (no debugger) No — silent even on foreground return We also confirmed: MDM configuration profiles can disable Screen Time entirely, but cannot restrict the per-app authorization toggle — the user can always freely revoke the app's Screen Time access The Security Gap This creates a significant gap for parental controls use cases: User leaves the app (app goes to background) User goes to Settings and disables Screen Time access for the app All restrictions are immediately lifted User uses the device freely User re-enables Screen Time access and opens the app Everything syncs back to normal — administrator never knows Questions Is there any supported mechanism to receive a notification (background or foreground) when FamilyControls individual authorization is revoked? We are subscribing to AuthorizationCenter.shared.$authorizationStatus but it does not emit. Is the $authorizationStatus publisher expected to work only when a debugger is attached? Is this a known limitation or a bug? Can DeviceActivityMonitor extension detect authorization revocation? Based on documentation it appears limited to schedule/threshold events, but we haven't confirmed this. Is there a planned API improvement to address this gap? Environment iOS 26.2 Xcode 26.3 Swift 6.2.4 FamilyControls .individual authorization Related Threads Screen time API can be disabled easily Changing Screen Time Passcode does not protect apps
0
0
76
1w
Allow to open parent app from ShieldActionDelegate: `ShieldActionResponse.openParentApp`
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…)
0
0
49
1w
Family controls distribution request (timeline info)
Hello, I submitted a request for the Family Controls (Distribution) entitlement, but haven't received status update regarding approval/rejection etc. I submitted a previous contact support ticket as well. I'm wondering the timeline and also if my request went through - currently it says 'submitted' but it's remained this way for a while... I've had other developers in communities saying they were approved earlier, so curious if it's an app issue. Thank you
0
0
47
1w
DeviceActivityMonitor intervalDidEnd not firing for non-repeating timed unlock
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?
0
0
67
4d
Family Controls (Distribution) approved via email but portal still shows "Submitted" - blocking App Store submission
Hi, I submitted a Family Controls (Distribution) entitlement request for my app Faith Lock (com.faithlock.ios) - a prayer-focused iOS app that uses the Screen Time API to help users block distracting apps. I received an approval email, but the portal still shows the request as "Submitted" and the Distribution option does not appear under Additional Capabilities for my identifier. This is blocking me from submitting to App Store Connect. Details: Bundle ID: com.faithlock.ios Team ID: F86P575UNP Request IDs: 3PWTDR8KL3 / 885ZK276KK Status in portal: Submitted (unchanged since approval email) Has anyone experienced this? Is there a way to get the portal manually updated to reflect the approval? Any help or escalation from a DTS engineer would be greatly appreciated. Thank you.
0
0
79
4d
Urgent
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.
0
0
39
3d
Technical Blocker: Family Controls Entitlement for DeviceActivityMonitorExtension (Parent app already approved)
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.
0
0
22
3d
Technical Blocker: Family Controls Entitlement for DeviceActivityMonitorExtension (Parent app already approved)
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.
0
0
24
3d
App rejected 13+ times for UIRequiredDeviceCapabilities after adding DeviceActivity extensions — what am I missing?
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.
1
0
53
14h
Clarification on Family Controls Entitlement Coverage for App Extensions
Hello Apple Developer Community, I have an existing Family Controls entitlement approved for my main app. My app includes the following extensions: AppLimitMonitorExtension ShieldConfigurationExtension ShieldActionExtension I am seeking clarification on whether my existing Family Controls entitlement for the main app automatically covers these extensions, or if I must submit separate entitlement requests for each extension. Because when I try to distribute app on App Store Connect it give me error "Provisioning profile failed qualification". Many developers appear to be facing this issue, and it seems that Apple has not clearly documented this. is information anywhere.
3
0
176
Apr ’25
iOS 18.4 (?) FamilyActivityPicker regression: presenting SFSafariViewController on top bugs
If I present "SFSafariViewController" when a "FamilyActivityPicker" is visible, it will automatically dismiss the "SFSafariViewController" and crash the "FamilyActivityPicker." I'm assuming the cause of the bug is that each is in a separate process (aside from the app), and there's some hacks to try to stop "FamilyActivityPicker" from crashing, and this is causing the new bug because "SFSafariViewController" is also in a separate process. (I'm not 100% if its just in 18.4 or iOS 18 overall...) (I'll try to file a feedback soon, but its 100% reproducible for me across multiple devices on iOS 18.4)
6
0
303
Apr ’25
Issue with Universal Links and App Extension (ShieldAction Handler)
Issue with Universal Links and App Extension (ShieldAction Handler) I'm currently working on a POC app using the FamilyControls framework and facing an issue when trying to open a Universal Link from an app extension, specifically from a ShieldAction handler. When I try to open a Universal Link, I encounter the following error: Failed to open URL https://sixteen-server-c008110f8759.herokuapp.com/.well-known/apple-app-site-association: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open 'com.apple.mobilesafari' failed." UserInfo={BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x14f2d90b0 {Error Domain=FBSOpenApplicationErrorDomain Code=3 "Application com.sixteen.life is neither visible nor entitled, so may not perform un-trusted user actions." UserInfo={BSErrorCodeDescription=Security, NSLocalizedFailureReason=Application com.sixteen.life is neither visible nor entitled, so may not perform un-trusted user actions.}} Context: I’m using a ShieldAction handler as part of an App Extension to trigger the action (e.g., "Break in Shield") in my app. The app extension (ShieldAction handler) is responsible for trying to open the Universal Link. I’m encountering the error because the app is not visible or entitled to perform this action, which seems to be related to security restrictions when using App Extensions. Questions: App Extension and Universal Link Interaction: Is it possible for an App Extension (like ShieldAction handler) to open a Universal Link or trigger an external app, such as Safari, even though it is not the foreground app? Entitlements for App Extensions: Are there any specific entitlements or permissions required to allow an app extension (ShieldAction handler) to open Universal Links or perform actions like opening Safari from the background? App Visibility and State: How can I ensure that my app is in the right state (visible/active) and has the necessary entitlements to trigger these actions when running in the context of an app extension? Workaround: If this behavior is restricted due to app extension limitations, what would be the recommended workaround to handle launching external apps (like Safari) or Universal Links from within an app extension?
9
0
474
Jul ’25
Extend Family Control permission to app's extensions
I have tried multiple time through multiple channels and you have yet to respond to my request. I am developing an App on xcode APP Bundle ID: garymdmd.MediaPace Apple ID: 6740823496 Apple has granted me distribution use of the Family Control/Screentime module for my main app. According to your engineer's post here: https://developer.apple.com/forums/thread/764919 That permission should be extended to your extensions that are part of the app. When you try to setup the extension identifiers they do not show the "added capabilities" column that sow sup when getting permission for the main app so you are not able to endow the extension with these permissions which seem to be needed to work with the app. I am trying to add these bundle identifier extensions: garymdmd.MediaPace.ScreenTimeMonitorDuo garymdmd.MediaPace.DeviceActivityReport Can you please tell me how to get this to work or to add permissions to these extensions. I have sent in the request form multiple times (here - https://developer.apple.com/contact/request/family-controls-distribution) and Apple simply writes back that I have permission after a few weeks but nothing changes for the extension capabilities.
2
0
164
Jun ’25
Family Control Entitlements not recognized when distributing
I have been approved for family controls entitlements and see them in my apple certificates for my bundle identifier. I see them listed for Distribution in my Runner, however, when I try to distribute I get the error that I do not have the right permissions. Do I need to get the entitlements for each extension I have as well? I have three extensions that use the family controls.
1
0
157
May ’25
StoreKit2, IAP not instantly shared with Family
Hey folks! In one of our apps we're using the FamilyControls framework to manage the screentime for the child. The app requires the Guardian to activate a subscription on his/her device to enable the functionality for the Child on the child device. We're currently using StoreKit 2 to get notified when there is an active subscription. The issue we're seeing (and our users) is that an activated subscription isn't instantly propagated to the Family members, in this case the device belonging to the child. Is this a known bug, and are the possible any workarounds? Currently we have to ask our users to "Restore Purchase" or wait minutes/hours for the app to active, which isn't a viable solution. We want it to "just work" :) Sincerely, César Pinto Castillo Ambi Studio
3
0
122
May ’25
Need com.apple.developer.managed-settings entitlement
Hello, I already have got approval from Apple for com.apple.developer.family-controls entitlement When I am building my app, there is one part where I need to check the list of applications which I have blocked with my app. To get the list I have to have com.apple.developer.managed-settings entitlement ... Now how and where show I get hold of it ? I already got permission for Family Control, how do I get hold of this now ?
5
0
220
Jul ’25
Profile doesn't support Family Controls (Development).
Hi there! I've been getting this error when I've checked multiple times that I've included the right entitlements as well as provisiong profile. My one concern is that perhaps I'm unable to submit to internal or external TestFlight with Family Controls (Development) and need the one for distrubution, but have yet to submit my appplication for this ability. If anyone has any inisght into this issue lmk!
1
0
204
Jul ’25
Urgent: Family Controls Entitlement for DeviceActivityMonitorExtension (Parent app already approved)
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.
Replies
0
Boosts
0
Views
28
Activity
1w
FamilyControls individual authorization: No way to detect revocation while app is backgrounded
We are developing an MDM agent app that uses FamilyControls with .individual authorization to enforce Screen Time restrictions (app blocking, domain blocking via ManagedSettingsStore and DeviceActivityCenter). The Problem We are actively subscribing to AuthorizationCenter.shared.$authorizationStatus to detect authorization changes. However, when the user revokes the app's FamilyControls authorization through Settings (either via Settings > Screen Time > Apps With Screen Time Access, or Settings > Apps > [Our App]), the publisher does not emit any value. All ManagedSettingsStore restrictions are lifted immediately by the system, but our app receives no notification of this change. The only scenario where the publisher reliably emits is when a debugger is attached (i.e., running directly from Xcode). Without the debugger, the publisher is completely silent — even when the app returns to foreground. Code Example We tried subscribing directly to AuthorizationCenter.shared.$authorizationStatus with no intermediary, exactly as shown in the documentation: AuthorizationCenter.shared.$authorizationStatus .sink { status in print("[DIRECT] authorizationStatus emitted: \(status)") } .store(in: &cancellables) This subscription is set up at app launch and stored in cancellables. The result is the same — the publisher does not emit when the user revokes authorization in Settings without a debugger attached. Documentation Reference The documentation for authorizationStatus states: "The status may change due to external events, such as a child graduating to an adult account, or a parent or guardian changing the status in Settings." And: "The system sets this property only after a call to requestAuthorization(for:) succeeds. It then updates the property until a call to revokeAuthorization(completionHandler:) succeeds or your app exits." This suggests the publisher should emit when the status is changed via Settings, but in our testing it does not — unless a debugger is attached. What We Verified We tested with a development-signed build (which includes the com.apple.developer.family-controls entitlement), launched from Xcode, then disconnected the debugger, killed the app, and relaunched from the home screen. Scenario Publisher emits on revocation? Running from Xcode (debugger attached) Yes, immediately Development-signed build (no debugger) No — silent even on foreground return We also confirmed: MDM configuration profiles can disable Screen Time entirely, but cannot restrict the per-app authorization toggle — the user can always freely revoke the app's Screen Time access The Security Gap This creates a significant gap for parental controls use cases: User leaves the app (app goes to background) User goes to Settings and disables Screen Time access for the app All restrictions are immediately lifted User uses the device freely User re-enables Screen Time access and opens the app Everything syncs back to normal — administrator never knows Questions Is there any supported mechanism to receive a notification (background or foreground) when FamilyControls individual authorization is revoked? We are subscribing to AuthorizationCenter.shared.$authorizationStatus but it does not emit. Is the $authorizationStatus publisher expected to work only when a debugger is attached? Is this a known limitation or a bug? Can DeviceActivityMonitor extension detect authorization revocation? Based on documentation it appears limited to schedule/threshold events, but we haven't confirmed this. Is there a planned API improvement to address this gap? Environment iOS 26.2 Xcode 26.3 Swift 6.2.4 FamilyControls .individual authorization Related Threads Screen time API can be disabled easily Changing Screen Time Passcode does not protect apps
Replies
0
Boosts
0
Views
76
Activity
1w
Allow to open parent app from ShieldActionDelegate: `ShieldActionResponse.openParentApp`
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…)
Replies
0
Boosts
0
Views
49
Activity
1w
Family controls distribution request (timeline info)
Hello, I submitted a request for the Family Controls (Distribution) entitlement, but haven't received status update regarding approval/rejection etc. I submitted a previous contact support ticket as well. I'm wondering the timeline and also if my request went through - currently it says 'submitted' but it's remained this way for a while... I've had other developers in communities saying they were approved earlier, so curious if it's an app issue. Thank you
Replies
0
Boosts
0
Views
47
Activity
1w
DeviceActivityMonitor intervalDidEnd not firing for non-repeating timed unlock
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?
Replies
0
Boosts
0
Views
67
Activity
4d
Family Controls (Distribution) approved via email but portal still shows "Submitted" - blocking App Store submission
Hi, I submitted a Family Controls (Distribution) entitlement request for my app Faith Lock (com.faithlock.ios) - a prayer-focused iOS app that uses the Screen Time API to help users block distracting apps. I received an approval email, but the portal still shows the request as "Submitted" and the Distribution option does not appear under Additional Capabilities for my identifier. This is blocking me from submitting to App Store Connect. Details: Bundle ID: com.faithlock.ios Team ID: F86P575UNP Request IDs: 3PWTDR8KL3 / 885ZK276KK Status in portal: Submitted (unchanged since approval email) Has anyone experienced this? Is there a way to get the portal manually updated to reflect the approval? Any help or escalation from a DTS engineer would be greatly appreciated. Thank you.
Replies
0
Boosts
0
Views
79
Activity
4d
Urgent
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.
Replies
0
Boosts
0
Views
39
Activity
3d
Technical Blocker: Family Controls Entitlement for DeviceActivityMonitorExtension (Parent app already approved)
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.
Replies
0
Boosts
0
Views
22
Activity
3d
Technical Blocker: Family Controls Entitlement for DeviceActivityMonitorExtension (Parent app already approved)
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.
Replies
0
Boosts
0
Views
24
Activity
3d
App rejected 13+ times for UIRequiredDeviceCapabilities after adding DeviceActivity extensions — what am I missing?
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.
Replies
1
Boosts
0
Views
53
Activity
14h
New DeviceActivityAuthorization API without documentation
Here is a post to gather findings in case anyone found out what this new API does. Apple did not include any comments or documentation and due to the generic naming we don't know what this API might does. https://developer.apple.com/documentation/deviceactivity/deviceactivityauthorization?changes=latest_major
Replies
3
Boosts
0
Views
668
Activity
Jul ’25
FamilyActivityPicker Title
Is it possible to change the title "Choose Activites" and also remove the search on the FamilyActivityPicker?
Replies
4
Boosts
0
Views
580
Activity
Nov ’25
Clarification on Family Controls Entitlement Coverage for App Extensions
Hello Apple Developer Community, I have an existing Family Controls entitlement approved for my main app. My app includes the following extensions: AppLimitMonitorExtension ShieldConfigurationExtension ShieldActionExtension I am seeking clarification on whether my existing Family Controls entitlement for the main app automatically covers these extensions, or if I must submit separate entitlement requests for each extension. Because when I try to distribute app on App Store Connect it give me error "Provisioning profile failed qualification". Many developers appear to be facing this issue, and it seems that Apple has not clearly documented this. is information anywhere.
Replies
3
Boosts
0
Views
176
Activity
Apr ’25
iOS 18.4 (?) FamilyActivityPicker regression: presenting SFSafariViewController on top bugs
If I present "SFSafariViewController" when a "FamilyActivityPicker" is visible, it will automatically dismiss the "SFSafariViewController" and crash the "FamilyActivityPicker." I'm assuming the cause of the bug is that each is in a separate process (aside from the app), and there's some hacks to try to stop "FamilyActivityPicker" from crashing, and this is causing the new bug because "SFSafariViewController" is also in a separate process. (I'm not 100% if its just in 18.4 or iOS 18 overall...) (I'll try to file a feedback soon, but its 100% reproducible for me across multiple devices on iOS 18.4)
Replies
6
Boosts
0
Views
303
Activity
Apr ’25
Issue with Universal Links and App Extension (ShieldAction Handler)
Issue with Universal Links and App Extension (ShieldAction Handler) I'm currently working on a POC app using the FamilyControls framework and facing an issue when trying to open a Universal Link from an app extension, specifically from a ShieldAction handler. When I try to open a Universal Link, I encounter the following error: Failed to open URL https://sixteen-server-c008110f8759.herokuapp.com/.well-known/apple-app-site-association: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open 'com.apple.mobilesafari' failed." UserInfo={BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x14f2d90b0 {Error Domain=FBSOpenApplicationErrorDomain Code=3 "Application com.sixteen.life is neither visible nor entitled, so may not perform un-trusted user actions." UserInfo={BSErrorCodeDescription=Security, NSLocalizedFailureReason=Application com.sixteen.life is neither visible nor entitled, so may not perform un-trusted user actions.}} Context: I’m using a ShieldAction handler as part of an App Extension to trigger the action (e.g., "Break in Shield") in my app. The app extension (ShieldAction handler) is responsible for trying to open the Universal Link. I’m encountering the error because the app is not visible or entitled to perform this action, which seems to be related to security restrictions when using App Extensions. Questions: App Extension and Universal Link Interaction: Is it possible for an App Extension (like ShieldAction handler) to open a Universal Link or trigger an external app, such as Safari, even though it is not the foreground app? Entitlements for App Extensions: Are there any specific entitlements or permissions required to allow an app extension (ShieldAction handler) to open Universal Links or perform actions like opening Safari from the background? App Visibility and State: How can I ensure that my app is in the right state (visible/active) and has the necessary entitlements to trigger these actions when running in the context of an app extension? Workaround: If this behavior is restricted due to app extension limitations, what would be the recommended workaround to handle launching external apps (like Safari) or Universal Links from within an app extension?
Replies
9
Boosts
0
Views
474
Activity
Jul ’25
Extend Family Control permission to app's extensions
I have tried multiple time through multiple channels and you have yet to respond to my request. I am developing an App on xcode APP Bundle ID: garymdmd.MediaPace Apple ID: 6740823496 Apple has granted me distribution use of the Family Control/Screentime module for my main app. According to your engineer's post here: https://developer.apple.com/forums/thread/764919 That permission should be extended to your extensions that are part of the app. When you try to setup the extension identifiers they do not show the "added capabilities" column that sow sup when getting permission for the main app so you are not able to endow the extension with these permissions which seem to be needed to work with the app. I am trying to add these bundle identifier extensions: garymdmd.MediaPace.ScreenTimeMonitorDuo garymdmd.MediaPace.DeviceActivityReport Can you please tell me how to get this to work or to add permissions to these extensions. I have sent in the request form multiple times (here - https://developer.apple.com/contact/request/family-controls-distribution) and Apple simply writes back that I have permission after a few weeks but nothing changes for the extension capabilities.
Replies
2
Boosts
0
Views
164
Activity
Jun ’25
Family Control Entitlements not recognized when distributing
I have been approved for family controls entitlements and see them in my apple certificates for my bundle identifier. I see them listed for Distribution in my Runner, however, when I try to distribute I get the error that I do not have the right permissions. Do I need to get the entitlements for each extension I have as well? I have three extensions that use the family controls.
Replies
1
Boosts
0
Views
157
Activity
May ’25
StoreKit2, IAP not instantly shared with Family
Hey folks! In one of our apps we're using the FamilyControls framework to manage the screentime for the child. The app requires the Guardian to activate a subscription on his/her device to enable the functionality for the Child on the child device. We're currently using StoreKit 2 to get notified when there is an active subscription. The issue we're seeing (and our users) is that an activated subscription isn't instantly propagated to the Family members, in this case the device belonging to the child. Is this a known bug, and are the possible any workarounds? Currently we have to ask our users to "Restore Purchase" or wait minutes/hours for the app to active, which isn't a viable solution. We want it to "just work" :) Sincerely, César Pinto Castillo Ambi Studio
Replies
3
Boosts
0
Views
122
Activity
May ’25
Need com.apple.developer.managed-settings entitlement
Hello, I already have got approval from Apple for com.apple.developer.family-controls entitlement When I am building my app, there is one part where I need to check the list of applications which I have blocked with my app. To get the list I have to have com.apple.developer.managed-settings entitlement ... Now how and where show I get hold of it ? I already got permission for Family Control, how do I get hold of this now ?
Replies
5
Boosts
0
Views
220
Activity
Jul ’25
Profile doesn't support Family Controls (Development).
Hi there! I've been getting this error when I've checked multiple times that I've included the right entitlements as well as provisiong profile. My one concern is that perhaps I'm unable to submit to internal or external TestFlight with Family Controls (Development) and need the one for distrubution, but have yet to submit my appplication for this ability. If anyone has any inisght into this issue lmk!
Replies
1
Boosts
0
Views
204
Activity
Jul ’25