DeviceActivityReport — supported way to surface a child's per-app usage on the parent device (third-party cross-device parental control)?

Question

Created 1d

Replies 1

Boosts 0

Participants 2

I'm building a cross-device parental-control app: separate child and parent devices in the same Family Sharing group. I want to show the child's per-app (and per-category) Screen Time usage on the parent device. After extensive testing I can only get the child's total minutes across, and I'd like to confirm the supported architecture before building further on a path the framework may intentionally forbid.

Authorization / setup

Child device: AuthorizationCenter.shared.requestAuthorization(for: .child) — approved. Confirmed authorized: my app appears under Settings → Screen Time on the child, and the child's own DeviceActivityReport(users: .all) renders full per-app data.
Parent device: separate device in the same family.
Targets: main app + DeviceActivityReport extension + DeviceActivityMonitor extension, all with com.apple.developer.family-controls and a shared App Group. Physical devices, iOS 26.4.1. Xcode ⟦version⟧.

What works: only the child's total minutes reach the parent — and only via my own relay: a DeviceActivityMonitor extension on the child writes aggregate totals to the App Group, the host app syncs them through CloudKit. No Screen Time API itself delivers the child's app/category breakdown to the parent. ⸻ Finding 1 — the report extension computes correct per-app data but cannot export it. On the child, makeConfiguration(representing:) iterates the results and produces correct per-app durations:

LumicoActivityReport makeConfiguration done — 1 activityData, 1 segments, 5 apps, 17 min total

Writing those aggregates to the shared App Group from inside the extension is then denied by the sandbox:

Couldn't write values for keys ("screen_time_per_app_json") in CFPrefsPlistSource (Domain: group.servusjon.Lumico.shared …): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access

(UserDefaults.set doesn't throw — the write silently no-ops; only this CFPrefs log reveals the denial.)

Q1: Is there any supported way to surface aggregated, non-identifying per-app usage (app name + minutes + category) computed inside the DeviceActivityReport extension to the host app, given that App Group writes from the extension are denied? Or is the DeviceActivityMonitor extension (threshold events) the only supported way to get any usage signal out of the Screen Time sandbox?

Finding 2 — on the parent, users: .children shows the parent's OWN data. On the parent I embed DeviceActivityReport(_:filter:) with DeviceActivityFilter(users: .children, …). The report renders, but shows the parent's own apps/categories — no child data. FamilyActivityPicker on the parent behaves the same (lists the parent's own apps). The identical code on the child (users: .all) returns the child's full data — so the pipeline works; only the cross-device delivery to the parent fails.

Q2: What is required for DeviceActivityReport(users: .children) to deliver a child's activity to a third-party app on the parent device? Must the parent app hold a specific FamilyControls authorization (which FamilyControlsMember)? What conditions make FamilyActivityPicker surface a child's apps (not just categories) from the family on the parent device — authorization type, Family Sharing roles, child managed status, sync timing? ⸻ Already ruled out: physical devices (not Simulator); Screen Time data present on the child; extension correctly embedded (ExtensionKit com.apple.deviceactivityui.report-extension) and running makeConfiguration normally; family-controls + App Group present on app and both extensions; iCloud container named conventionally iCloud.<bundleid>.

Core question: What is the supported architecture for showing a child's per-app usage on a parent's device in a third-party app? I want to build on the sanctioned path rather than a workaround. Thanks!

Answer 1

DTS Engineer OP

Apple

1d

Thanks for the post with all the details and descriptions of what you are trying to accomplish. I’m more interested in the final goal for the app instead of being a replacement for the existing functionality instead of using it to be compliant with the location and local laws?

What is the exact boundaries of privacy model for the Screen Time API that you are trying to get to? The designed the FamilyControls and DeviceActivity frameworks with strict data boundaries. Detailed usage data is legally and technically treated as highly sensitive, and the framework intentionally forces that data to remain on the device where it was generated.

The DeviceActivityReport extension runs in a highly restricted sandbox explicitly designed this sandbox to be age and location based. Any attempt to exfiltrate the raw data you iterate over in makeConfiguration(representing:) will be blocked by the sandbox, as you saw with the CFPrefsPlistSource denial?

For DeviceActivityReport(users: .children) to deliver a child's activity to the parent device? It is not possible for third-party apps to get access to privacy information. That will break security and does not expose this cross-device data stream to third-party.

The restriction preventing third-party apps from accessing or exfiltrating detailed Screen Time data is not a missing feature; it is a fundamental, deliberate architectural decision. It is rooted in strict privacy, security, and legal compliance principles.

Albert  WWDR