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

Hello, I requested "Family Controls (Distribution)" for one of my apps. I received email that the entitlement is granted and I can use it: Hello XXXX The entitlement for Family Controls (Distribution) has been assigned to your account, and you can now configure this capability for eligible apps. If you’re enrolled as an organization, Admins on your team can also use this capability. However, on the identifiers page, the status still shows as "No Requests". Additionally, I see nowhere any other indicator. I opened a case with the ID 102999908799 but didnt receive any response. Anybody knows what to do? Thank you.

It has been 20 days since we applied for Family Controls (Distribution) permission, but the status still shows as Submitted. Is there any way to expedite the review process?

Setup Parent device: FamilyActivityPicker with a selection created as FamilyActivitySelection(includeEntireCategory: true). The parent selects apps for an always-on block list. The selection is encoded with PropertyListEncoder and sent to our server. Child device: authorized with AuthorizationCenter.shared.requestAuthorization(for: .child). It receives the selection, decodes it, and immediately applies its application tokens. The shield stays on all day, with no schedule: let selection = try PropertyListDecoder().decode(FamilyActivitySelection.self, from: data) ManagedSettingsStore(named: .appBlock).shield.applications = selection.applicationTokensObserved Cases A and B use the same two physical devices with the parent and child roles swapped. In all cases, the Family Sharing group uses legacy Screen Time, because not every device is on iOS 27 and the redesigned Screen Time is not available. CaseParentChildOur app's shieldSystem Screen Time (set by parent)AiOS 27.0.1iOS 18.7.1BlocksBlocksBiOS 18.7.1iOS 27.0.1Does not blockBlocksCiOS 18.7.1iOS 18.7.1BlocksBlocksQuestions Is this a known issue in iOS 27.0.x? Could it be related to issue number 175437403 ("Screen Time restrictions might not apply to child accounts despite being configured"), which the iOS 27 release notes list as fixed? Should tokens selected on an iOS 18 parent device be enforced on an iOS 27 child device? Is there a workaround, or a way to detect that a shield was applied but is not being enforced?

I would like to propose a policy adjustment regarding Apple Wallet restrictions for child accounts (under 13) under Family Sharing. Current Limitation: Currently, Apple IDs for children under 13 are completely blocked from adding any cards to Apple Wallet. While restricting credit and debit cards for minors is a necessary measure for financial security and CoPPA compliance, this blanket restriction also blocks transit cards (such as Suica, T-money, etc.). The Problem: In regions with advanced public transit infrastructures, many children rely on digital transit cards for daily commutes to school and academies. Because Apple Wallet blocks transit cards on child accounts—even on Apple Watch via Family Setup—children are forced to carry physical transit cards, leading to frequent losses and damages. Proposed Solution: Differentiate Transit from Financial Cards: Maintain strict blocks on credit/debit cards for accounts under 13, but grant an exception for Transit Cards. Family Sharing Integration: Require Parental Approval through Family Sharing for any transit card addition or balance top-up, ensuring full parental control and safety. By introducing this exception, Apple can greatly improve the usability of Apple Watch Family Setup for families while maintaining high safety standards. I have submitted this feedback via Feedback Assistant under FB25261157. If you agree or are facing similar design constraints, please upvote this thread or reference the FB number in your own feedback submissions. Thank you.

PLEASE ADDRESS ASAP: Muse is #1 on the App Store and Facebook is one of the most blocked apps for Screen Time. This is affecting a vast number of people. Description: When a user blocks the Facebook app in any screen time app, iOS automatically blocks Meta's Muse app too. Every single time. There is no way for the user or the developer to prevent it, allowlist it, or even detect that it happened. Muse shows Apple's generic blocked-app "Restricted" screen instead of the screen time app's own design, so the user cannot tell who blocked it or why. This is the worst possible combination of apps: Facebook is one of the most-blocked app across screen time apps. Muse ("Muse from Meta") is currently the #1 app on the App Store. A huge and fast-growing number of users block Facebook and silently lose the world's most popular new app. Muse launched Sept 8, 2026 and adoption is still climbing -- the affected population grows every day. There is NO workaround whatsoever: Users cannot allowlist Muse: it does not appear in Settings > Screen Time > Always Allowed. Developers cannot prevent it: the Screen Time API offers no opt-out; the extra block is applied by iOS itself. Developers cannot detect it: Muse's token (listed separately in FamilyActivityPicker) corresponds to no real identity anywhere else. Developers cannot customize it: their ShieldConfiguration is never consulted -- Muse gets Apple's generic shield UI. Users cannot even block Muse on purpose: shielding Muse's own token is a silent no-op. Screen Time usage statistics are also wrong -- Muse usage is recorded as "Facebook." This Screen Time bug renders screen time apps effectively unusable if users want to block Facebook and use Muse, which is extremely common. How can we get this addressed as soon as possible? Feedback Assistant ticket: https://feedbackassistant.apple.com/feedback/25019832

Hello, I’m building an app that helps people spend less time on social media apps. For that, I make heavy use of Apple’s Screen Time APIs, such as ManagedSettings and FamilyControls. When an app is locked using a ShieldConfiguration, the user has to open my app in order to unlock it (e.g. enter a code). This is very cumbersome because no documented API exists to open the parent app (=my app) from the ShieldActionDelegate (also part of my app) when the user presses a button of the ShieldConfiguration. The ShieldActionDelegate callback just offers three options in its ShieldActionResponse: .none .defer .close .openParentApp is missing. We are working around this limitation by sending a local push notification that the user has to tap on. This has multiple drawbacks: It has to be ensured that notification permission has been granted. It has to be ensured that notifications can be delivered even while focus is enabled. Features such as Apple Intelligence notification summaries and notification prioritization can heavily delay delivering notifications and thus frustrate the user. Neither my users nor myself do understand why this is not possible in a smoother way, at least according to the documentation. There are 3rd party apps that have such functionality, they can directly open their own app from a button press in the Shield, see here: https://apps.apple.com/us/app/applocker-passcode-lock-apps/id1132845904 It would be great if Apple could level the playfield for all developers and document how this is achievable, because technically it clearly is. Thanks a lot and have a great day!

An app using FamilyControls (.individual) computes a single daily number on device from the user's own DeviceActivity data. Can that number be sent to a server so the user can compare it with friends? No app tokens, bundle IDs, or per-app times would leave the device. Is this allowed under DPLA section 3.3.3(P), which limits sharing usage data "beyond … the individual and their device"?

Dear Screen Time Team! The current 6 MB memory limit for the DeviceActivityMonitor extension no longer reflects the reality of modern iOS devices or the complexity of apps built on top of the Screen Time framework. When Screen Time APIs were introduced with iOS 15, hardware constraints were very different. Since then, iPhone performance and available RAM have increased significantly…but the extension memory limit has remained unchanged. My name is Frederik Riedel, and I’m the developer of the screen time app “one sec.” Our app relies heavily on FamilyControls, ManagedSettings, and DeviceActivity to provide real-time interventions that help users reduce social media usage. In practice, the 6 MB limit has become a critical bottleneck: The DeviceActivityMonitor extension frequently crashes due to memory pressure, often unpredictably. Even highly optimized implementations struggle to stay within this constraint when using Swift and multiple ManagedSettings stores. The limit makes it disproportionately difficult to build stable, maintainable, and scalable architectures on top of these frameworks. This is not just an edge case…it directly impacts reliability in production apps that depend on Screen Time APIs for core functionality. Modern system integrations like Screen Time are incredibly powerful, but they also require a reasonable amount of memory headroom to function reliably. The current limit forces developers into fragile workarounds and undermines the robustness of apps that aim to improve users’ digital wellbeing. We would greatly appreciate if you could revisit and update this restriction to better align with today’s device capabilities and developer needs. Thank you for your continued work on Screen Time and for supporting developers building meaningful experiences on top of it. Feedback: FB22279215 Best regards, Frederik Riedel (one sec app)

I'm developing a digital wellbeing app using FamilyControls and DeviceActivity. The core functionality of the app is to show the user their per-application Screen Time usage, including the application identity and duration (for example, Instagram — 1h 30m, YouTube — 45m). I understand that on iOS 26.4+, AuthorizationStatus.approvedWithDataAccess and DeviceActivityData.activityData(filteredBy:using:) provide access to non-tokenized application usage data. I also understand the current Apple documentation states that customer installations can only obtain approvedWithDataAccess on devices located in the EU with an Apple Account configured to an EU country or region, and that outside the EU the authorization status never becomes approvedWithDataAccess. My app and test device are based in Kazakhstan. My question is not about bypassing Apple's privacy model or implementing an undocumented workaround. I would like to know whether there is any official path for a legitimate third-party Screen Time / digital wellbeing app to obtain this data outside the EU, for example: an additional entitlement; a developer approval or application process; a regional exception; an alternative Apple-supported API; or any other official mechanism. We already have the Family Controls distribution entitlement approved and have enabled the Family Controls App and Website Usage capability. If no such mechanism exists, I would appreciate confirmation that the EU restriction is currently absolute for customer installations and that there is no additional entitlement or approval process available for developers outside the EU. The reason I am asking is that per-application usage is a core part of the application's functionality, so I want to make sure I am not missing an official Apple-supported option before designing around this limitation.

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?

I’m evaluating an iOS app that uses Family Controls / DeviceActivity for an adult user’s voluntary personal device-management and digital-wellbeing goals. The app would also have an optional social competition feature where friends participate in fantasy-style leagues based on completion of their individual digital-wellbeing goals. I’m trying to understand the restrictions in Apple Developer Program License Agreement Section 3.3.3(P), specifically whether a privacy-preserving result derived locally from Family Controls / DeviceActivity can leave the device when the underlying usage data never does. I’m considering three architectures: A — Locally derived fantasy score DeviceActivity information is evaluated entirely on-device and converted locally into an abstract score. The server receives only: fantasy_points = 82 No Screen Time duration, app identity, website activity, bundle identifier, or underlying usage information leaves the device. B — Binary goal completion A user creates a private usage goal, such as remaining below their chosen daily device-usage threshold. The goal is evaluated entirely on-device. The server receives only: goal_completed = true The server then awards predetermined fantasy points. It never receives the underlying Screen Time value. C — Opaque challenge completion A user privately selects an app/activity goal. DeviceActivity evaluates the threshold locally. The server receives only: challenge_id = C928 completed = true The server knows C928 is worth a predetermined number of points, but does not receive the selected app identity, usage duration, Screen Time quantity, or other underlying DeviceActivity information. In all three approaches, raw Screen Time duration, per-app usage duration, application/bundle identity, website activity, DeviceActivity reports, and underlying historical usage records would remain on-device. Friends would only see fantasy points, matchup results, standings, and/or achievements. My question: Under Section 3.3.3(P) and the Family Controls requirements, are any of A, B, or C permitted? More specifically, does Apple consider an abstract score, boolean goal-completion result, or opaque challenge-completion result to itself be “device or usage data” when it was derived from Family Controls / DeviceActivity? If none of these architectures are permitted, is there a supported privacy-preserving architecture that allows an on-device DeviceActivity evaluation to affect a server-side social or multiplayer feature without transmitting the underlying device/usage information? I’m trying to establish the compliant architecture before development rather than build around an incorrect interpretation of the Family Controls requirements.

I'm developing an iOS parent-child app that uses FamilyControls and DeviceActivity. Before distribution, I need to test AuthorizationCenter.shared.requestAuthorization(for: .child), including the guardian approval flow. So far I have tested .individual, which authenticates the device owner and does not exercise the child flow. Apple Developer Program Support directed me to this forum. What is the Apple-supported way to test this flow in this situation? Is there an Apple-supported test-only account or setup for this flow without using a child's personal Apple Account? If so, where are its requirements documented? If not, what is the recommended alternative? Can Sandbox Apple Accounts used for StoreKit Family Sharing tests be used to sign in to iCloud and test FamilyControls .child, or are they limited to purchase testing? Is there a supported simulator or other test method for guardian approval, or must this be verified using a child Apple Account in a real Family Sharing group on physical devices? I want to follow Apple's account rules and test the actual parental authorization path before distribution. References to official guidance would be appreciated.

When I tap on one of the buttons in the ShieldAction extension I want to close the shield and open the parent app instead of the shielded app. Is there any way of doing this using the Screen Time API? class ShieldActionExtension: ShieldActionDelegate {      override func handle(action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void) {     // Handle the action as needed.           let store = ManagedSettingsStore()               switch action {     case .primaryButtonPressed:       //TODO - open parent app       completionHandler(.defer)     case .secondaryButtonPressed:       //remove shield       store.shield.applications?.remove(application)       completionHandler(.defer)         @unknown default:       fatalError()     }   }   }

I’m designing a voluntary self-control/safety app for adults using FamilyControls/ManagedSettings with individual authorization. When a user voluntarily starts a timed protection session, can the app hide or block itself for the duration of that session so the user cannot easily locate the app and uninstall it? When the DeviceActivity schedule ends, could an extension remove that restriction so the app becomes available again automatically? I understand that an adult may ultimately be able to revoke Family Controls authorization through Settings. I’m specifically asking whether the app itself can be hidden/blocked during the active session.

Hi everyone, I'm developing an iOS app that uses Apple's Family Controls / Screen Time APIs. I've encountered a strange issue when testing with multiple devices: The app works normally on the first device. When I install the same TestFlight build on a second device, the user completes the Family Controls authorization successfully. Immediately after authorization, an error appears: "Family Controls is only available for one application." After dismissing the error, the app still works normally. Screen Time / Shield functionality also appears to work as expected. The issue seems to occur specifically when authorizing the app on a second device. Has anyone encountered this error before?

My app receives AuthorizationStatus.approvedWithDataAccess when run from a development build, but the identical code returns only .approved when run from a TestFlight / App Store (distribution) build. I'm trying to determine how to get the com.apple.developer.family-controls.app-and-website-usage entitlement granted for distribution, since enabling the capability in the portal has not been sufficient. Environment Xcode 26.6 (17F113) iPhone 17, iOS 26.5.2 App uses FamilyControls + ManagedSettings, plus Screen Time extensions (Shield Configuration, Shield Action, Device Activity, Live Activity, Control). Entitlement in question: com.apple.developer.family-controls.app-and-website-usage (iOS 26.4+) What works vs. what doesn't Development build (installed from Xcode): AuthorizationCenter.shared.authorizationStatus == .approvedWithDataAccess. FamilyActivityData.shared.installedApplications returns real bundle IDs and display names. TestFlight / distribution build (same source, same device, same OS): authorizationStatus == .approved. installedApplications is empty. The only variable between the two is development vs. distribution signing. What I've already done Enabled Family Controls App and Website Usage on the main App ID and on every extension identifier in Certificates, Identifiers & Profiles. Confirmed the entitlement key is present in the app's .entitlements and is signed into the distribution build. Regenerated the distribution provisioning profiles after enabling the capability (Automatically Manage Signing), archived a fresh build, ran Validate App (passed), and uploaded to TestFlight. Installed the TestFlight build on-device and verified in Settings that Authorization is still .approved. What I found in Capability Requests Under Certificates, Identifiers & Profiles -> the App ID, only Family Controls (base) shows as Assigned, its info panel lists Entitlement Keys = com.apple.developer.family-controls only. There is no entry anywhere in Capability Requests for com.apple.developer.family-controls.app-and-website-usage. So it appears there is no account-level distribution grant for the App and Website Usage tier for a distribution profile to inherit, which would explain why the checkbox alone doesn't take effect at runtime in distribution. I already have the base Family Controls distribution entitlement (the app ships and runs fine); it is specifically the App and Website Usage tier that works only in development. My questions Does the app-and-website-usage tier require a separate distribution approval (beyond enabling the checkbox on the App ID)? If so, where is that request submitted — it does not appear as a requestable item in my Capability Requests tab. Is there an additional step to make a distribution provisioning profile carry app-and-website-usage, given the base Family Controls entitlement already distributes correctly? For anyone who has shipped an app using .approvedWithDataAccess (iOS 26.4+): what did it take to get the usage tier active in an App Store/TestFlight build? I went through Developer Support; they confirmed the base Family Controls entitlement is on the account and directed me here for code-level guidance. Any pointers appreciated. Thank you!

I'm building a parental-control app using FamilyControls, ManagedSettings and DeviceActivity. A guardian can lock a child's device from their own device, and the child's device applies the shield locally. The delivery problem: a background push can't wake our app once it has been force-quit, which is common on a child's device, so guardian-initiated changes sit undelivered until the child happens to open the app. I've found that DeviceActivityMonitorExtension still receives intervalDidStart / intervalDidEnd while the app is force-quit, and that a URLSession request started from the extension completes. So I could register a couple of short recurring DeviceActivitySchedule activities purely to wake the extension every ~15 minutes, check the server, and apply the resulting shield. My question: is using DeviceActivitySchedule purely as a wake mechanism — where the schedule doesn't correspond to any real usage-monitoring window — a supported use of the API, or is it working by accident? I'd rather not build on it if it's the latter. Two smaller ones, if anyone knows: Is network activity from the monitor extension expected to be given time to complete, and is there a documented execution budget? I've seen reports here that the extension stops being invoked after some days without the host app launching. Is that expected, and what re-arms it? If there's a supported mechanism for this that I've missed, I'd much rather use it.

Hi, I am developing a Screen Time App and I am having issues with the ShieldConfigurationExtension (ShieldConfigurationDataSource). I know this extensions is sandboxed but I should be able to read data from the main app. I am using SwiftData as my database, but I am unable to initialize it in the extensions with an error indicating insufficient file permissions. I have App Group set up and I am able to share data using UserDefaults but that is just inconvenient. Is there any way I could just open the SwiftData in read only mode so that I could display the user some info on the shield? SwiftData Init: private func setupContainer() throws { let schema = Schema([ DogEntity.self, HouseEntity.self ]) // Use app group container if available let config: ModelConfiguration if let containerURL = FileManager.default.containerURL( forSecurityApplicationGroupIdentifier: "group.\(Bundle.app.bundleIdentifier ?? "")" ) { config = ModelConfiguration(schema: schema, url: containerURL.appendingPathComponent("default.sqlite")) } else { config = ModelConfiguration(schema: schema) } self.container = try ModelContainer(for: schema, configurations: [config]) } Error in extension: fault: Attempt to add read-only file at path file:///private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite read/write. Adding it read-only instead. This will be a hard error in the future; you must specify the NSReadOnlyPersistentStoreOption. error: (3) access permission denied error: Encountered exception error during prepareSQL for SQL string 'SELECT TBL_NAME FROM SQLITE_MASTER WHERE TBL_NAME = 'Z_METADATA'' : access permission denied with userInfo { NSFilePath = "/private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite"; NSSQLiteErrorDomain = 3; } while checking table name from store: <NSSQLiteConnection: 0x154100300> error: Store failed to load. <NSPersistentStoreDescription: 0x15402d590> (type: SQLite, url: file:///private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite) with error = Error Domain=NSCocoaErrorDomain Code=256 "The file “default.sqlite” couldn’t be opened." UserInfo={NSFilePath=/private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite, NSSQLiteErrorDomain=3} with userInfo { NSFilePath = "/private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite"; NSSQLiteErrorDomain = 3; } Any help appreciated 🙂

Hi there! My claim is that ManagedSettingsStore.TokenExpiryMessage API family doesn't work properly. I'm curious if that's only me, or others have also found it confusing, or non-working? I haven't found much public discussion about it, so this is the start of it. There are multiple confusing scenarios from my playing with it, but the simplest example is that ~30% of my apps NEW users get the ".tokensDidExpire" as soon as they approve Screen Time Permissions. Note that they haven't even seen the FamilyActivityPicker! FB23391495 is the feedback. Apple dev responded, but it didn't give confidence that my bug report was deemed correct (which can be fair!). However, it's current status is "Potential fix identified - For a future OS update," so maybe there is something to it. The API is likely quite difficult to get right, so I am happy to provide feedback on potential implementation so it's 100% solid.

We adopted the "com.apple.developer.family-controls.app-and-website-usage entitlement" to read usage through "DeviceActivityData.activityData(filteredBy:using:)" after "approvedWithDataAccess". It works as documented. We want to clarify the exclusivity issues. The consent sheet says, under "Limited Access", that Screen Time "will lose access to this data as only one app or service can access it at a time." On our test devices that is exactly what happens: after allowing, the Screen Time pane in Settings shows no new usage until the app is toggled off under Apps with Screen Time Access. Is this intended as permanent design, and is there any supported way for a third-party app and Apple's Screen Time to hold the data simultaneously?