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

After transferring the App ownership to a different account, if you update the app on iOS, two identical apps will show up in Settings > Screen Time. Users can't control the blocking settings from before the update - the only fix is to restart the phone. After the next execution of manageStore.shield.applications, users still can't manually disable the restrictions - their only option is to uninstall and reinstall the app. I believe this is related to how Screen Time API's authentication works - it's not just tied to the app's bundle ID, but also linked to the developer account's organization ID. Any suggestions for a clean solution that would allow smooth app updates after the transfer without running into these issues?

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.