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

App Store Connect returns the following message when the NSExtensionPointIdentifier key in the Info.plist of a Device Activity Monitor extension contains an invalid value: ITMS-90349: Invalid Info.plist value - The value of the NSExtensionPointIdentifier key, <value>, in the Info.plist of ".../PlugIns/...appex" is invalid. To resolve this issue, set NSExtensionPointIdentifier to com.apple.deviceactivity.monitor-extension. The expected Info.plist structure for a Device Activity Monitor extension is: <plist version="1.0"> <dict> <key>NSExtension</key> <dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.deviceactivity.monitor-extension</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).DeviceActivityMonitorExtension</string> </dict> </dict> </plist> After you apply this fix, build and archive your app, then re-upload to App Store Connect to confirm the error is resolved.

I’m the owner of actifinder mobile app. Apple’s Screen Time ‘Limit Adult Websites’ setting is incorrectly blocking our website, including the homepage. ActiFinder is an outdoor activities platform for hiking, cycling, kayaking, skiing, events and similar activities and does not contain adult content. I believe our domain has been incorrectly classified as adult content. I’d like to have actifinder.com reviewed and removed from the adult-content block/classification. Could you please escalate this to the team responsible for Screen Time web-content filtering/domain classification?

Our app uses the Family Controls framework for individual (self) device management. Separately, it estimates how much a user scrolls from CoreMotion accelerometer data (CMSensorRecorder) with an on-device Core ML model. Today, no Screen Time data leaves the device. We'd like to add an opt-in feature where a user compares results with friends they explicitly invite, and we want to stay within DPLA section 3.3.3(P) ("You and Your Application may not share device or usage data received through the Family Controls Framework or otherwise, beyond … the individual and their device"). Is it acceptable to share, only with invited friends (opt-in), a daily scroll-distance estimate that is computed solely from accelerometer data and never uses DeviceActivity or other Family Controls data? On the device only, we could use DeviceActivityMonitor threshold events to calibrate our accelerometer-based estimate against that user's screen time (the calibration and the threshold data never leave the device). Would sharing the resulting estimate (for example, "estimated minutes") with invited friends count as sharing usage data received through Family Controls, and therefore not be allowed? Would sharing only an outcome derived on device from DeviceActivity threshold events (for example, win/lose or goal met/not met) count as sharing device or usage data under 3.3.3(P)? We understand App Review can't pre-approve features. We're looking for guidance on how to interpret this section.

Hi everyone, I’m the developer of one sec, an app used by a large number of users globally to reduce time spent on social media and to build healthier digital habits. Because of this, we rely heavily on Apple’s Screen Time / DeviceActivity / FamilyControls, ManagedSettings APIs – and unfortunately, we’re seeing increasingly severe issues in production that directly impact hundreds of thousands of real iOS users. During the past years, we have been busy filing dozens of feedback requests for different Screen Time issues – and there has been no response from Apple at all. Developer Relations might be able to "confirm" that the bugs are present and that they ended up with the right team – but they are never addressed, neither are workarounds provided. Instead, the situation gets worse and worse. iOS 26 introduced a series of heavy regressions (which have been reported via Apple’s official bug report tool "Feedback Assistant" on iOS 26 beta 1 in June 2025 – and have not been addressed 10 Months later). This is very frustrating for us as developers, but also for our end-users who run into these issues every day. In the end this impacts our ability to build an amazing product and hurts revenue (which affects both us and Apple). 1. DeviceActivity thresholds are not firing at all This affects both: our app’s usage of the API and Apple’s own Screen Time limits Radars: FB22304617, FB20526837, FB15491936, FB12195437, FB15663329, FB18198691, FB18289475, FB19827144 2. Screen Time usage data is clearly corrupted Websites showing hundreds of hours per week Up to ~20 hours per day of usage reported for a single domain Radars: FB22304617, FB17777429, FB18464235 3. DeviceActivity thresholds reaching threshold immediately Newly introduced with iOS 26 Reported on iOS 26 beta 1 in June No response so far / no workaround DeviceActivity calls didReachThreshold immediately after creating the DeviceActivityEvent – instead of waiting till the defined threshold is actually reached. Radars: FB13696022, FB18351583, FB21320644, FB18927456, FB18061981 4. Randomly Randomizing ApplicationTokens From time to time, and without consistency, Screen Time suddenly provides new, random, unknown tokens to my app in the ShieldConfigurationDataSource and ShieldActionDelegate. This has been reported on many times before here on the dev forms, many many years back already: https://forums.developer.apple.com/forums/thread/756440 https://forums.developer.apple.com/forums/thread/758325 https://forums.developer.apple.com/forums/thread/758325?answerId=793267022#793267022 Radars: FB14082790 and FB18764644 5. Moving Tokens from one ManagedSettingsStore to Another Removing an ApplicationToken from one SettingsStore and then adding it to another while the target app remains in foreground leads to the re-use of the ShieldConfiguration. Which can be wrong in many scenarios. It is not possible to request a re-request of the ShieldConfiguration in that scenario. Radar: FB14237883 6. Unable to Open Parent App (one sec) from Shield Many times, when a target app is blocked by a shield, the user wants to perform some action (e.g. to unlock more time for the target app via an intervention). That means, that somehow I have to forward the user from a ShieldActionDelegate back into my target app. Unfortunately, there’s no API for that. Many apps on the App Store rely on private API to achieve that, but that’s too risky for a popular app like one sec. Radar: FB15079668 7. Unable to Open Target App from an ApplicationToken When a user has completed an intervention within one sec, and they indend to to continue to the target app, there is no way that one sec can open the target app just from the token alone. Sure, there are URL schemes, but that means the user has to manually assign URL schemes to each ApplicationToken. That is not a very user friendly process (and in many cases impossible, because not every app registers URL schemes). It would be better if there was a way that my app could open a target app directly from an ApplicationToken, e.g. via an AppIntent that can be run on a button press. This way, the selected apps would remain fully private while still offering advanced functionality: struct OpenTargetAppIntent: AppIntent, OpenAppFromApplicationTokenIntent { func perform() { return .result(openAppFromApplicationToken: applicationToken) } } Radar: FB15500695 Summary Thanks a lot for taking the time to read my feedback. If you have any questions, please feel free to reach out to me any time. I’m always happy to provide more details, logs, and steps to reproduce in my radars / feedback requests or in-person in Cupertino. It would be extremely helpful if someone from the Screen Time / DeviceActivity engineering team could: Take a look at the listed radars. Work on bug fixes and be transparent about when fixes will be shipped. Provide workarounds in the meantime. We genuinely want to build great, reliable experiences on top of Screen Time – but in its current state, it’s becoming very difficult to depend on. – Frederik

A screen time app I'm making has started telling users that their limit was reached even when they're far below their limit for the day (sometimes even at 0 minutes for the day). This issue only started happening after upgrading my software to iOS 26.2. Is this happening to anyone else? If so how have you found any solutions or does anyone know of any changes that could be causing this? Any help would be appreciated.

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?

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!

We're building a Screen Time / mindful-pause app for iOS 26–27. The user adds a Shortcuts personal automation "When is Opened" that runs our App Intent. The intent passes the trigger app's Bundle Identifier (from the trigger output) and shows a short pause screen. When the user taps "Continue", we want to take them back into that app — only the one app they chose, only after they tap. Is there a supported API to open another installed app when the user taps Continue, given its bundle identifier from the Shortcuts trigger? A DTS reply in 2024 said there was no supported way (thread 740707). Has anything changed in iOS 26/27? (Related feedback: FB15500695.) If not, is it acceptable to open the chosen app via a URL scheme it registers in its Info.plist, including a third-party sign-in callback scheme, purely to bring it to the foreground? Many apps register no URL scheme. Is there a recommended pattern — e.g. handing control back to Shortcuts so the automation or the "Open App" action opens the trigger app — without the "App is Opened" automation firing again in a loop? What's the recommended way to avoid that re-fire? We currently ignore it for a short time window. A minimal sample project reproduces this (App Intent, pause screen, Continue using UIApplication.open). Happy to share it. Xcode 27.0 (27A266a), iOS 27.0 (24A446).

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)

Hello Appleians, Before purchasing an individual Apple Developer Program membership, I would like to clarify whether my intended use is supported. I will be the only developer and user, physically located in Türkiye. The app will run on my personal iPhone, without App Store or TestFlight distribution. My iPhone already displays Screen Time usage from my Mac through Share Across Devices. I will not install a collector on the Mac or monitor anyone else. Could you please clarify: Can an individual membership obtain both Family Controls and Family Controls App and Website Usage entitlements for development testing in Türkiye? Is ongoing, sole-user personal use permitted with a development provisioning profile? If not, which supported installation method permits this use in Türkiye? Can DeviceActivityData.activityData(filteredBy:using:) retrieve the shared Mac’s category durations without an app installed on that Mac? Under section 3.3.3(P), may the app upload daily category-duration aggregates to a private Cloudflare backend accessible only to me, and compare them with my own sleep and mood check-ins to flag changes from my personal baseline? The proposed system will not provide medical diagnosis or treatment, contain advertising, or collect messages, page titles or company content. Please distinguish technical development access from permission for ongoing personal use and off-device processing. Thank you.

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.

On iOS 26.4, I set a Screen Time passcode. However, when I go to Settings > Apps > [Our App] and turn off Screen Time Access for the app, the system asks for Face ID instead of the Screen Time passcode. As a result, Screen Time access can be disabled without entering the Screen Time passcode. Steps to Reproduce 1. Set a Screen Time passcode on iOS 26.4. 2. Open Settings > Apps > [Our App]. 3. Turn off Screen Time Access for the app. Expected Result The system should require the Screen Time passcode before allowing Screen Time access to be disabled. Actual Result The system asks for Face ID instead of the Screen Time passcode, and Screen Time access is disabled.

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.