The Problem The Family Activity Picker shows only the child's app categories on the guardian's/parent's device. The application names from the child's device are not showing on the guardian's/parent's device. The authorization is done on the child's device via try await AuthorizationCenter.shared.requestAuthorization(for: .child) Usage of the family activity picker on the guardian's/parent's device struct ContentView: View { @State private var isPresented = true @StateObject private var familyControlsHelper = FamilyControlsHelper.shared var onClose: () -> Void var body: some View { ZStack { Color.black.opacity(0.1).ignoresSafeArea() } .familyActivityPicker( isPresented: $isPresented, selection: $familyControlsHelper.familyActivitySelection ) .onChange(of: isPresented) { _ in if !isPresented { onClose() } } } } IMPORTANT Both devices are real (not simulators), and the app has granted distribution Family Controls entitlement. Question Is this the expected behavior? Or the child's app should appear on the guardian's device? Thanks.

I'm stuck in an impossible situation with DeviceActivityReportExtension on iOS 18. THE ISSUE: Configuration that works on device (iOS 18.2): Info.plist has only NSExtensionPointIdentifier Swift code uses u/main attribute App installs and runs perfectly Extension works correctly App Store validation FAILS: "Missing NSExtensionPrincipalClass" Adding NSExtensionPrincipalClass (as validation requests): Device installation FAILS with Error 3002 Error says: "NSExtensionPrincipalClass key is not allowed for this extension point" Cannot test on device Validation would likely pass ENVIRONMENT: Xcode 16.2 iOS 18.2 Extension point: com.apple.deviceactivityui.report-extension EVIDENCE IT'S WIDESPREAD: Apple Forums (3 days ago): https://developer.apple.com/forums/thread/812380 Stack Overflow (1+ year): https://stackoverflow.com/questions/77866230/ ROOT CAUSE: iOS 18 changed this extension to use u/main pattern (no NSExtensionPrincipalClass needed). App Store validation hasn't been updated and still expects iOS 17 configuration. WHAT I'VE TRIED: ✅ All deployment targets set to iOS 18.3 ✅ Code follows Apple's WWDC 2022 guidance ✅ All entitlements correct ✅ Info.plist validated ✅ Clean builds ✅ Works perfectly on device No configuration satisfies both device runtime AND App Store validation. Has anyone successfully uploaded an app with DeviceActivityReportExtension to TestFlight on iOS 18? Any workarounds? This is blocking TestFlight deployment completely.

After transferring the App ownership to a different account, if you update the app on iOS, two identical apps will show up in Settings > Screen Time. Users can't control the blocking settings from before the update - the only fix is to restart the phone. After the next execution of manageStore.shield.applications, users still can't manually disable the restrictions - their only option is to uninstall and reinstall the app. I believe this is related to how Screen Time API's authentication works - it's not just tied to the app's bundle ID, but also linked to the developer account's organization ID. Any suggestions for a clean solution that would allow smooth app updates after the transfer without running into these issues?

Hi everyone, I'm hoping someone can share their experience or offer advice on entitlement request timelines. I previously had two bundle IDs approved for an app I'm testing via TestFlight - both were approved within a few days. I recently submitted a request for a third bundle ID (JMSHRM8W5J), and after realizing I may not have included enough detail, I submitted a follow-up request (XS2QYC59UU) with more context. It's now been almost three weeks, which is significantly longer than my earlier approvals - though I recognize some of that time included the holidays. A few questions for the community: Has anyone experienced longer wait times for additional entitlements on an existing project (with approved entitlements)? Did submitting a second request help or potentially slow things down? Is there anything I should include in a request to improve chances of quick approval? Any insight would be appreciated. Thanks!

Since the iOS 26.2 update, we have been experiencing anomalous behavior with the DeviceActivityMonitor extension when utilizing the ScreenTime API. Specifically, we are receiving the eventDidReachThreshold event within a few minutes of initiating monitoring, despite configuring a high usage limit. The process of turning off Screen Time -> restarting the device -> turning on Screen Time does not work. Any ideas? Thanks Filed Feedback Assistant: FB21560904

Hello, I'm experiencing a significant delay getting the Family Controls entitlement approved for my Shield Configuration Extension, and I'm hoping someone here can help or has experienced something similar. Background: I'm developing an app that uses the Screen Time API with Family Controls. My main app bundle (lukedev.Bloka) was approved for Family Controls (Distribution) and works perfectly. The Problem My Shield Configuration Extension (lukedev.Bloka.Shield) has been stuck waiting for approval for over 2 weeks: Request ID: 6C8LD22UVM Submitted: November 20, 2025 Status: Still "Submitted" Current State: Only shows "Family Controls (Development)" in capabilities What I've Tried ✅ Submitted entitlement request via the proper channels ✅ Contacted Apple Developer Support (case #102762028251) ✅ Verified the main app has full Family Controls approval ✅ Deleted and regenerated all provisioning profiles multiple times ✅ Confirmed the App ID configuration is correct in the Developer Portal The Issue Without Family Controls (Distribution) approval for the Shield extension, I cannot: Test the complete app functionality on physical devices Submit the app to App Store Connect Move forward with development The error I'm getting during provisioning: Provisioning profile failed qualification Profile doesn't include the com.apple.developer.family-controls entitlement Questions Has anyone experienced multi-week delays for Shield extension entitlements? Is this normal? Should Shield extensions automatically inherit entitlements from the main app, or do they really require separate approval? The documentation isn't clear on this. Are there any known workarounds to test Shield Configuration Extensions during development while waiting for distribution approval? How can I escalate this request? Developer Support initially told me I already had approval (for the main app) but didn't address the extension's separate bundle ID. Technical Details Xcode: 16.2 Target: iOS 18+ Main App: Family Controls (Distribution) ✅ Approved Shield Extension: Family Controls (Development only) ❌ Stuck Why This Matters The Shield Configuration Extension is a core component of Screen Time API apps - it's not optional. Without it, the app cannot properly display blocking interfaces. The fact that it requires a separate 2+ week approval process (after the main app was already approved) seems like a significant oversight in Apple's review process. Has anyone successfully navigated this situation or found a way to expedite the review? Any help or insights would be greatly appreciated! Thanks, Luca

General: Forums topic: Family Controls Forums tag: Family Controls Configuring Family Controls documentation Requesting the Family Controls entitlement documentation Screen Time Technology Frameworks documentation FamilyControls documentation What's new in Screen Time API video Meet the Screen Time API video

We're building a parental control app using FamilyControls (.child authorization). Our architecture: Parent sends pause command → Firestore + FCM Child receives push → NotificationService Extension triggers main app Main app sets ManagedSettings Shields Problem: If child disables Notifications in Settings and force-quits the app, we cannot enforce Shields. What we've tried: Firestore Realtime Listener (works only when app is running) DeviceActivityMonitor (intervalDidStart/End only triggers at schedule boundaries, eventDidReachThreshold requires explicit app selection via FamilyActivityPicker) Question: Is there a recommended approach for parental control apps to reliably enforce Shields when the child has disabled notifications? Or is this a known limitation?

Issue: The search functionality in FamilyActivityPicker has disappeared on iPadOS 26.0+. This feature was working in previous versions but is now missing. Framework: FamilyControls Expected: Search bar should be available in FamilyActivityPicker to help users find apps quickly. Actual: Search functionality is completely missing. Impact: Makes app selection difficult for users with many installed apps. Is this a known issue? If it's a bug, please address it in an upcoming update. If intentional, guidance on alternatives would be appreciated. Thank you.

Hello! I am experiencing some strange bugs around DeviceActivityEvents: When creating a DeviceActivityEvent we can assign a threshold and applicationTokens. The idea is, that after the user has spent said threshold on said apps, eventDidReachThreshold is called. includesPastActivity is set to false. On iOS 26 however, it happens (quite reliably after updating to a new beta seed) quite often that eventDidReachThreshold is called immediately (after a couple of seconds) instead of waiting for the threshold to be met. Is anyone else seeing similar issues on iOS 26? Only workaround I have found is to ask users to re-grant Screen Time permissions. This only holds for about two weeks though or at most until the next iOS 26 beta update is installed. Feedback filed under: FB18061981 FB18927456

Hi everyone, I submitted this feature request through Apple’s Feedback Assistant and wanted to share it here, because many families run into the same issue and Apple prioritizes features based on the number of reports they receive. Current limitation: Screen Time only allows one single Downtime period per day for child accounts. For families with separate school hours and bedtime, this is very impractical. My real-world use case: • Downtime 1: 08:00–13:00 (school) • Downtime 2: 20:00–06:00 (bedtime) Both serve completely different purposes, but are not possible to combine with the current system. My suggestions to Apple: Support multiple Downtime periods per day for child accounts. Allow custom exceptions per Downtime block (e.g., allow Phone app). Provide more flexibility overall for families using Screen Time. If you would benefit from this too, it would be great if you could submit the same request via the Feedback app – the more reports Apple receives, the higher the chance for implementation. My Feedback ID: FB21265678 Thank you! 🙏 Hallo zusammen, ich habe über die Feedback-App einen Vorschlag an Apple eingereicht und wollte ihn hier teilen, weil viele Familien dasselbe Problem haben und Apple mehr Rückmeldungen braucht, um das Thema zu priorisieren. Aktuelles Problem: In Bildschirmzeit kann für Kinder aktuell nur eine einzige Auszeit pro Tag eingerichtet werden. Für Familien mit getrennten Schul- und Schlafenszeiten ist das extrem unpraktisch. Mein Anwendungsfall: • Auszeit 1: 08:00–13:00 (Schule) • Auszeit 2: 20:00–06:00 (Schlafenszeit) Beides erfüllt unterschiedliche Zwecke, ist aber nicht kombinierbar. Mein Vorschlag an Apple: Mehrere Auszeiten pro Tag für Kinderaccounts. Pro Auszeit eigene Ausnahmen festlegen (z. B. Telefon erlauben). Allgemein mehr Flexibilität im Screen-Time-System für Familien. Wenn ihr das ebenfalls hilfreich findet, wäre es super, wenn ihr es auch über die Feedback-App meldet – je mehr, desto besser. Feedback-ID meines Vorschlags: FB21265678 Danke euch! 🙏

Is it possible to change the title "Choose Activites" and also remove the search on the FamilyActivityPicker?

Hello, I'm currently experiencing an issue with the DeviceActivityMonitor extension in my code, specifically with the eventDidReachThreshold callback. I'm hoping to get some insights into why this problem occurs and how to resolve it. Problem: Issue 1: The eventDidReachThreshold callback is not triggering as expected. It appears that the callback is not being invoked when the threshold is reached. Issue 2: After a few seconds, the eventDidReachThreshold callback starts to trigger multiple times. This unexpected behavior is causing problems in my code, as it results in incorrect actions being taken. iOS version: iOS16.7.2 and iOS17.1 Xcode version: 15.0.1 Swift version: 5.9 Here is my code to start the monitoring: func startMonitoring() { var startTime : DateComponents = DateComponents(hour: 0, minute: 0) let endTime : DateComponents = DateComponents(hour: 23, minute: 59) /// Creates the schedule for the activity, specifying the start and end times, and setting it to repeat. let schedule = DeviceActivitySchedule(intervalStart: startTime, intervalEnd: endTime, repeats: true, warningTime: nil) /// Defines the event that should trigger the encouragement. let event = DeviceActivityEvent(applications: socialActivitySelection.applicationTokens, categories: socialActivitySelection.categoryTokens, webDomains: socialActivitySelection.webDomainTokens, threshold: DateComponents(minute: 2)) let events: [DeviceActivityEvent.Name: DeviceActivityEvent] = [.socialScreenTimeEvent : event] do { activityCenter.stopMonitoring([.socialScreenTime]) /// Tries to start monitoring the activity using the specified schedule and events. try activityCenter.startMonitoring(.socialScreenTime, during: schedule, events: events) } catch { /// Prints an error message if the activity could not be started. print("Could not start monitoring: \(error)") } } If there are any known workarounds or potential solutions, please share them. Thank you for your help in resolving this problem.

class ShieldActionExtension: ShieldActionDelegate { override func handle(action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void) { // Handle the action as needed. switch action { case .primaryButtonPressed: if let url = URL(string: "blockfocusapp://") { let extensionContext = NSExtensionContext() extensionContext.open(url, completionHandler: nil) } // completionHandler(.defer) case .secondaryButtonPressed: let userDefaults = UserDefaults(suiteName: "group.in.appsquare.FocusApp.shieldExt") userDefaults?.set(false, forKey: "shouldOpenMainApp") completionHandler(.defer) @unknown default: fatalError() } } override func handle(action: ShieldAction, for webDomain: WebDomainToken, completionHandler: @escaping (ShieldActionResponse) -> Void) { // Handle the action as needed. completionHandler(.close) } override func handle(action: ShieldAction, for category: ActivityCategoryToken, completionHandler: @escaping (ShieldActionResponse) -> Void) { // Handle the action as needed. completionHandler(.close) } } I want to be able to open my app from ShieldActionExtension

Hello, I think it is quite a common use-case to open the parent app that owns the ShieldActionDelegate when the user selects an action in the Shield. There are only three options available that we can do in response to an action: ShieldActionResponse.none ShieldActionResponse.close ShieldActionResponse.defer It would be great if this new one would be added as well: ShieldActionResponse.openParentApp While finding a workaround for now, the problem is that the ShieldActionDelegate is not a normal app extension. That means, normal tricks do not work to open the parent app from here. For example, UIApplication.shared.open(url) does not work because we can’t access UIApplication from the ShieldActionDelegate unfortunately. NSExtensionContext is also not available in the ShieldActionDelegate unfortunately, so that’s also not possible. There are apps however, that managed to find a workaround, in my research I stumbled across these two: https://apps.apple.com/de/app/applocker-passcode-lock-apps/id1132845904?l=en-GB https://apps.apple.com/us/app/app-lock/id6448239603 Please find a screen recording (gif) attached. Their workaround is 100% what I’m looking for, so there MUST be a way to do so that is compliant with the App Store guidelines (after all, the apps are available on the App Store!). I had documented my feature request more than 2 years ago in this radar as well: FB10393561

Hello, I’m running into an issue with the Family Controls (Distribution) entitlement not being included in my App Store Connect provisioning profiles. Here’s the situation: •Both my main app and its Screen Time extension have been approved for Family Controls (Distribution) In Certificates, Identifiers & Profiles → Identifiers, I can clearly see that the capability Family Controls (Distribution) is enabled for both App IDs. However, when I generate a new provisioning profile (either manually or via Xcode), the resulting .mobileprovision file’s Entitlements section does not include the Family Controls (Distribution) entitlement. As a result, building for distribution or archiving fails to recognize that entitlement, even though everything looks correct in the Developer Portal. But the missing entitlement persists. How can I successfully generate a distribution provisioning profile that includes Family Controls (Distribution)? Thanks in advance for any guidance — this seems like a subtle configuration issue, and I’d love to hear how to get over it. I can provide the Team ID and bundle ID upon request. STEPS TO REPRODUCE I’ve tried: •Regenerating both App IDs and provisioning profiles •Revoking and re-creating distribution certificates •Cleaning derived data and re-downloading profiles from Xcode Every time, creating a profile for App Store Connect will fail to include the capabilities the app has been approved for.

I’m developing an app that uses Family Controls to block other apps. I’ve already received approval from Apple for the entitlement, and everything works perfectly when I run the app from Xcode on a physical device. However, when I upload the same build to TestFlight, the app installs and runs, but the Family Controls functionality doesn’t work — it seems like the entitlement isn’t being applied in the TestFlight version. So I’d like to ask: 👉 Do Family Controls entitlements work automatically on TestFlight builds, or is there any additional step required to enable them?

Hi everyone, solo iOS dev here. I’ve built a small focus app (“Modo”) that uses Apple’s Screen Time APIs to help curb social-media overuse. In development everything works: FamilyActivityPicker for selection, a DeviceActivityMonitor extension for schedules, and ManagedSettings shields (plus uninstall guard only while “Blocked” is active). I requested the Family Controls distribution entitlement so I can ship, but my capability request has been pending for a while and I’m not sure what the usual path forward is. What I’ve already done • Submitted the capability request (Account Holder), describing the use case (self-control / digital well-being), user consent flow,. • Implemented app + DeviceActivityMonitor + ManagedSettingsUI extensions; verified the debug build has the right entitlements and behavior. • Regenerated profiles after the request; checked codesign entitlements on the built targets. • Filed a Developer Support ticket referencing the capability request. I really appreciate any timelines, examples, or advice you can share. If an Apple engineer needs specifics (Team ID, request number), I can provide them as well. Thanks in advance!

I'm developing a parental control app that needs to block adult/18+ websites using the Screen Time API. I've run into scaling issues with 'ManagedSettings.webContent.blockedByFilter`. Environment: iOS 18.x, real device (iPhone) ManagedSettings framework Screen Time permissions granted Current Behavior: The Question: Commercial parental control apps successfully block tens of thousands of domains. What API or architecture should I be using to scale beyond 30-50 domains? Approaches I'm considering: Safari Content Blockers (limited to Safari only) Multiple ManagedSettingsStore instances Network Extension / DNS filtering A different Screen Time API approach What's the recommended way to block large domain lists (1000-60000+) across all apps and browsers? Any guidance appreciated! //33 domains - Works perfectly let blockedSites: Set<WebDomain> = [ WebDomain(domain: "example1.com"), WebDomain(domain: "example2.com"), // ... 31 more domains ] store.webContent.blockedByFilter = .specific(blockedSites) // All 33 domains blocked successfully // 101 domains - Complete failure (no domains blocked at all) let blockedSites: Set<WebDomain> = [ WebDomain(domain: "example1.com"), // ... 100 more domains ] store.webContent.blockedByFilter = .specific(blockedSites) // No errors thrown, but ZERO domains are blocked

Our app uses a 24-hour DeviceActivityMonitor repeating schedule to send users notifications for every hour of screen time they spend on their phone per day. Notifications are sent from eventDidReachThreshold callbacks at 1, 2, 3, etc, hour thresholds to keep them aware of their screen time. We have recently received an influx of emails from our users that after updating to iOS 17.6.1 their DeviceActivityMonitor notifications are saying their screen time was much higher than what is shown in DeviceActivityReport and their device's Screen Time settings. These users have disabled "Share Across Devices" - but I suspect the DeviceActivityMonitor is still getting screen time from their other devices even though that setting is turned off. Has anybody else noticed this, understands what is causing this, or could recommend a fix that we can tell our users to do?