iOS 27.0.1 child device does not enforce third-party ManagedSettings shields when the parent device runs iOS 18.7.1 (system Screen Time works)

App & System Services General
teratat OP
Created
Replies 1
Boosts 0
Views 38
Participants 2

Setup

  • Parent device: FamilyActivityPicker with a selection created as FamilyActivitySelection(includeEntireCategory: true). The parent selects apps for an always-on block list. The selection is encoded with PropertyListEncoder and sent to our server.
  • Child device: authorized with AuthorizationCenter.shared.requestAuthorization(for: .child). It receives the selection, decodes it, and immediately applies its application tokens. The shield stays on all day, with no schedule:
let selection = try PropertyListDecoder().decode(FamilyActivitySelection.self, from: data)
ManagedSettingsStore(named: .appBlock).shield.applications = selection.applicationTokens

Observed
Cases A and B use the same two physical devices with the parent and child roles swapped. In all cases, the Family Sharing group uses legacy Screen Time, because not every device is on iOS 27 and the redesigned Screen Time is not available.

CaseParentChildOur app's shieldSystem Screen Time (set by parent)
AiOS 27.0.1iOS 18.7.1BlocksBlocks
BiOS 18.7.1iOS 27.0.1Does not blockBlocks
CiOS 18.7.1iOS 18.7.1BlocksBlocks

Questions

  1. Is this a known issue in iOS 27.0.x? Could it be related to issue number 175437403 ("Screen Time restrictions might not apply to child accounts despite being configured"), which the iOS 27 release notes list as fixed? Should tokens selected on an iOS 18 parent device be enforced on an iOS 27 child device?
  2. Is there a workaround, or a way to detect that a shield was applied but is not being enforced?
Replies  1
Boosts 0
Views  38
Participants  2
Pokpong OP

I don't know of a public way to ask ManagedSettings whether a specific shield is actually being enforced. Apple's APIs let you set the shield, but this result looks like an OS-level issue from the A/B tests you described, especially since the same child device blocks when the parent is also on iOS 18.7.1.

I'd file a Feedback Assistant report with the exact matrix, device models, build numbers, the Family Controls authorization status on both devices, the decoded token counts, and sysdiagnose from the iOS 27 child shortly after reproducing it. Keep a copy of the selection's encoded data and confirm that decoding succeeds and applicationTokens isn't empty before assigning the store. If possible, add a test where the selection is created on an iOS 27 parent and sent to the same iOS 27 child; that would help separate token-versioning from the mixed-version family setup.

I wouldn't treat the release-note issue number as confirmation that this is the same bug. Apple's docs describe these as opaque tokens shared within a Family Sharing group, and say they become void if authorization is revoked, so check that authorization is still valid on the child. If it reproduces with valid authorization and nonempty tokens, the Feedback report is the useful next step; I don't know of a reliable app-side workaround for a shield the OS isn't enforcing.

References: [FamilyActivitySelection](https://developer.apple.com/documentation/familycontrols/familyactivity