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

SCREEN TIME API is reporting false positives to DeviceActivityMonitor extension in iOS 26.2 & 26.3
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
0
1
362
Jan ’26
Family Controls Distribution Entitlement Request Taking Longer Than Expected - Any Tips?
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!
2
0
836
Jan ’26
Screen Time issues after transferring App developer account ownership
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?
3
1
590
Jan ’26
iOS 18 DeviceActivityReportExtension fails TestFlight validation - No workaround exists?
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.
1
0
230
Jan ’26
Missing child's apps in the Family Activity Picker on the guardian's/parent's device
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.
0
0
69
Jan ’26
Guidance on implementing Declared Age Range API in response to Texas SB2420
I've spent the last few days researching the upcoming laws in Texas and other US states, and how these laws will impact on developers around the world. I want to share what I've learned so far with the community and get feedback on my current understanding. This post is not so much focused on a single API, but more of the bigger picture. Background The law essentially mandates that: (1) app store platforms implement age categorization and verification mechanisms, and (2) developers implement logic to listen to age categorization signals provided by the platform and respond accordingly. You can read the law itself here: https://capitol.texas.gov/tlodocs/89R/billtext/html/SB02420S.HTM Most people seem to be interpreting the law as follows: All developers who distribute apps in the USA are effectively required to implement the new APIs (required by Texas, not by Apple). The penalties are heavy, but it's unclear whether developers would actually be pursued and by whom (e.g. would someone seriously pursue an alarm clock app because it could be accessed by a minor?). Putting aside the ethical, privacy, and legal issues (and the damaging precedents this law sets), most people seem to agree that, from a technical perspective, this is a very silly way to implement age blocking (app store collects the info and passes it to dev, dev is responsible for blocking access). It would make way more sense for the platform to block the app directly for affected users (with optional API support for developers who wish to use it). However, I believe the law has specifically mandated that this is how they expect the system to work, so Apple's hands have been tied. Apple has basically complied with their obligations by providing the relevant APIs to developers. Because the law is vague and open-ended, there are a lot of legal and technical uncertainties about what developers actually need to do to be compliant. Understandably, Apple seems reticent to provide any guidance to developers that could be interpreted as legal advice. Apple's docs simply describe what the APIs do with no guidance on what the overall flow is meant to look like or how and when the APIs should actually be used in practice. Americans familiar with the political situation seem to think there's the possibility of an injunction before this law goes into effect, but that looks increasingly unlikely given that it's two weeks away. Developer solutions Many devs seem to be exploring two main workarounds, at least as temporary solutions: (1) Raise your app's rating to 18+. Putting aside the fact that Texas law would effectively be forcing developers to raise their global age rating (resulting in lost revenue that extends far beyond Texas), it remains unclear whether this solution is actually legally compliant, since the law specifically mandates that apps must implement logic to respond to signals from the platform. (2) Geo-block Texas. Again, it remains unclear if this is compliant because geo-blocking is not 100% accurate and it doesn't actually do what the law says you have to do. It also creates issues if you already have users in Texas, and it means performing additional privacy-hostile checks (i.e., detecting the user's location, even users who are not subject to the law). The DeclaredAgeRange API is actually pretty straight-forward to use – although there is still a lack of documentation on certain edge cases and it's difficult to test. In addition, the new APIs are only available in iOS 26.2, so it's unclear what you need to do if you're still supporting < iOS 26.2. Some people are of the opinion that developers can only reasonably respond to the signals that are available, thus pushing responsibility back to the platforms in regards to earlier OS versions. The API provides a bool (AgeRangeService.shared.isEligibleForAgeFeatures), which allows you to determine if the user is someone to whom age checks need to be applied. https://developer.apple.com/documentation/declaredagerange/agerangeservice/iseligibleforagefeatures I'm not 100% sure, but perhaps the simplest action you can take is to check this bool on launch and block access if it's true. In any case, it looks like this API will be very useful because it means we can avoid applying the checks in other jurisdictions and for grandfathered-in users without needing to implement custom geo-tracking code (albeit only in iOS 26.2+). To implement the API, my current thinking is that, on every launch, I should first check the above bool and, if it's true, do the following: (1) get the App Store age rating with let appStoreAgeRating = await AppStore.ageRatingCode ?? 18, (2) request the user's age with let ageRangeResponse = try await AgeRangeService.shared.requestAgeRange(ageGates: appStoreAgeRating), (3) check that the user has agreed to share their age, (4) check that lowerBound >= appStoreAgeRating, and (5) check that the verification method is not one of the self-declared methods. If this procedure fails, I should block access to the app and provide a link to Apple's support page: https://support.apple.com/en-us/122770 I stress, however, that this is just my current idea and there are some edge cases I'm unsure about. Other issues It is possible to do some basic testing of the API, but only using a sandbox App Store account on a physical device. From the Developer section in iOS Settings, you can select from a few different scenarios, like "Texas user aged 14 without parental consent", etc. There's also a whole separate aspect to this law relating to "significant updates". Everyone seems kinda confused about this, but it seems like the general idea is that, if your app's age classification changes in the future, the app should be responsive to that change. My current interpretation is that if I use the AppStore.ageRatingCode as the age gate (as described above) then that should allow me to comply, but I haven't really looked into this aspect of the law yet. There's also another aspect to this law requiring developers to revoke access to the app when requested by the parent. I have not looked into this yet, but as noted above, it doesn't make sense to me why this is the developer's responsibility given that the platforms already provide solid parental controls. Do I need to something else in addition to what I've sketched out above? It goes without saying, of course, that everything above is not legal advice, and I still have some gaps in my understanding. I would really appreciate any feedback on the above, perhaps with recommendations about better ways to approach this.
10
1
1.5k
Jan ’26
How to trigger ShieldConfigurationExtension?
On pressing the secondary button on my ShieldConfigurationExtension, I remove the shields by setting shields in the named ManagedStore to nil in my ShieldActionExtension. // ShieldActionExtension.swift let store = ManagedSettingsStore() store.shield.applications = nil store.shield.applicationCategories = nil Now after some duration I want to re-apply the shields again for which I do the following: // ShieldActionExtension.swift DispatchQueue.main.asyncAfter(deadline: .now() + unlockDuration) { [weak self] in self?.reapplyShields(for: sessionId, application: application) } private func reapplyShields(for sessionId: String, application: ApplicationToken) { store.shield.applications = Set([application]) } Followed by the completionHandler: // ShieldActionExtension.swift completionHandler(.defer) Now the expectation is ShieldConfigurationExtension should be re-triggered with store.shield.applications = Set([application]), however I see the default iOS screen time shield. This behavior is experience when the blocked app is running in the foreground. However, if I close and re-open the blocked app - the ShieldConfigurationExtension is trigerred again correctly. If I do a completionHandler(.none) instead, the overriden configuration method in ShieldConfigurationExtension is not triggered. How do I make sure ShieldConfigurationExtension is triggered if the blocked app is running in the foreground when the shields are re-applied again?
0
0
282
Jan ’26
Can't show screen time data
I am getting this error when I try to show device activity report view by this DeviceActivityReport(appsContext, filter: filter) Attempt to map database failed: permission was denied. This attempt will not be retried. I have taken access by this way. AuthorizationCenter.shared.requestAuthorization(for: .individual) Detailed errors: LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Attempt to map database failed: permission was denied. This attempt will not be retried.
0
0
199
Jan ’26
Family Controls (Distribution) Capability Request
Hello! I recently submitted a request for the Family Controls (Distribution) for my app, and I’d be super happy if i could have some information about how long this process usually takes so i can plan accordingly. It would help immensly since we want to ship the app as soon as possible. I submitted the request around a week ago. Is there anything I can do on my end to help the process move more smoothly? Thanks in advance!
0
0
273
Jan ’26
FamilyControls on Mac Catalyst — can’t authorize due to sandbox; does this make ManagedSettings/DeviceActivity unusable?
Hi DTS / Apple engineers, We’re attempting to extending our screen time app target to Mac Catalyst. On iOS, FamilyControls works as expected (AuthorizationCenter + FamilyActivityPicker, then ManagedSettings shields + DeviceActivity monitoring/reporting). On Mac Catalyst: The project builds with FamilyControls/DeviceActivity/ManagedSettings capabilities enabled. But attempting to request FamilyControls authorization (or present FamilyActivityPicker) fails at runtime. We see errors similar to: Failed to get service proxy: The connection to service named com.apple.FamilyControlsAgent was invalidated: failed at lookup with error 159 - Sandbox restriction. And our app stays authorizationStatus == .notDetermined, with the request failing. We saw an Apple engineer suggestion to “disable App Sandbox”, but Mac Catalyst apps appear to always be sandboxed, so we can’t disable it. Questions: Is FamilyControls authorization supported on Mac Catalyst today? If so, what entitlement/capability is required specifically for Catalyst/macOS? If FamilyControls auth cannot succeed on Catalyst, does that mean ManagedSettings shields and DeviceActivity monitoring/reporting are effectively unusable on Catalyst (since they depend on that authorization)? Is there an Apple‑recommended approach for a Catalyst “portal” app that mirrors an iOS child device’s restrictions, or is local enforcement on Catalyst intentionally unsupported? Any guidance (and any official docs that clarify current platform support) would be hugely appreciated.
0
0
133
Feb ’26
How to open main app from ShieldActionExtension?
Hi! I'm building a Screen Time management app using FamilyControls and ManagedSettings. When a user taps the primary button on a ShieldActionExtension, I need to open my main app to guide them through an intervention exercise. Other approved App Store apps like Jomo - Screen Time Blocker do exactly this: tapping their shield's primary button opens the main Jomo app directly. Screen recording: https://drive.google.com/file/d/15yubtTdTkFskGCIaAw_HGB57-boHPl3a/view?usp=sharing I've tried: URL schemes (UIApplication.shared.open() unavailable in extensions) Universal links Local notifications (works, but adds an extra tap) NSUserActivity Is there a supported API I'm missing? Or another accepted solution? Any guidance is appreciated.
0
0
203
Feb ’26
Shield Action Extension rejected by App Store Connect – Invalid NSExtensionPointIdentifier for ManagedSettingsUI
Hello, I’m using the Screen Time API / Family Controls in my iOS app Sobre and I’m having an issue submitting a new build to TestFlight. My app setup is as follows: Main app ID: com.balthazar.sobre App extensions: Device Activity Monitor: com.balthazar.sobre.deviceactivitymonitor Shield Configuration: com.balthazar.sobre.shieldconfiguration Shield Action: com.balthazar.sobre.shieldaction On the Apple Developer portal: Family Controls (Distribution) is enabled for: the main app ID com.balthazar.sobre and all 3 extension App IDs above. App Groups are also configured for the app and the extensions. New App Store provisioning profiles have been generated for the app and all 3 extensions and are used in the latest build. When I submit the build through App Store Connect (via Fastlane / EAS), validation fails only for the Shield Action extension with this error: Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.ManagedSettingsUI.shield-action-service, in the Info.plist of “Sobre.app/PlugIns/ShieldActionExtension.appex” is invalid. DeviceActivityMonitorExtension and ShieldConfigurationExtension are accepted without any issue. My questions: What is the correct expected value for NSExtensionPointIdentifier for a Shield Action extension using the Screen Time / ManagedSettings APIs? Are there any additional entitlements or capabilities (for example, related to Managed Settings) that must be explicitly enabled for the app or the Shield Action extension in order for this extension point to be accepted by App Store Connect? Given that Family Controls (Distribution) is already granted for the main app and all extensions, is there anything else that needs to be requested or configured on my account or App IDs to use a Shield Action extension? My goal is to use Screen Time / Family Controls properly to block distracting apps and present a custom Shield UI + actions for my users, while respecting all Apple policies. Thank you in advance for your help and guidance
1
0
220
Feb ’26
Extract raw Screen Time data? Security says it's 'expected'
Hi everyone, I have a question regarding the intended privacy limits of the DeviceActivityReportExtension. According to the documentation and the WWDC21 session "Meet the Screen Time API", this extension was created specifically to prevent the host application from accessing the user's underlying activity data (websites visited, app usage, screen time, etc). But I have found that my host app is actually able to reconstruct this raw activity data from the activity report. I am able to extract specific visited websites and app usage durations back into the main app. I reported this to Apple Security (Case ID: OE1100504480881 ), assuming it was a sandbox bypass. However, they closed the ticket stating that this is "expected behavior" and requires no fix. My question for Screen Time Engineers: Is the documentation incorrect? If my host app is expected to be able to read this data, is there a formal API we should be using instead of extracting it from the report extension? The current behavior contradicts the privacy limits described in the documentation, so I am confused if I should rely on this data access for my app features or if it will be patched later. Thanks.
1
0
379
Feb ’26
Screen time API can be disabled easily
We have developed a Parental/Self control app using Screen time API. We have used individual authentication to authorize the app, using the instructions here: https://developer.apple.com/documentation/familycontrols/authorizationcenter The problem is , that individual auth can be disabled easily , by the following steps: enter Settings app. in Settings app, click on the Parental/Self control app. click to disable screen time restriction. show the device owner's face/fingerprint. (or pin code) Why is that a problem: Parental control apps, or self-control apps, are about giving control to the software, To make it hard for the user to disable the restrictions. So using the flow I have introduced above, it's super-easy for a user to disable his Parental control restrictions, which misses the entire point of Parental/Self control idea. Furthermore, not only the user have the means to unlock his screen time restrictions, he also MUST have the means to unlock it. This makes Screen time (with individual auth) useless: I have a code ready to make a great parental control app for my clients, with amazing ideas, but I can't use the Screen time API unless this problem is fixed. Why child-parent auth is not enough: My clients are grownups people between ages of 15-40, that are interested in self-control, so they don't have iCloud child accounts. also, the child-parent auth solution forces my clients to give some control to other person, and my clients prefer their privacy. Some of them prefer self-control and not parental-control. What I suggest as a solution: 1: Give more options to users how to disable the Screen time restrictions. including: a second faceID / FingerPrint (that isn't the same as the one used to unlock the device) a second pin password. a string password 2: Give the users the option to choose to not have the device's owner Face/Finger/Pincode ID , as a method to disable the Screen time restrictions.
16
3
6.5k
Feb ’26
Family Controls Entitlement Request Pending Over 2 Weeks
Hello, Our team submitted a request for Family Controls entitlements for our main app and four related extensions. It has now been a little over two weeks since submission, and the request is still pending review. We wanted to check if there are any recommended steps we can take on our end to help move the process forward. Any guidance or tips from anyone who have recently gone through this process would be greatly appreciated. Thank you.
2
0
126
Feb ’26
SCREEN TIME API is reporting false positives to DeviceActivityMonitor extension in iOS 26.2 & 26.3
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
Replies
0
Boosts
1
Views
362
Activity
Jan ’26
Family Controls Distribution Entitlement Request Taking Longer Than Expected - Any Tips?
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!
Replies
2
Boosts
0
Views
836
Activity
Jan ’26
Screen Time issues after transferring App developer account ownership
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?
Replies
3
Boosts
1
Views
590
Activity
Jan ’26
iOS 18 DeviceActivityReportExtension fails TestFlight validation - No workaround exists?
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.
Replies
1
Boosts
0
Views
230
Activity
Jan ’26
Missing child's apps in the Family Activity Picker on the guardian's/parent's device
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.
Replies
0
Boosts
0
Views
69
Activity
Jan ’26
Guidance on implementing Declared Age Range API in response to Texas SB2420
I've spent the last few days researching the upcoming laws in Texas and other US states, and how these laws will impact on developers around the world. I want to share what I've learned so far with the community and get feedback on my current understanding. This post is not so much focused on a single API, but more of the bigger picture. Background The law essentially mandates that: (1) app store platforms implement age categorization and verification mechanisms, and (2) developers implement logic to listen to age categorization signals provided by the platform and respond accordingly. You can read the law itself here: https://capitol.texas.gov/tlodocs/89R/billtext/html/SB02420S.HTM Most people seem to be interpreting the law as follows: All developers who distribute apps in the USA are effectively required to implement the new APIs (required by Texas, not by Apple). The penalties are heavy, but it's unclear whether developers would actually be pursued and by whom (e.g. would someone seriously pursue an alarm clock app because it could be accessed by a minor?). Putting aside the ethical, privacy, and legal issues (and the damaging precedents this law sets), most people seem to agree that, from a technical perspective, this is a very silly way to implement age blocking (app store collects the info and passes it to dev, dev is responsible for blocking access). It would make way more sense for the platform to block the app directly for affected users (with optional API support for developers who wish to use it). However, I believe the law has specifically mandated that this is how they expect the system to work, so Apple's hands have been tied. Apple has basically complied with their obligations by providing the relevant APIs to developers. Because the law is vague and open-ended, there are a lot of legal and technical uncertainties about what developers actually need to do to be compliant. Understandably, Apple seems reticent to provide any guidance to developers that could be interpreted as legal advice. Apple's docs simply describe what the APIs do with no guidance on what the overall flow is meant to look like or how and when the APIs should actually be used in practice. Americans familiar with the political situation seem to think there's the possibility of an injunction before this law goes into effect, but that looks increasingly unlikely given that it's two weeks away. Developer solutions Many devs seem to be exploring two main workarounds, at least as temporary solutions: (1) Raise your app's rating to 18+. Putting aside the fact that Texas law would effectively be forcing developers to raise their global age rating (resulting in lost revenue that extends far beyond Texas), it remains unclear whether this solution is actually legally compliant, since the law specifically mandates that apps must implement logic to respond to signals from the platform. (2) Geo-block Texas. Again, it remains unclear if this is compliant because geo-blocking is not 100% accurate and it doesn't actually do what the law says you have to do. It also creates issues if you already have users in Texas, and it means performing additional privacy-hostile checks (i.e., detecting the user's location, even users who are not subject to the law). The DeclaredAgeRange API is actually pretty straight-forward to use – although there is still a lack of documentation on certain edge cases and it's difficult to test. In addition, the new APIs are only available in iOS 26.2, so it's unclear what you need to do if you're still supporting < iOS 26.2. Some people are of the opinion that developers can only reasonably respond to the signals that are available, thus pushing responsibility back to the platforms in regards to earlier OS versions. The API provides a bool (AgeRangeService.shared.isEligibleForAgeFeatures), which allows you to determine if the user is someone to whom age checks need to be applied. https://developer.apple.com/documentation/declaredagerange/agerangeservice/iseligibleforagefeatures I'm not 100% sure, but perhaps the simplest action you can take is to check this bool on launch and block access if it's true. In any case, it looks like this API will be very useful because it means we can avoid applying the checks in other jurisdictions and for grandfathered-in users without needing to implement custom geo-tracking code (albeit only in iOS 26.2+). To implement the API, my current thinking is that, on every launch, I should first check the above bool and, if it's true, do the following: (1) get the App Store age rating with let appStoreAgeRating = await AppStore.ageRatingCode ?? 18, (2) request the user's age with let ageRangeResponse = try await AgeRangeService.shared.requestAgeRange(ageGates: appStoreAgeRating), (3) check that the user has agreed to share their age, (4) check that lowerBound >= appStoreAgeRating, and (5) check that the verification method is not one of the self-declared methods. If this procedure fails, I should block access to the app and provide a link to Apple's support page: https://support.apple.com/en-us/122770 I stress, however, that this is just my current idea and there are some edge cases I'm unsure about. Other issues It is possible to do some basic testing of the API, but only using a sandbox App Store account on a physical device. From the Developer section in iOS Settings, you can select from a few different scenarios, like "Texas user aged 14 without parental consent", etc. There's also a whole separate aspect to this law relating to "significant updates". Everyone seems kinda confused about this, but it seems like the general idea is that, if your app's age classification changes in the future, the app should be responsive to that change. My current interpretation is that if I use the AppStore.ageRatingCode as the age gate (as described above) then that should allow me to comply, but I haven't really looked into this aspect of the law yet. There's also another aspect to this law requiring developers to revoke access to the app when requested by the parent. I have not looked into this yet, but as noted above, it doesn't make sense to me why this is the developer's responsibility given that the platforms already provide solid parental controls. Do I need to something else in addition to what I've sketched out above? It goes without saying, of course, that everything above is not legal advice, and I still have some gaps in my understanding. I would really appreciate any feedback on the above, perhaps with recommendations about better ways to approach this.
Replies
10
Boosts
1
Views
1.5k
Activity
Jan ’26
screen time api Lock Screen
In my app I want to integrate a personilized Lock Screen. Does anybody know how that works?
Replies
1
Boosts
0
Views
254
Activity
Jan ’26
How to trigger ShieldConfigurationExtension?
On pressing the secondary button on my ShieldConfigurationExtension, I remove the shields by setting shields in the named ManagedStore to nil in my ShieldActionExtension. // ShieldActionExtension.swift let store = ManagedSettingsStore() store.shield.applications = nil store.shield.applicationCategories = nil Now after some duration I want to re-apply the shields again for which I do the following: // ShieldActionExtension.swift DispatchQueue.main.asyncAfter(deadline: .now() + unlockDuration) { [weak self] in self?.reapplyShields(for: sessionId, application: application) } private func reapplyShields(for sessionId: String, application: ApplicationToken) { store.shield.applications = Set([application]) } Followed by the completionHandler: // ShieldActionExtension.swift completionHandler(.defer) Now the expectation is ShieldConfigurationExtension should be re-triggered with store.shield.applications = Set([application]), however I see the default iOS screen time shield. This behavior is experience when the blocked app is running in the foreground. However, if I close and re-open the blocked app - the ShieldConfigurationExtension is trigerred again correctly. If I do a completionHandler(.none) instead, the overriden configuration method in ShieldConfigurationExtension is not triggered. How do I make sure ShieldConfigurationExtension is triggered if the blocked app is running in the foreground when the shields are re-applied again?
Replies
0
Boosts
0
Views
282
Activity
Jan ’26
Family Controls Entitlement - Typical Review Timeline?
Hi, Submitted Family Controls entitlement requests yesterday for a digital wellness app (main app + 3 extensions). For those who've been through this: How long did approval take? Did Apple ask for more info? Any tips? Thanks!
Replies
1
Boosts
0
Views
328
Activity
Jan ’26
DeviceActivityReport not showing report data to main app
I am getting this error when I try to show device activity report view by this DeviceActivityReport(appsContext, filter: filter) Attempt to map database failed: permission was denied. This attempt will not be retried. I have taken access by this way. AuthorizationCenter.shared.requestAuthorization(for: .individual)
Replies
3
Boosts
0
Views
1k
Activity
Jan ’26
Cannot access to screentime database to show in UI
I am getting this error when I try to show device activity report view by this DeviceActivityReport(appsContext, filter: filter) Attempt to map database failed: permission was denied. This attempt will not be retried. I have taken access by this way. AuthorizationCenter.shared.requestAuthorization(for: .individual)
Replies
0
Boosts
0
Views
350
Activity
Jan ’26
Can't show screen time data
I am getting this error when I try to show device activity report view by this DeviceActivityReport(appsContext, filter: filter) Attempt to map database failed: permission was denied. This attempt will not be retried. I have taken access by this way. AuthorizationCenter.shared.requestAuthorization(for: .individual) Detailed errors: LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Attempt to map database failed: permission was denied. This attempt will not be retried.
Replies
0
Boosts
0
Views
199
Activity
Jan ’26
Family Controls (Distribution) Capability Request
Hello! I recently submitted a request for the Family Controls (Distribution) for my app, and I’d be super happy if i could have some information about how long this process usually takes so i can plan accordingly. It would help immensly since we want to ship the app as soon as possible. I submitted the request around a week ago. Is there anything I can do on my end to help the process move more smoothly? Thanks in advance!
Replies
0
Boosts
0
Views
273
Activity
Jan ’26
Family Controls Entitlement - Typical Review Timeline?
Hi, Submitted Family Controls entitlement requests yesterday for a digital wellness app (main app + 3 extensions). For those who've been through this: How long did approval take? Did Apple ask for more info? Any tips? Thanks!
Replies
3
Boosts
0
Views
253
Activity
Jan ’26
FamilyControls on Mac Catalyst — can’t authorize due to sandbox; does this make ManagedSettings/DeviceActivity unusable?
Hi DTS / Apple engineers, We’re attempting to extending our screen time app target to Mac Catalyst. On iOS, FamilyControls works as expected (AuthorizationCenter + FamilyActivityPicker, then ManagedSettings shields + DeviceActivity monitoring/reporting). On Mac Catalyst: The project builds with FamilyControls/DeviceActivity/ManagedSettings capabilities enabled. But attempting to request FamilyControls authorization (or present FamilyActivityPicker) fails at runtime. We see errors similar to: Failed to get service proxy: The connection to service named com.apple.FamilyControlsAgent was invalidated: failed at lookup with error 159 - Sandbox restriction. And our app stays authorizationStatus == .notDetermined, with the request failing. We saw an Apple engineer suggestion to “disable App Sandbox”, but Mac Catalyst apps appear to always be sandboxed, so we can’t disable it. Questions: Is FamilyControls authorization supported on Mac Catalyst today? If so, what entitlement/capability is required specifically for Catalyst/macOS? If FamilyControls auth cannot succeed on Catalyst, does that mean ManagedSettings shields and DeviceActivity monitoring/reporting are effectively unusable on Catalyst (since they depend on that authorization)? Is there an Apple‑recommended approach for a Catalyst “portal” app that mirrors an iOS child device’s restrictions, or is local enforcement on Catalyst intentionally unsupported? Any guidance (and any official docs that clarify current platform support) would be hugely appreciated.
Replies
0
Boosts
0
Views
133
Activity
Feb ’26
How to open main app from ShieldActionExtension?
Hi! I'm building a Screen Time management app using FamilyControls and ManagedSettings. When a user taps the primary button on a ShieldActionExtension, I need to open my main app to guide them through an intervention exercise. Other approved App Store apps like Jomo - Screen Time Blocker do exactly this: tapping their shield's primary button opens the main Jomo app directly. Screen recording: https://drive.google.com/file/d/15yubtTdTkFskGCIaAw_HGB57-boHPl3a/view?usp=sharing I've tried: URL schemes (UIApplication.shared.open() unavailable in extensions) Universal links Local notifications (works, but adds an extra tap) NSUserActivity Is there a supported API I'm missing? Or another accepted solution? Any guidance is appreciated.
Replies
0
Boosts
0
Views
203
Activity
Feb ’26
Shield Action Extension rejected by App Store Connect – Invalid NSExtensionPointIdentifier for ManagedSettingsUI
Hello, I’m using the Screen Time API / Family Controls in my iOS app Sobre and I’m having an issue submitting a new build to TestFlight. My app setup is as follows: Main app ID: com.balthazar.sobre App extensions: Device Activity Monitor: com.balthazar.sobre.deviceactivitymonitor Shield Configuration: com.balthazar.sobre.shieldconfiguration Shield Action: com.balthazar.sobre.shieldaction On the Apple Developer portal: Family Controls (Distribution) is enabled for: the main app ID com.balthazar.sobre and all 3 extension App IDs above. App Groups are also configured for the app and the extensions. New App Store provisioning profiles have been generated for the app and all 3 extensions and are used in the latest build. When I submit the build through App Store Connect (via Fastlane / EAS), validation fails only for the Shield Action extension with this error: Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.ManagedSettingsUI.shield-action-service, in the Info.plist of “Sobre.app/PlugIns/ShieldActionExtension.appex” is invalid. DeviceActivityMonitorExtension and ShieldConfigurationExtension are accepted without any issue. My questions: What is the correct expected value for NSExtensionPointIdentifier for a Shield Action extension using the Screen Time / ManagedSettings APIs? Are there any additional entitlements or capabilities (for example, related to Managed Settings) that must be explicitly enabled for the app or the Shield Action extension in order for this extension point to be accepted by App Store Connect? Given that Family Controls (Distribution) is already granted for the main app and all extensions, is there anything else that needs to be requested or configured on my account or App IDs to use a Shield Action extension? My goal is to use Screen Time / Family Controls properly to block distracting apps and present a custom Shield UI + actions for my users, while respecting all Apple policies. Thank you in advance for your help and guidance
Replies
1
Boosts
0
Views
220
Activity
Feb ’26
Extract raw Screen Time data? Security says it's 'expected'
Hi everyone, I have a question regarding the intended privacy limits of the DeviceActivityReportExtension. According to the documentation and the WWDC21 session "Meet the Screen Time API", this extension was created specifically to prevent the host application from accessing the user's underlying activity data (websites visited, app usage, screen time, etc). But I have found that my host app is actually able to reconstruct this raw activity data from the activity report. I am able to extract specific visited websites and app usage durations back into the main app. I reported this to Apple Security (Case ID: OE1100504480881 ), assuming it was a sandbox bypass. However, they closed the ticket stating that this is "expected behavior" and requires no fix. My question for Screen Time Engineers: Is the documentation incorrect? If my host app is expected to be able to read this data, is there a formal API we should be using instead of extracting it from the report extension? The current behavior contradicts the privacy limits described in the documentation, so I am confused if I should rely on this data access for my app features or if it will be patched later. Thanks.
Replies
1
Boosts
0
Views
379
Activity
Feb ’26
Screen time API can be disabled easily
We have developed a Parental/Self control app using Screen time API. We have used individual authentication to authorize the app, using the instructions here: https://developer.apple.com/documentation/familycontrols/authorizationcenter The problem is , that individual auth can be disabled easily , by the following steps: enter Settings app. in Settings app, click on the Parental/Self control app. click to disable screen time restriction. show the device owner's face/fingerprint. (or pin code) Why is that a problem: Parental control apps, or self-control apps, are about giving control to the software, To make it hard for the user to disable the restrictions. So using the flow I have introduced above, it's super-easy for a user to disable his Parental control restrictions, which misses the entire point of Parental/Self control idea. Furthermore, not only the user have the means to unlock his screen time restrictions, he also MUST have the means to unlock it. This makes Screen time (with individual auth) useless: I have a code ready to make a great parental control app for my clients, with amazing ideas, but I can't use the Screen time API unless this problem is fixed. Why child-parent auth is not enough: My clients are grownups people between ages of 15-40, that are interested in self-control, so they don't have iCloud child accounts. also, the child-parent auth solution forces my clients to give some control to other person, and my clients prefer their privacy. Some of them prefer self-control and not parental-control. What I suggest as a solution: 1: Give more options to users how to disable the Screen time restrictions. including: a second faceID / FingerPrint (that isn't the same as the one used to unlock the device) a second pin password. a string password 2: Give the users the option to choose to not have the device's owner Face/Finger/Pincode ID , as a method to disable the Screen time restrictions.
Replies
16
Boosts
3
Views
6.5k
Activity
Feb ’26
Family Controls Entitlement Request Pending Over 2 Weeks
Hello, Our team submitted a request for Family Controls entitlements for our main app and four related extensions. It has now been a little over two weeks since submission, and the request is still pending review. We wanted to check if there are any recommended steps we can take on our end to help move the process forward. Any guidance or tips from anyone who have recently gone through this process would be greatly appreciated. Thank you.
Replies
2
Boosts
0
Views
126
Activity
Feb ’26