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

I am reporting what appears to be a serious integrity flaw in Safari under iPadOS 26.3 (and lower) that materially undermines the reliability of Screen Time parental controls. This is not merely a UX inconsistency but a functional contradiction within a system explicitly marketed and positioned as secure parental control infrastructure. Device / Environment Device: iPad Air M3 13" (2025) OS: iPadOS 26.3 Safari (system version) Screen Time enabled with active restrictions Child account (10 years old) Background We deliberately chose an Apple device for school use based on the expectation that Apple’s system-level parental control mechanisms — especially Screen Time — are robust, tamper-resistant, and technically consistent. Screen Time is configured with: App limits Downtime Parental controls enabled with limited web content restrictions (school requirements prevent strict blocking) Safari enabled (mandatory for educational use) further parental control restrictions Because aggressive website blocking would interfere with legitimate school activities, monitoring Safari browsing history is a central supervisory mechanism. When Screen Time is active: Clearing the entire browsing history via Safari is correctly blocked. Clearing history via system settings is correctly blocked. The system explicitly communicates that deletion is not permitted due to Screen Time restrictions. This behavior establishes a clear user expectation: Browsing history is protected against manipulation. The Issue Despite the above safeguards, individual browsing history entries can be deleted easily and silently through the address bar suggestion interface. This creates a structural contradiction: Full deletion is blocked. Selective deletion — which is arguably more problematic — remains possible. Steps to Reproduce Enable Screen Time with restrictions that prevent deletion of browsing history (for example on a student device with a child account). Open Safari and visit any website. Confirm it appears in Safari history. Tap the Safari address bar. Type part of the URL or page title. Safari suggests the previously visited page below the address bar. Swipe left on that suggestion. A red “Delete from History” button appears. Tap it. Actual Result The entry disappears immediately: No Screen Time PIN required No authentication request No warning No restriction triggered No parental notification No audit trace visible Deletion occurs silently and irreversibly. Expected Result When Screen Time is configured to prevent browsing history deletion: Individual entries must not be deletable Deletion must require Screen Time authentication Anything else defeats the protective purpose of the restriction. Real-World Impact In practical use, this allows minors to selectively sanitize browsing history while preserving a seemingly intact record. In our case, this method is widely known among classmates and routinely used to conceal visits to gaming or social media platforms during school hours. The technical barrier to exploitation is negligible. This results in: A false sense of security for parents A discrepancy between advertised functionality and actual system behavior A material weakening of parental control integrity When a system explicitly blocks full history deletion but permits silent selective deletion, the protection mechanism becomes functionally inconsistent and unreliable. Given that Screen Time is publicly positioned as a dependable parental control framework, this issue raises concerns not only about implementation quality but also about user trust and reasonable reliance on advertised safeguards. Request Please classify this as a parental control integrity and trust issue. Specifically: Disable individual history deletion while Screen Time restrictions are active OR Require Screen Time passcode authentication for deleting single entries Screen Time is presented as a secure supervisory environment for minors. In its current implementation under iPadOS 26.3 and before, that expectation is technically not met. This issue warrants prioritization.

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.

Hello Apple Developer Support Team, We are developing an iOS iPhone application and would like clarification on whether Apple provides any APIs or system-level support to implement parental approval workflows aligned with certain regional regulatory requirements (for example, Texas, Utah, and Louisiana). Our intended use cases are outlined below: Initial Approval (App Download Stage) We understand that, in some situations, when a minor attempts to download an app from the App Store on iPhone, iOS may require approval through Family Sharing / Ask to Buy. We would like to confirm: • Whether there is any developer-accessible API that allows an iPhone app to detect if installation was approved via parental consent. • Whether apps can receive any callback, status indicator, or system signal confirming parental approval or rejection. • Whether the Declared Age Range API or any related framework provides access to parental approval or age verification signals. Ongoing Approval for Significant Changes For regulatory compliance, we may need to request parental re-approval when introducing significant application updates (for example, adding chat functionality, social interaction features, or modifying data collection practices). We would like clarification on: • Whether iOS provides any mechanism or API that allows iPhone apps to trigger or request parental re-approval after the application has already been installed. • Whether Apple provides any built-in workflows, system prompts, or entitlement-based approaches that support this type of re-approval process. In-App Handling of Parent Approval Requirements If our backend determines that a minor user requires parental approval before continuing to use certain app features, we would like to understand: • Whether Apple provides any APIs, SDKs, or recommended frameworks that allow initiating or facilitating parental authorization from within the iPhone app. • Whether there are any callbacks, permission states, entitlement checks, or system notifications that developers can use to determine and track parental consent status. If any such capabilities exist, we would greatly appreciate links to official documentation, technical guidance, or sample implementations demonstrating how approval status can be retrieved and handled in an iOS iPhone application. Also from which iOS version this capabilities will work & how to handle lower iOS version which is not supporting. Additionally, if Apple recommends alternative compliance approaches using existing frameworks such as Family Sharing, Screen Time APIs, or Declared Age Range, we would appreciate guidance on best practices for implementation. Also, could you please clarify the minimum iOS version that supports these capabilities? We would also appreciate recommendations on how developers should manage or implement fallback handling for devices running lower iOS versions where these capabilities are not supported. Thank you for your assistance and guidance in ensuring compliance with Apple platform policies and regional regulatory requirements. Kind regards

Hi, Submitted Family Controls entitlement request a month ago for my main focus app, got approved within a day. Submitted 3 more requests for my extensions, and it has been 16 days without any word. Saw advice to file a code-level support with DTS in this similar forum: https://developer.apple.com/forums/thread/812934 Is there anything else I can do before filing a code-level support? Any extra info to provide? If not, can a DTS engineer please refer me for the code-level support? Thanks!

Hello! I recently submitted a request for the Family Controls (Distribution) entitlement for my app, and I’m trying to understand what kind of timeline to expect. I’ve seen posts suggesting anywhere from a few days to over a month for approval. Is there a typical review window for this entitlement? And is there anything I can do on my end to help the process move more smoothly? Thanks in advance!

Description: I am developing a digital well-being application using the Screen Time API (FamilyControls, ManagedSettings, and DeviceActivity). I am encountering a critical issue where the ApplicationToken provided by the system to my app extensions suddenly changes, causing a mismatch with the tokens originally stored by the main application. The Problem: When a user selects applications via FamilyActivityPicker, we persist the FamilyActivitySelection (and the underlying ApplicationToken objects) in a shared App Group container. However, we are seeing frequent cases where the token passed into: ShieldConfigurationDataSource.configuration(shielding:in:) ShieldActionDelegate.handle(action:for:completionHandler:) ...does not match (using ==) any of the tokens previously selected and stored. IOS version: 26.2.1

I'm experiencing a contradictory validation issue with DeviceActivityReportExtension that creates an impossible situation: The Problem: Without NSExtensionPrincipalClass in Info.plist → App Store Connect rejects upload with: "Missing Info.plist values. No values for NSExtensionMainStoryboard or NSExtensionPrincipalClass found" With NSExtensionPrincipalClass → Local install fails with: "defines either an NSExtensionMainStoryboard or NSExtensionPrincipalClass key, which is not allowed for the extension point com.apple.deviceactivityui.report-extension" Setup: Extension point: com.apple.deviceactivityui.report-extension Using SwiftUI with @main attribute and DeviceActivityReportExtension protocol Xcode 16.2, iOS 17.6 deployment target Code structure: @main struct SpoolReport: DeviceActivityReportExtension { var body: some DeviceActivityReportScene { // Report scenes here } } The extension builds and runs perfectly without NSExtensionPrincipalClass, but cannot be uploaded to App Store Connect. Adding the key allows upload but breaks local installation. Is this a known issue? Is there a workaround or correct Info.plist configuration for DeviceActivityReportExtension? Thank you!

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

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.

Hi, we are developing a screen time management app. The app locks the device after it was used for specified amount of time. After updating to iOS 26.2, we noticed a huge issue: the events started to fire (reach the threshold) in the DeviceActivityMonitorExtension prematurely, almost immediately after scheduling. The only solution we've found is to delete the app and reboot the device, but the effect is not lasting long and this does not always help. Before updating to iOS 26, events also used to sometimes fire prematurely, but rescheduling the event often helped. Now the rescheduling happens almost every second and the events keep reaching the threshold prematurely. Can you suggest any workarounds for this issue?

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

There is an inconsistent issue when views are rendered from the Device Activity Report Extension. This issue is noticeable only on release versions and it works fine in debug mode. Around 80% of the times, the Report Views return blank screen and this is only the case when a weekly/monthly filter is used. Although, it works as expected for daily report views. My questions are: How are all the Report Activity Views working fine in debug mode but not in release mode? How the daily activity filter works fine in the release mode but the weekly/monthly filters don't work? Is this because of a memory limit issue in the extension? As of now, I have the family-controls(distribution) entitlement only for the app and for the extensions I only have family-controls(development) entitlement. Do I need to request for family-controls(Distribution) entitlement even for the extensions? I have seen threads on the forum mentioning the blank screen issue associated with the DeviceActivityReport but haven't found a solution to it. Any suggestions/feedback would be of great help, thanks.

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.

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!

On iOS 26.2 (23C55), DeviceActivityMonitor.eventDidReachThreshold fires intermittently for a daily schedule (00:00–23:59) even when iOS Screen Time shows 0 minutes for the selected apps that day. This causes premature shielding via ManagedSettings. Environment: iPhone 13 Pro Max, iOS 26.2 (23C55). Event selection: 2 apps. Threshold: 30 minutes. Multiple TestFlight users report the same behavior across various app selections and thresholds. Intermittent (~50% of days); sometimes multiple days in a row. Not observed in testing prior to iOS 26.2. Evidence: sysdiagnose + Screen Time screenshots (with 0 screen time on selected apps) + unified logs show UsageTrackingAgent notifying the extension that “unproductive from activity daily reached its threshold,” followed immediately by ManagedSettings shield being applied (extension reacting to the callback). Filed Feedback Assistant: FB21450954. Questions: Are others seeing this on 26.2? Does it correlate with restarting monitoring at interval boundaries or includesPastActivity settings?

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!

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.

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)

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)

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!