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.

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

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

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

Hi Apple Developer Support, I’m developing an iOS app that uses FamilyControls, ManagedSettings, and DeviceActivity. My app requests Screen Time authorization with: try await AuthorizationCenter.shared.requestAuthorization(for: .individual) Issue: On my development-installed build, AuthorizationCenter.shared.authorizationStatus becomes .approvedWithDataAccess, and the app can display usage data. However, after installing the App Store / App Store Connect distribution build, the same device and same flow returns .approved instead of .approvedWithDataAccess. As a result, the app only treats the authorization as management access, not usage-data access. App details: App name: App时记 Main bundle ID: com.qteqpid.appstop Device Activity Monitor extension: com.qteqpid.appstop.AppStopMonitorExtension Device Activity Report extension: com.qteqpid.appstop.AppStopReportExtension Version/build tested: 2.0 (4) Team ID: 5N6B48T57B What I verified: I exported an App Store Connect IPA from Xcode Organizer on September 3, 2026 and inspected the actual signed entitlements with codesign. The main app and both Screen Time extensions all include: com.apple.developer.family-controls = true com.apple.developer.family-controls.app-and-website-usage = true com.apple.security.application-groups = group.com.qteqpid.appstop get-task-allow = false The DistributionSummary.plist also shows Apple Distribution signing and App Store provisioning profiles for the main app and both extensions. Question: Given that the App Store Connect distribution IPA appears to contain the app-and-website-usage entitlement on the main app and both extensions, what conditions would cause AuthorizationCenter.shared.authorizationStatus to return .approved instead of .approvedWithDataAccess for an .individual authorization? Is there an additional distribution-side approval, App ID setting, provisioning support setting, device state, or Screen Time privacy limitation that can prevent .approvedWithDataAccess even when the signed entitlements are present? I would appreciate guidance on how to verify why data access is not granted in the App Store/TestFlight environment. Thank you.

Hello, I’m looking for some guidance regarding an App Store review that has been taking significantly longer than expected. Our app, SafeKnot, was originally submitted on August 20, 2026 at 20:24. Shortly after submission, we received an automated App Review message indicating two issues: The app uses Screen Time APIs and needed the Family Controls entitlement. The app offers auto-renewable subscriptions but the App Store metadata was missing a functional Terms of Use (EULA) link. We addressed both issues: The required Family Controls entitlement/configuration was completed. The Terms of Use information was added correctly. We then resubmitted the app for review. Since the resubmission, the app has remained in “In Review” status for several days, and we have not received any additional questions, rejection messages, or requests for information from App Review. We also contacted Apple Developer Program Support and received the following case number: Case ID: 20000149485605 Could an Apple engineer or App Review representative please advise whether the submission is still progressing normally, or whether there may be an issue preventing the review from proceeding? We do not want to cancel and resubmit the app unnecessarily, as it is already in the review process. Thank you very much for your help.

Does anybody know if Apple allows for apps to access a user’s applicationa’ usage data? As a part of an app idea I have I need to see What is the screen time of each user on each app (Not only mine). Is it possible?

Hello, Apple Developer Technical Support directed me to the Developer Forums for clarification on the following Family Controls use case. DTS reference: Case-ID 21723677 I am evaluating an iOS app called “Zone” before beginning full development. I would like to determine whether the proposed architecture is considered permitted individual device management for focus and productivity, or prohibited use “in organizational settings” under Section 3.3.3(P) of the Apple Developer Program License Agreement. Proposed architecture: Zone is offered to companies as a workplace focus and productivity service. The app is installed on an adult employee’s personally owned iPhone. Participation and each Focus Session are voluntary. The employee independently requests Family Controls authorization using individual authorization. Only the employee can select the apps and websites to restrict. Only the employee can start or stop a Focus Session. During the session, Zone applies restrictions locally on that employee’s iPhone using Family Controls and Managed Settings. The employer cannot authorize or revoke Family Controls access. The employer cannot select restricted apps or websites. The employer cannot remotely start, stop, or schedule a Focus Session. The employer cannot remotely manage or control the employee’s device. Zone would not provide the employer with: Screen Time or Device Activity data App or website tokens App usage history Website browsing history Information about attempts to open restricted apps Location, messages, photos, or other personal device information However, Zone would include a company web dashboard. The dashboard would show only an app-generated boolean status for each participating employee: Zone ON: the employee has voluntarily started a Focus Session Zone OFF: the employee has not started a Focus Session This status is generated by the Zone app itself. It is not derived from Screen Time usage data and does not indicate whether the employee actually attempted to use any restricted app or website. My questions are: Would this architecture be considered permitted individual device management for focus and productivity, even though the service is offered through an employer and the employer can see the Zone ON/OFF status? Or would the employer relationship and company dashboard make this prohibited use of Family Controls “in organizational settings”? If sharing the app-generated ON/OFF status with the employer is incompatible with the Family Controls terms, would the use be permitted if Family Controls operated entirely on-device and no Focus Session status or device information were sent to the employer? Is there another Apple-supported framework or architecture recommended for this use case? I understand that final entitlement approval and App Review decisions may depend on the submitted application. I am seeking architectural guidance before investing in implementation. Thank you.

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.

I'm about to start losing all my phone's biome data and my mind with it. I need help from guru engineers. Hope someone could help me. Published Biome research covers reading the SEGB artifacts, but I can't find anything on sync/sync.db and the merge logic. Hoping someone here has looked at it. Setup: iPhone16 Pro on iOS 26.6 paired with a MacBook Air on macOS 26.6. Same Apple ID. Reading my own devices, read-only. What happened My Macbook stopped receiving phone's in_focus biome stream after a large tombstone purge. In ~/Library/Biome/sync/sync.db, table CRDTLocation has rows of (stream, site, day, state). For my iPhone's AppLaunch stream there is a contiguous band of 27 days, 30 June to 29 July, with state = 4. Every other day is state = 2. Other streams on the same device have bands of only 1-2 days. Data behaviour lines up exactly with that band: -every day at or below 29 July: the phone offers batches, zero records ever land -every day after 29 July: records land normally, but only 2-3 per hour, the gap is widening every day. I am now on the 1st of Aug. -14 out of 14 date buckets observed over a week follow this, no exceptions Media.NowPlaying on the same phone has its own state=4 day at 23 July, and it has delivered nothing since 22 July. Over a week it re-offered ~8,900 records spanning 21 June to 16 July, all refused, and it never offers anything dated after its 23 July mark, even though newer data exists on the phone. The 27-day band was created on 30 July: two tombstone segments written over 6 seconds at 08:14 UTC containing ~18,000 deletion records covering 2-24 July. On the Mac those days now show 0 live records and several thousand dead slots. TombstoneBookmark still points at that segment. Questions What do CRDTLocation.state values mean? I'm fairly confident 4 = deleted and 2 = present/known, since days marked 2 sync fine including ones with no data yet. Is that right, and are there other values? Is the refusal rule what it looks like: an incoming batch is dropped if its day is at or below the highest state=4 day for that (stream, site)? Is the comparison meant to be inclusive? Is a tombstone for a day supposed to bar re-delivery of the entire day permanently, or only the specific records that were deleted? Mine appears to bar everything, including records that were never deleted. Is there any supported way to clear a state=4 band, or reset the sync relationship for one stream, without erasing the device? Has anyone seen a tombstone burst like this, ~18,000 deletion records in under 6 seconds while both devices were idle? Normal pruning on my device is ~700/day. Is there a known trigger? Would it be possible to repoint tombstone bookmark manually? The source records still exist on the phone but Biome retention is ~28 days, so they age out within days... please help Thank you!

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.

Our app — a screen-time / focus app — has had no App Review activity for two weeks, and we believe the trigger was an automated Guideline 2.5.1 check that froze an otherwise actively progressing review. (This forum account is linked to the developer account in question; we can provide the App ID, bundle IDs, submission IDs, and support case numbers through any private channel on request.) Context: Jul 2–5: Our first submission (Version 1.0.0) was under active review. We went through several ordinary metadata / paywall-related iterations, and the reviewer responded within roughly 24 hours each time. Nothing related to Screen Time was raised in these human reviews of builds 9 and 10. Jul 8: After we submitted build 11 — which addressed the remaining human-review feedback — we received an automated Guideline 2.5.1 (Performance: Software Requirements) message stating that the app uses the Screen Time API but has not been submitted with the Family Controls entitlement, and that review of the submission cannot proceed. All reviewer activity stopped at that point, and there has been none since. What we verified: The Family Controls (Distribution) entitlement is granted to our account and assigned to all four bundle IDs (the main app plus its DeviceActivityMonitor, ShieldAction, and ShieldConfiguration extensions). We verified with codesign that com.apple.developer.family-controls = true is present in the code signature and embedded provisioning profile of every one of the four executables in the submitted IPA — so the entitlement named in the automated message is present in the flagged build. For context: builds 9 and 10, with an identical Screen Time API surface and identical entitlements (verified at the binary level with nm against the submitted artifacts), had been human-reviewed on Jul 2–5 with no Screen Time-related objection. We recognize those builds may simply not have reached the automated analysis stage before being superseded, so we do not draw firm conclusions from that. What we did anyway (build 12, submitted Jul 9): In case the automated check actually concerns the separate com.apple.developer.family-controls.app-and-website-usage entitlement (which we do not request and do not need), we removed every reference from our main app to the APIs associated with it: AuthorizationStatus.approvedWithDataAccess, ManagedSettings.Application.bundleIdentifier, ManagedSettings.Application.localizedDisplayName, ManagedSettings.ActivityCategory.localizedDisplayName, and ManagedSettings.WebDomain.domain. We verified with nm that none of the four executables in the build 12 IPA reference these APIs. The app does not use FamilyActivityData, DeviceActivityReport, app usage events, web usage events, or App and Website Usage data access. No automated message has appeared for build 12. What has happened since: Jul 9–14: No reviewer activity on build 12. We filed an expedited review request and opened two Developer Support cases (Jul 8 and Jul 14). No response to any of them. Around Jul 15: Hoping to clear the frozen state, we cancelled and resubmitted the same Version 1.0.0 / build 12. Around Jul 17: Filed a second expedited review request for the new submission. Jul 22 (today): The new submission has been in "Waiting for Review" since Jul 15, with no reviewer activity and no reply to either support case or either expedite request. What we are asking: Could someone check whether the Jul 8 automated flag is still attached to the app record and blocking reviewer assignment, and help get the current submission assigned to a reviewer? If the automated check flags build 12 again, could the message specify which entitlement and which binary / API references triggered it, so we can address it precisely? We can provide codesign output, entitlement plists, provisioning profile dumps, and nm symbol listings on request. Thank you.

Hey everyone,I’m running into a deeply frustrating structural bug with the redesigned Screen Time menus in the iOS beta, and I wanted to see if anyone else has found a workaround (or is facing the same thing).In previous iOS versions, if a site was blocked by the filter, you could hit "Allow Website," enter your code, and go on with your day. It didn't permanently log itself into your settings.In this beta, the system acts like a strict binary engine. The second you manually approve a site or click "Allow Anyway," that URL is permanently added to a list. There is no swipe-to-delete option anymore. You are completely locked into either choosing "Always Allow" or "Never Allow" for that URL. There is literally no middle ground or way to just remove it from the menu entirely.To make it worse, I have tried literally everything: disabling Screen Time, turning off tracking, and I even went as far as doing a full Reset All Settings. Guess what? The list was still there. It seems to be pulling straight from an iCloud ghost-sync loop that ignores local device overrides.Has anyone successfully forced these URLs to delete, or are we completely at the mercy of Apple patching this database design flaw in a future beta build?

With the declining literacy rates I think it would be incredibly valuable for apple to implement a separate keyboard experience for minors. One without auto or predictive text, swipe to text, or even potentially also voice memos. These are all very convenient features that I think could unfortunately contribute or even enable the literacy crisis as more and more children grow up and rely on technology. I also think bringing back the ‘look up’ tool on highlighted text into the main options would support and encourage more education (or even adding a thesaurus option as well) From: A Gen Z adult who grew up learning how to spell at the same time I learned how to text. Without relying on all of the convenience features that in turn can remove the mental friction that learning to fix your mistakes provides, my iPhone was teaching me how to spell with simple red lines that required me to interact with my spelling in order to correct my mistakes. Note: Autocorrect was still a feature at the time however was often turned off by most people because of text slang culture which coincidentally helped create more intentional spell check interactions. I believe the decision to turn off autocorrect should be considered a more conscious responsibility so it should not necessarily be left up to a child to decide for themselves.

I am the developer of a screen time awareness app currently on the App Store. It uses the Family Controls and DeviceActivity frameworks, with the distribution entitlement approved, to show users their own cumulative screen time since install. All tracking today is fully on-device and nothing leaves the user's phone. I am planning an optional social feature and I want to confirm Apple's position before building it, because I want to stay clearly within the Developer Program License Agreement, specifically Section 3.3.3(P) regarding data received through the Family Controls framework. Here is how the feature would work: The app monitors the user's own device activity via DeviceActivityMonitor threshold events. This is the same mechanism the app already uses for its on-device counter. On-device, that counter is converted into an abstracted, gamified score. The score is not expressed in hours, minutes, or any unit of time, and the app never displays it as time. If, and only if, the user opts in to the feature, the app uploads a self-chosen username, the date the user's count began, and the user's abstracted score values to my backend. Score values may be computed over different time windows, for example a lifetime score alongside daily, weekly, or monthly scores, but they are all the same abstraction: no raw time totals, no per-app or per-category data, no contacts, and no identifiers beyond what the account itself requires. Friends who have mutually opted in see each other's usernames and scores on a leaderboard. The app never displays another person's screen time, and no time values are stored server-side. The feature is off by default, data is encrypted in transit and at rest, and users can delete their account and all associated data from within the app at any time. The privacy policy will disclose all of this. My question: does transmitting this opt-in, abstracted score, derived on-device from DeviceActivity threshold events, comply with DPLA Section 3.3.3(P) and the intended use of the Family Controls framework? If this specific design is not acceptable, is there any form of opt-in social comparison feature that would be, and what constraints would it need to satisfy? I am aware of earlier threads here where sending screen time data off-device was flagged as non-conforming, which is exactly why I am asking before writing any code rather than after. I would rather design this correctly from the start than risk a rejection later. Thank you for your time. Happy to provide any additional detail about the design.