Hello Apple Developer Community, I am looking for guidance regarding an Apple Developer Program organization enrollment issue. I am enrolling as a Company / Organization for my US LLC. My organization has a valid D-U-N-S Number, and Apple Developer's D-U-N-S lookup successfully recognizes my company information. I also received confirmation from Apple Developer Relations that my D-U-N-S information can be used for organization enrollment. However, my organization enrollment was declined without a clear explanation. During the previous review process, there was also a technical issue with my company email server, and I may have missed some communication from Apple Developer Support. The email issue has now been resolved. I am the founder and authorized representative of the company, and I can provide any required company documents or verification information. Has anyone experienced a similar situation where: D-U-N-S verification was successful, company information matched, but organization enrollment was still declined? Any advice on how to request a proper manual review would be appreciated. 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.

As of May 8th, 2026, after I upgraded to "codex-cli 0.129.0" via Xcode, I can no longer sign into my ChatGPT account in Xcode Intelligence Settings. The Log In window is always successful, but the settings never update to show the login being successful. It's a constant loop. Perhaps a hand-shake fail. Versions: Tahoe 26.3.1, Xcode 26.4.1, codex-cli 0.129.0.

Following up on my earlier thread about non-blocking interventions. I ran a clean, isolated test on iOS 26.5.2: I start DeviceActivityCenter.startMonitoring with a single event whose threshold is 2 minutes of usage for a selected app (includesPastActivity = false), with actions on eventDidReachThreshold. Result: the event's recorded trigger time is +0 seconds from monitoring start (immediate), it fires without any real usage, and after 2 minutes of actual use no notification and no ManagedSettings shield are applied. This matches the regression discussed in Forum thread 808470 / FB18061981. Concretely, the feature we want to build: while a user is using a selected app, deliver a repeating local notification every N minutes of usage (e.g., every 15 minutes) whose body states how many minutes they've used that app today (e.g., "You've used TikTok for 45 minutes today"). This is a gentle, factual awareness nudge — no blocking. This is exactly what eventDidReachThreshold with multiple thresholds (15/30/45 min…) + sendNotification would do, but that path is broken by the regression above. Questions: Is there a fix timeline for the eventDidReachThreshold immediate-fire regression (iOS 26.x)? Any FB to watch? What is the supported way to implement the feature above — a repeating notification every N minutes of usage, containing the cumulative minutes used today for that app — without relying on the broken threshold event? Specifically: a. How should we obtain the cumulative usage minutes for a selection to put in the notification body? Is the only source a DeviceActivityReport (which renders in an extension and isn't readable as a value in the app)? b. How should we trigger every N minutes of usage if threshold events are unreliable? Is there any usage-based trigger other than eventDidReachThreshold? Until a fix, is a DeviceActivitySchedule-based (wall-clock) approach the only reliable path? Is applying a ManagedSettings shield from the DeviceActivityMonitor extension expected to interrupt an app that is already in the foreground (mid-use), or only at next launch? Our app is non-blocking by design (a brief "pause" nudge + factual usage reminders), fully on-device, Family Controls (Distribution) approved. We'd rather build on a supported path. Thank you.

I'm building a consumer iOS app that helps users be more intentional about opening distracting apps. It never hard-blocks; it only nudges. I have Family Controls (Distribution) approved and a working TestFlight build using FamilyControls / DeviceActivity / ManagedSettings. I've confirmed from testing and the forums that: ShieldActionResponse is only .none / .defer / .close (no supported way to open my main app from the shield extension — threads 719905, 793060). ShieldConfiguration is a static snapshot (no countdown/animation; FB14237883). DeviceActivityMonitor events are threshold/schedule based and cannot hook "the app was just opened," and on iOS 26 eventDidReachThreshold fires immediately/incorrectly (thread 808470). I'd like to confirm the supported approaches for these UX patterns (each = every-app-open vs on-a-schedule): On app open, present my own full-screen UI (a brief non-blocking "pause") without requiring the user to manually create a Shortcuts personal automation. Is there any supported API for this, or is a user-created Shortcuts automation the officially recommended path? On app open, deliver a local notification (rather than UI) — supported only via a user-created Shortcuts automation, or is there another way? On a schedule / at fixed intervals, automatically bring my app's UI to the foreground (e.g., re-show a screen every N minutes) — I believe this is not allowed (apps can't self-foreground); can you confirm, and is a user-tapped notification the only path? On a schedule / at fixed intervals, send repeating local notifications while a usage limit is exceeded — given the iOS 26 eventDidReachThreshold regression, what's the recommended way to reliably detect "over limit" and drive repeating reminders? Some third-party apps appear to open their main app from a shield/monitor context. Is there any supported mechanism enabling that which I may have missed? I'd rather build on a supported path than risk anything review-sensitive. Guidance (or where to file an enhancement request) is appreciated. Thank you.

Hi, I’m using FamilyControls + DeviceActivity. Users select apps/categories/web domains via FamilyActivitySelection. I need to show today’s total usage for that selected group only, not the device’s full Screen Time. Setup: A visible DeviceActivityReport shows today’s per-app list with a daily DeviceActivityFilter for the selected tokens. This visible list is usually accurate and updates quickly. A separate hidden DeviceActivityReport uses the same filter to compute an aggregate total by summing app.totalActivityDuration in makeConfiguration(representing:). The extension sends that total to the main app via notify_set_state + Darwin notification. DeviceActivityMonitor is only used as a fallback. Problem: The visible app list stays current, but the aggregate total for the same selected apps sometimes lags by several minutes or updates only after new selected-app usage occurs. Sometimes the total appears temporarily frozen while the app list still looks correct. Questions: Is a hidden DeviceActivityReport a supported way to compute a selected-app aggregate total? Is makeConfiguration expected to run often enough for a near-live total? Why would the visible per-app report update while a hidden report with the same filter does not? What is the recommended architecture for a reliable, non-inflated today total for selected apps only? Thanks!

Summary: When applying a configuration profile that uses allowListedAppBundleIDs to permit a defined set of apps, essential Apple Watch apps are unexpectedly removed from the paired Watch — even though their associated iPhone bundle IDs are explicitly included. This issue occurs with a minimal profile, and has been consistently reproducible on the latest versions of iOS and watchOS. Impact: This behavior severely limits the use of Apple Watch in managed environments (e.g., education, family management, accessibility contexts), where allowlisting is a key control mechanism. It also suggests either: Undocumented internal dependencies between iOS and watchOS apps, or A possible regression in how allowlists interact with Watch integration. Steps to Reproduce: Create a configuration profile with a Restrictions payload containing only the allowListedAppBundleIDs key. Allow a broad list of essential system apps, including all known Apple Watch-related bundle IDs: com.apple.NanoAlarm com.apple.NanoNowPlaying com.apple.NanoOxygenSaturation com.apple.NanoRegistry com.apple.NanoRemote com.apple.NanoSleep com.apple.NanoStopwatch com.apple.NanoWorldClock (All the bundles can be seen in the Attached profile) Install the profile on a supervised or non-supervised iPhone paired with an Apple Watch. Restart both devices. Observe that several core Watch apps (e.g. Heart Rate, Activity, Workout) are missing from the Watch. Expected Behavior: All apps explicitly included in the allowlist should function normally. System apps — especially those tied to hardware like Apple Watch — should remain accessible unless explicitly excluded. Actual Behavior: Multiple Apple Watch system apps are removed or hidden, despite their iPhone bundle IDs being listed in the allowlist. Test Environment: iPhone running iOS 18 Apple Watch running watchOS 11 Profile includes only the allowListedAppBundleIDs key Issue confirmed on fresh devices with no third-party apps Request for Apple Engineering: Please confirm whether additional internal or undocumented bundle IDs are required to preserve Apple Watch functionality when allowlisting apps. If this behavior is unintended, please treat this as a regression or bug affecting key system components. If intentional, please provide formal documentation listing all required bundle IDs for preserving Watch support with allowlisting enabled. Attachment: .mobileconfig profile demonstrating the issue (clean, minimal, reproducible) Attached test profile = https://drive.google.com/file/d/12YknGWuo1bDG-bmzPi0T41H6uHrhDmdR/view?usp=sharing

On a supervised device running iOS 18 without any AirDrop restrictions applied, when a profile with allowListedAppBundleIDs restriction key is installed, the AirDrop sound plays. But still the accept prompt does not appear, making it impossible to accept files. The prompt works as expected on iOS 18 devices to which the allowListedAppBundleIDs restriction is not installed. This issue occurs only on supervised iOS 18 devices to which the allowListedAppBundleIDs restriction is being applied. Device must be in iOS 18 version > Install the (allowListedAppBundleIDs restriction) profile with the device > Try to AirDrop files to the managed device. The expected result is that the accept prompt must pop up but it does not appear. This issue is occurring irrespective of any Whitelisted bundle ID being added to the allowListedAppBundleIDs restriction profile. Have attached a few Whitelisted bundle ID here com.talentlms.talentlms.ios.beta, com.maxaccel.safetrack, com.manageengine.mdm.iosagent, com.apple.weather, com.apple.mobilenotes, gov.dot.phmsa.erg2, com.apple.calculator, com.manageengine.mdm.iosagent, com.apple.webapp, com.apple.CoreCDPUI.localSecretPrompt etc. Have raised a Feedback request (FB15709399) with sysdiagnose logs and a short video on the issue.

Case ID: 102924093872 Case ID: 102924089648 Hi Apple Support Team, I’m reaching out regarding a critical issue that is blocking my app testing and affecting hundreds of users. I cannot receive the two-factor authentication code for my Apple Developer account. My mobile operator has confirmed that SMS messages from Apple are not reaching their network at all. I also receive no calls. Since my account is not logged in on any device, SMS is the only way I can verify my identity - and it’s not working. I have already submitted two support cases but have not received any response yet. Here is the impact this is having right now: • 250+ people are waiting to get access to test my app • 400 users are already using the app • I cannot sign the new agreement that appeared in App Store Connect • Because of this, TestFlight is completely blocked - both the 10,000 user limit and the 100 user internal testing • Even when I add someone to my team and grant them access, it still doesn’t work for them either I have been building this app for almost 7 months. We are in the final testing stage before I plan to release it for sale. Every day without access is a day my users are waiting and I cannot move forward. I am asking you to please help me resolve this as quickly as possible. I really need your support right now. Thank you so much for your time. Best regards, Tata

I am currently testing Managed Open-In restrictions in an MDM-managed environment on iPadOS 27 beta. I have observed that the restrictions "allowOpenFromManagedToUnmanaged" and "allowOpenFromUnmanagedToManaged", even when set to false, are still being bypassed in certain scenarios. Specifically, I observed two issues: Photos App – Images opened from a managed application can still be saved using the Save to Photos option. Shortcuts App – Custom Shortcuts triggered from the Share Sheet can accept managed content, compress it into an archive, and share that archive with unmanaged applications, effectively bypassing the Managed Open-In restrictions. According to the iPadOS 27 beta release notes, both of these issues were marked as resolved. However, they remain reproducible in my testing on a supervised MDM-enrolled device. I have submitted a detailed report with a sys diagnose log via the Feedback Assistant (FB ID:FB23316986).

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.. 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!

Dear Screen Time Team! The current 6 MB memory limit for the DeviceActivityMonitor extension no longer reflects the reality of modern iOS devices or the complexity of apps built on top of the Screen Time framework. When Screen Time APIs were introduced with iOS 15, hardware constraints were very different. Since then, iPhone performance and available RAM have increased significantly…but the extension memory limit has remained unchanged. My name is Frederik Riedel, and I’m the developer of the screen time app “one sec.” Our app relies heavily on FamilyControls, ManagedSettings, and DeviceActivity to provide real-time interventions that help users reduce social media usage. In practice, the 6 MB limit has become a critical bottleneck: The DeviceActivityMonitor extension frequently crashes due to memory pressure, often unpredictably. Even highly optimized implementations struggle to stay within this constraint when using Swift and multiple ManagedSettings stores. The limit makes it disproportionately difficult to build stable, maintainable, and scalable architectures on top of these frameworks. This is not just an edge case…it directly impacts reliability in production apps that depend on Screen Time APIs for core functionality. Modern system integrations like Screen Time are incredibly powerful, but they also require a reasonable amount of memory headroom to function reliably. The current limit forces developers into fragile workarounds and undermines the robustness of apps that aim to improve users’ digital wellbeing. We would greatly appreciate if you could revisit and update this restriction to better align with today’s device capabilities and developer needs. Thank you for your continued work on Screen Time and for supporting developers building meaningful experiences on top of it. Feedback: FB22279215 Best regards, Frederik Riedel (one sec app)

Dear Developer Technical Support, I wanted to ask for technical advice regarding the DeviceActivityMonitor which is part of the DeviceActivity framework: The DeviceActivityMonitor has a very strict memory limit of 6MB. That’s not a lot and it doesn't leave a lot of room for any kind of code that accesses permanently stored data. I would therefore like to ask for advice on best-practices on how to share information between the main app and that extension: Is UserDefaults a good idea to use here? Can/should we use CoreData or SwiftData? Should we build super small file-based data sharing (e.g. via .plists)? Why is it necessary to share data? This can be simple things that inform the decision of the device activity monitor in intervalDidStart, intervalDidEnd, eventDidReachThreshold, eventWillReachThresholdWarning. For example a setting where the user decides if they want to receive a push notification on eventWillReachThresholdWarning. Or the list of tokens that is supposed to be blocked in eventDidReachThreshold or intervalDidStart. I’m asking because even though we are super careful and conservative about memory allocations in our DeviceActivityMonitor we are regularly seeing it being killed due to memory pressure. What’s the best way to approach this? I’m grateful for any kinds of hints! Thanks a lot and have a great day! – Frederik

Hi everyone, I’m the developer of one sec, an app used by a large number of users globally to reduce time spent on social media and to build healthier digital habits. Because of this, we rely heavily on Apple’s Screen Time / DeviceActivity / FamilyControls, ManagedSettings APIs – and unfortunately, we’re seeing increasingly severe issues in production that directly impact hundreds of thousands of real iOS users. During the past years, we have been busy filing dozens of feedback requests for different Screen Time issues – and there has been no response from Apple at all. Developer Relations might be able to "confirm" that the bugs are present and that they ended up with the right team – but they are never addressed, neither are workarounds provided. Instead, the situation gets worse and worse. iOS 26 introduced a series of heavy regressions (which have been reported via Apple’s official bug report tool "Feedback Assistant" on iOS 26 beta 1 in June 2025 – and have not been addressed 10 Months later). This is very frustrating for us as developers, but also for our end-users who run into these issues every day. In the end this impacts our ability to build an amazing product and hurts revenue (which affects both us and Apple). 1. DeviceActivity thresholds are not firing at all This affects both: our app’s usage of the API and Apple’s own Screen Time limits Radars: FB22304617, FB20526837, FB15491936, FB12195437, FB15663329, FB18198691, FB18289475, FB19827144 2. Screen Time usage data is clearly corrupted Websites showing hundreds of hours per week Up to ~20 hours per day of usage reported for a single domain Radars: FB22304617, FB17777429, FB18464235 3. DeviceActivity thresholds reaching threshold immediately Newly introduced with iOS 26 Reported on iOS 26 beta 1 in June No response so far / no workaround DeviceActivity calls didReachThreshold immediately after creating the DeviceActivityEvent – instead of waiting till the defined threshold is actually reached. Radars: FB13696022, FB18351583, FB21320644, FB18927456, FB18061981 4. Randomly Randomizing ApplicationTokens From time to time, and without consistency, Screen Time suddenly provides new, random, unknown tokens to my app in the ShieldConfigurationDataSource and ShieldActionDelegate. This has been reported on many times before here on the dev forms, many many years back already: https://forums.developer.apple.com/forums/thread/756440 https://forums.developer.apple.com/forums/thread/758325 https://forums.developer.apple.com/forums/thread/758325?answerId=793267022#793267022 Radars: FB14082790 and FB18764644 5. Moving Tokens from one ManagedSettingsStore to Another Removing an ApplicationToken from one SettingsStore and then adding it to another while the target app remains in foreground leads to the re-use of the ShieldConfiguration. Which can be wrong in many scenarios. It is not possible to request a re-request of the ShieldConfiguration in that scenario. Radar: FB14237883 6. Unable to Open Parent App (one sec) from Shield Many times, when a target app is blocked by a shield, the user wants to perform some action (e.g. to unlock more time for the target app via an intervention). That means, that somehow I have to forward the user from a ShieldActionDelegate back into my target app. Unfortunately, there’s no API for that. Many apps on the App Store rely on private API to achieve that, but that’s too risky for a popular app like one sec. Radar: FB15079668 7. Unable to Open Target App from an ApplicationToken When a user has completed an intervention within one sec, and they indend to to continue to the target app, there is no way that one sec can open the target app just from the token alone. Sure, there are URL schemes, but that means the user has to manually assign URL schemes to each ApplicationToken. That is not a very user friendly process (and in many cases impossible, because not every app registers URL schemes). It would be better if there was a way that my app could open a target app directly from an ApplicationToken, e.g. via an AppIntent that can be run on a button press. This way, the selected apps would remain fully private while still offering advanced functionality: struct OpenTargetAppIntent: AppIntent, OpenAppFromApplicationTokenIntent { func perform() { return .result(openAppFromApplicationToken: applicationToken) } } Radar: FB15500695 Summary Thanks a lot for taking the time to read my feedback. If you have any questions, please feel free to reach out to me any time. I’m always happy to provide more details, logs, and steps to reproduce in my radars / feedback requests or in-person in Cupertino. It would be extremely helpful if someone from the Screen Time / DeviceActivity engineering team could: Take a look at the listed radars. Work on bug fixes and be transparent about when fixes will be shipped. Provide workarounds in the meantime. We genuinely want to build great, reliable experiences on top of Screen Time – but in its current state, it’s becoming very difficult to depend on. – Frederik

Hi. I am going through my first App publishing. I had an issue that they cannot login but I don’t understand the issue. For my app login is not required. I have a password needed one time to get in and I provided that in the notes. They shared back the password did not work but I validated again and it is the right password. Any thoughts or feedback. Not really sure what to else to do.

I am seeing a reproducible App Switcher rendering artifact with ManagedSettingsUI shield customization. When a Screen Time shield is customized with ShieldConfiguration.backgroundColor, the shield appears with an uncropped rectangular background layer in the iOS App Switcher. Square corners become visible around the shield card/background layer. This disappears when backgroundColor is nil, and reappears as soon as any UIColor is provided. I also observed the same behavior in another Screen Time app that customizes its shield background, so this does not appear to be specific to my app. Minimal repro: Create an iOS app using FamilyControls, ManagedSettings, and ManagedSettingsUI. Add a ShieldConfigurationDataSource extension. Return a ShieldConfiguration with backgroundColor set to any UIColor. Shield an app and open the shielded app. Open the iOS App Switcher. Example: return ShieldConfiguration( backgroundBlurStyle: .regular, backgroundColor: UIColor(red: 246/255, green: 238/255, blue: 227/255, alpha: 1) ) Expected: The shield background should be clipped consistently with the App Switcher card/screen corner mask. Actual: The shield background appears as a full rectangular layer in the App Switcher, exposing square corners. Control tests: backgroundColor = nil: no square-corner artifact. backgroundColor = UIColor(...): square-corner artifact appears. The issue occurs regardless of backgroundBlurStyle, including nil, .regular, and .systemUltraThinMaterialLight. I filed this through Feedback Assistant as well. Has anyone found a workaround that still allows a custom shield background color?

Hello, I’m trying to clarify whether the new Age Range / Age Assurance Setup Assistant pane can be skipped on macOS when using a standard MDM Device Enrollment flow, not Automated Device Enrollment. Environment: Platform: macOS Tahoe 26.5.1 Enrollment type: MDM Device Enrollment, not ADE / DEP MDM: Microsoft Intune Profile deployment channel: Device profile Payload type: com.apple.SetupAssistant.managed Key used: SkipSetupItems Skip items tested: AgeAssurance AgeBasedSafetySettings The configuration profile installs successfully on the Mac as a device profile. I can confirm that the com.apple.SetupAssistant.managed payload is present on the device and includes the tested SkipSetupItems values. However, the Age Range / age-related Setup Assistant pane is still shown to the user. Example payload content: <dict> <key>PayloadType</key> <string>com.apple.SetupAssistant.managed</string> <key>PayloadIdentifier</key> <string>com.example.setupassistant.managed</string> <key>PayloadUUID</key> <string>REDACTED-UUID</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadDisplayName</key> <string>Managed Setup Assistant</string> <key>SkipSetupItems</key> <array> <string>AgeAssurance</string> <string>AgeBasedSafetySettings</string> </array> </dict> What I expected: When the com.apple.SetupAssistant.managed payload is installed as a device-level profile and includes the relevant age-related skip keys, the Age Range / Age Assurance pane should be skipped during Setup Assistant, or Apple documentation should state clearly that this pane can only be skipped in ADE. What actually happens: The profile installs, but the Age Range / age-related Setup Assistant pane still appears to the user on macOS 26.5.1. Documentation ambiguity: Apple’s Setup Assistant payload documentation says: The supported payload identifier is com.apple.SetupAssistant.managed Supported operating systems/channels include macOS device and macOS user Supported enrollment methods include User Enrollment, Device Enrollment, and Automated Device Enrollment SkipSetupItems is a list of Setup Assistant panes that can be skipped Apple’s macOS Tahoe 26 enterprise notes say: “The new Age Range setup pane is automatically skipped for devices using Automated Device Enrollment.” That wording clearly mentions ADE, but I have not found documentation that explicitly states whether the Age Range pane is intentionally unsupported for non-ADE macOS MDM enrollment, or whether there is a separate skip key required for macOS. Third-party MDM/tooling documentation appears to reference the following newer skip keys: AgeAssurance AgeBasedSafetySettings However, it is unclear whether those keys are supported on macOS, iOS/iPadOS only, ADE only, or all MDM enrollment methods. Questions: Are AgeAssurance and AgeBasedSafetySettings valid SkipSetupItems values on macOS 26.5.1? If yes, are they supported only during Automated Device Enrollment, or should they also work with standard MDM Device Enrollment? If these keys are iOS/iPadOS-only, what is the correct macOS skip item for the Age Range / age-related Setup Assistant pane? Is the Age Range pane intentionally only auto-skipped in ADE on macOS? Should Apple’s public Device Management / SkipKeys documentation be updated to list the correct key names, supported platforms, minimum OS versions, and enrollment requirements? This is important for Mac deployments where devices are enrolled into MDM but are not assigned through Apple Business Manager / Automated Device Enrollment. At the moment, it is difficult to determine whether the behavior is expected, unsupported, or a bug in macOS / Setup Assistant / MDM profile handling. Thanks.

Hello, we’re seeing a rather serious regression on iOS 26.6: The issue appears to reproduce with a single named ManagedSettingsStore: import ManagedSettings let store = ManagedSettingsStore(named: ManagedSettingsStore.Name("specific")) store.webContent.blockedByFilter = .specific([ WebDomain(domain: "specific-domain-marker.example") ]) Expected behavior: Only the explicitly configured .specific(...) web domain filter should be reflected in the effective ManagedSettings / ManagedConfiguration state. Observed behavior: After configuring this single store with .specific(...), I’m seeing unexpected additional websites being blocked (mostly adult content) which should only happen when using the .auto(…) API. Documented under FB22890915 with Sample Project and Sysdiagnose.

Some of our users encounter an issue after updating their iPhone/iPad to iOS 17.5.1. The tokens passed in the Shield Configuration extension don't match the tokens they selected in my app using the FamilyPicker before updating to iOS 17.5.1. It seems the tokens changed for no reason. My app can't match the token from the ShieldConfigurationDataSource to any tokens stored on my end, causing my shield screens to turn blank. The same applies to tokens in the Device Activity Report extension. The only workaround I've found is to tell affected users to unselect and reselect apps and websites to block in my app. This gets them new tokens from the FamilyActivityPicker, which solves the issue. However, for some users, the bug reoccurs a few days later. Tokens seem to change again, causing the same issue in the Shield Configuration extension. I am not able to reproduce the issue on my test devices so I have no sysdiagnose to attach. However, this issue is affecting other screen time apps: https://developer.apple.com/forums/thread/732845 https://forums.developer.apple.com/forums/thread/756440 FB14082790 FB14111223 A change in iOS 17.5.1 must have triggered this behaviour. Could an Apple engineer give us any updates on this?

Hello, I have submitted multiple requests for the Family Controls Distribution Entitlement through this form: https://developer.apple.com/contact/request/family-controls-distribution After submitting my requests, I waited for about 1 week but did not receive any response. Since I heard nothing, I contacted Apple Developer Support by email. After that, I finally received a response from an advisor asking for additional information, including my follow-up number. I replied with all the requested information immediately, but it has now been 5 more days and I still have not received any further response. In total, I have been waiting for about 2 weeks for this entitlement request. My app is a Screen Time control / digital wellbeing application that helps users reduce screen time through exercise-based challenges and healthy habits. My app uses the FamilyControls, ManagedSettings, and DeviceActivity frameworks and requires the Distribution Entitlement for App Store release. Here are my details: Case Number: 102866460896 Request Type: Family Controls Distribution Entitlement I understand the team may be busy, but I would appreciate any help checking the status of my request or escalating it if possible. Thank you very much.