forum-post-v2-evidence.log MCRestrictionsPayload (allowListedAppBundleIDs) breaks Apple Watch app enumeration — nanotimekitcompaniond reports "Missing .app from directory: /Watch/" Summary Installing a Configuration Profile with com.apple.applicationaccess payload containing allowListedAppBundleIDs causes native Apple Watch apps to disappear from the paired Watch — even when their bundle IDs are explicitly in the whitelist. Log analysis shows this is not a bundle ID matching problem: nanotimekitcompaniond on the iPhone fails to enumerate the <companion>.app/Watch/ subdirectories where native watchOS app stubs live. Follow-up to https://developer.apple.com/forums/thread/745585 — community-confirmed but received no official response. Environment iPhone 16 (iPhone17,3), iOS 26.4.2 (23E261), supervised Apple Watch paired via Bridge.app Profile installed locally via Apple Configurator (no MDM server required) Smoking gun Within ~5 seconds of profile install, two processes (nanotimekitcompaniond and NTKFaceSnapshotService) log identical errors for eight companion-app paths: nanotimekitcompaniond[1498] <Error>: Missing .app from directory: file:///Applications/MobilePhone.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../Calculator.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../Bridge.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../MobileTimer.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../Camera.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../VoiceMemos.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../MobileMail.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../FindMy.app/Watch/ NTKFaceSnapshotService[3758] <Error>: Missing .app from directory: <same 8 paths> The Watch's app icons and face complications both go through these processes, which explains the symptoms users see. iOS itself flags the payload as Watch-incompatible — but applies it anyway profiled[179] <Notice>: Payload class MCRestrictionsPayload (com.apple.applicationaccess) is not supported on any Watch version profiled[179] <Notice>: Payload class MCRestrictionsPayload (com.apple.applicationaccess) is not available on HomePod profiled[179] <Notice>: Beginning profile installation... profiled[179] <Notice>: Profile "...v2..." installed. So profiled knows the payload doesn't target watchOS — yet its side effects clearly manifest there. Tests performed Test Bundle IDs in whitelist Result v1 249 (every installed iOS app: Apple + 3rd party) Walkie-Talkie, Messages, Find My + more disappear from Watch v2 295 (v1 + every Apple extension/Nano* daemon seen in syslog: *.MessagesActionExtension, *.FindMyNotifications*Extension, *.FindMyWidget*, com.apple.NanoBackup, com.apple.NanoMusicSync, com.apple.NanoPreferencesSync, com.apple.NanoTimeKit.face, com.apple.NanoUniverse.AegirProxyApp, com.apple.tursd, com.apple.FaceTime.FTConversationService, com.apple.Bridge.GreenfieldThumbnailExtension, etc.) Identical Missing-.app errors. Same apps disappear. Conclusion: this is not a bundle ID matching issue — adding more IDs doesn't help. The system fails to enumerate <companion-iOS-app>.app/Watch/ regardless of whitelist contents. Many users in my prior thread reported trying 100+ bundle ID combinations without success; this evidence explains why. Reproduction (no MDM required) Pair Apple Watch with iPhone normally. Generate a Configuration Profile with com.apple.applicationaccess + any non-empty allowListedAppBundleIDs array. Install via Apple Configurator's cfgutil install-profile, or AirDrop + Settings → Install. Within ~5 s, nanotimekitcompaniond errors appear (visible via idevicesyslog). Native Watch apps backed by an iOS companion stub disappear from the Watch's app grid and from face complications. Hypothesis MCRestrictionsPayload applies an enumeration filter that does not descend into .app/Watch/ subdirectories when computing visible apps. nanotimekitcompaniond consequently sees those directories as missing, the Watch's Carousel (SpringBoard equivalent) hides the apps, and NTKFaceSnapshotService can't load corresponding complications. Because profiled itself logs the payload as "not supported on any Watch version", this appears to be unintended bleed-through. Questions for Apple Is MCRestrictionsPayload / allowListedAppBundleIDs officially supposed to affect Apple Watch apps? profiled says no. Is there an undocumented bundle ID pattern (e.g. <companion>.watchapp, or a Bridge.app/Watch/ prefix) that needs whitelisting to keep native Watch apps visible? Is the recommended workaround to use blacklistedAppBundleIDs instead? Should the enumeration error (Missing .app from directory: .../Watch/) be tracked as a separate watchOS framework bug? Artifacts Curated evidence log with timestamps, profile installer events, and the eight Missing-.app errors is attached as forum-post-v2-evidence.log. Full idevicesyslog captures (multiple install/remove cycles, ~2M log lines) and the .mobileconfig files are available on request. Thanks — looking forward to guidance.

We came across reports on Medium and Apple Developer Forums suggesting that ApplicationToken and ActivityCategoryToken values issued by the FamilyControls framework are not guaranteed to be stable, that iOS may silently re-issue new tokens for the same apps after OS or app updates, making any previously stored tokens invalid. We are storing FamilyActivitySelection tokens encoded via JSONEncoder to a backend for long-term use, and relying on them inside a DeviceActivityMonitorExtension to restore and apply shields when a schedule fires. What we're trying to understand is: is this token instability still an active problem in iOS 16/17/18/26, and when a token does become invalid, does JSONDecoder actually throw a DecodingError giving us a clear signal, or does it decode successfully and ManagedSettingsStore just silently ignore the stale tokens with no error at all? On Medium, We Found That The Token Mutation Problem One of the more painful bugs in real production apps: application tokens are not guaranteed to be stable forever. iOS can silently issue new, different tokens for the same app. If your store contains the old token and the Shield delegate receives a new one, the delegate has no way to match them — it doesn’t know which store is responsible for the shield, or which blocking “profile” caused it. This has been reported by multiple developers of real Screen Time apps and confirmed across several Apple Developer Forum threads. There is no official fix yet. The workaround is defensive: when the ShieldConfigurationDataSource or ShieldActionDelegate receives a token you don't recognise, fall back to a generic shield UI rather than crashing or returning empty data. And never rely on token identity as a long-term stable key in your persistence layer — always re-derive from a fresh FamilyActivityPicker selection when the user re-activates a profile.

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()     }   }   }

⬇️ ANYONE ON APPLE'S SCREEN TIME TEAM, PLEASE READ THIS ⬇️ Let's summarize the situation. 3rd-party apps with screen time access can be disabled by going to Settings > Screen Time > Apps with Screen Time Access. That's fine. Now, if I want to make it harder to remove my restrictions, I can ask a friend to enter a Screen Time Passcode for me. Great idea! The problem is my Screen Time Passcode isn't requested when disabling permissions for a third-party app. It's required for modifying any other Screen Time setting EXCEPT permissions for 3rd party apps. This is frustrating. The Screen Time passcode is a great feature. Making it compatible with permissions granted through the Family Controls framework is our NUMBER ONE REQUEST from tens of thousands of users. This feature has been requested for a long time (iOS 16, iOS 17, …): https://forums.developer.apple.com/forums/thread/714651 https://forums.developer.apple.com/forums/thread/727291 https://discussions.apple.com/thread/255421819 FB13548526
 If you're a developer working on Screen Time, share your feedback below or file one using Feedback Assistant. It is very disappointing to see it wasn't implemented for iOS 18. I can't believe this would require tremendous work from the Screen Time team to make it happen, but it would be a significant improvement for the Family Controls Framework and a ray of sunshine for all the developers who have worked really hard to deliver high-quality apps using the Screen Time API. Could an Apple engineer or a Screen Time team member give us any updates? Implementing this before the public release of iOS 18 would make A LOT of developers happy.

Hello! I am experiencing some strange bugs around DeviceActivityEvents: When creating a DeviceActivityEvent we can assign a threshold and applicationTokens. The idea is, that after the user has spent said threshold on said apps, eventDidReachThreshold is called. includesPastActivity is set to false. On iOS 26 however, it happens (quite reliably after updating to a new beta seed) quite often that eventDidReachThreshold is called immediately (after a couple of seconds) instead of waiting for the threshold to be met. Is anyone else seeing similar issues on iOS 26? Only workaround I have found is to ask users to re-grant Screen Time permissions. This only holds for about two weeks though or at most until the next iOS 26 beta update is installed. Feedback filed under: FB18061981 FB18927456

I’m building an iOS app that uses FamilyControls + ManagedSettings + DeviceActivity. Goal: temporarily “unlock” a shielded app for N minutes, then automatically re-apply the shield when the timer expires. What I do: In the main app, when user picks an expiry (e.g. 15 min, 30 min). I start a non-repeating DeviceActivity schedule and remove the app’s ApplicationToken from ManagedSettingsStore().shield.applications. I also store activeUnlockBundleID etc. in an App Group so the DeviceActivityMonitor extension can re-lock at the end. Expected: DeviceActivityMonitor.intervalDidEnd(for:) is invoked when the non-repeating interval ends, and I re-add the token to the shield set. Actual: The app does not re-lock when the interval expires. I added OS logs as well as “debug local notifications” from the DeviceActivityMonitor extension in: init() intervalDidStart intervalDidEnd eventDidReachThreshold None of these logs or notifications ever appear, which suggests the extension is never invoked (or cannot schedule local notifications or OS logs). Environment: Device: iPhone 17 Pro iOS 26.3.1 Xcode 26.4 Running on a physical device Notification permissions for the app: granted App + extensions are in the same App Group entitlement. Extension Info.plist has: NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = $(PRODUCT_MODULE_NAME).DeviceActivityMonitorExtension Questions: Are there known limitations/requirements for DeviceActivityMonitor callbacks where intervalDidEnd doesn't to fire? Is posting local notifications / OS Logs from a DeviceActivityMonitor extension supported/reliable? If not, what’s the recommended way to verify the extension is invoked? If this looks like a platform bug, should I file Feedback Assistant? If so, what logs/artifacts are most useful?

Hello, I am the developer of an app called one sec which helps users to spend less time on social media: https://one-sec.app Therefore, we make heavy use of the Screen Time API, and thus ManagedSettings and ShieldActionDelegate. One feature of one sec is the so-called “Doom Scroll Emergency Brake”. This blocks a target app after a certain usage threshold (e.g. 5 minutes) and requires going through an intervention (e.g. breathing exercise) to unlock more time. That added friction makes it very effective in reducing time spent on apps. One thing that is confusing for our users is the way they are prompted to unlock more time, if they want to. They have to: Have Push Notifications enabled for one sec Exempt one sec’s notifications from being delayed by AI prioritization (otherwise they are delayed by ca. 10s) Ensure that push notifications can be delivered during foci. Understand that they have to tap on the notification, which is not very straight-forward because it does not make sense from the user’s UX perspective. This is an artificial limitation of Apple’s screen time framework which has no reason (no security / privacy implications here…). Screenshots of the current flow attached. If would be much more reasonable if there was a new ShieldActionResponse.openParentApp value that can be returned from the completion handler of the ShieldActionDelegate.handle(…) callback. We have seen different apps use private API to achieve this, but we are afraid to do the same to avoid getting banned from the App Store. It would be fair if Apple would level the playground for all apps and offer such an API officially. – Frederik PS: Tracked under FB22347946, FB18846650, FB15500681, FB15079668, FB10393561 (all without responses so far…)

Hello, my app is frequently loosing / forgetting the Screen Time Permission that had been granted previously on iOS 26. I have experienced it myself, sysdiagnose is in this radar: FB18997699 But also also my App Store users who have updated to iOS 26 already have reported this bug. It would be great if Apple could ensure that this bug is addressed before iOS 26 is released to the public.

Hello, according to reports from our users these two ManagedSettingsStore options seem to be stuck in the enabled state even after turning them off or removing screen time permissions and uninstalling the app that configured them. Is this possible? Has anyone seen it? The denyAppRemoval (https://developer.apple.com/documentation/managedsettings/applicationsettings/denyappremoval-swift.property) prevents the user from uninstalling any apps from their device when active. The denyAppInstallation (https://developer.apple.com/documentation/managedsettings/applicationsettings/denyappinstallation-swift.property) "hides" App Store, making it impossible to install any new apps. We haven't been able to replicate it yet. Does anyone know about workarounds when this happens? So far it seems like the only way is to reset the affected device.

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?

I'm building an app that uses the Family Controls / Screen Time APIs (FamilyControls, ManagedSettings). My app has three targets, each with a distinct Bundle ID: Main App Shield Configuration Extension ShieldAction Extension All three have com.apple.developer.family-controls in their entitlements files, and they share an App Group. My question is about the distribution entitlement request form at developer.apple.com/contact/request/family-controls-distribution: does the form need to be submitted once per Bundle ID, or is a single submission for the main app sufficient to then enable Family Controls (Distribution) for the extension Bundle IDs in the developer portal as well? I've seen conflicting reports in other forum threads — some developers say one submission covers all targets, others say separate submissions are needed per Bundle ID. I've already submitted the main app, but now I am wondering whether I should submit one for each Shield extension. Thanks!

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

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’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, Once I try to reset security question, it says: "Your request could not be completed. This action could not be completed due to an error. Please try again later." So I am unable to access account. Please help! Best Regards,

We are currently working on a SCEP server implementation that operates in FIPS-approved mode. In this mode, RSA PKCS#1 v1.5 encryption is disallowed due to compliance requirements, and only FIPS-approved padding schemes such as RSA-OAEP are permitted. However, we have observed that the SCEP client functionality on Apple devices currently does not support RSA-OAEP for CMS EnvelopedData decryption. This creates a challenge for us in ensuring FIPS compliance while maintaining compatibility with Apple devices during certificate enrollment through SCEP. We would appreciate your guidance on the following: Are there any alternative FIPS-approved encryption algorithms or configurations supported by Apple devices for SCEP CMS EnvelopedData decryption? Is there any plan or timeline for future support of RSA-OAEP on Apple platforms for this use case? Feedback raised along with sysdiagnose logs as well : FB17655410