I took notes during the "What's new in managing Apple Devices" session. If interested, please see the attached "Notes from session": Session Notes For the session video, please see the following link: https://developer.apple.com/wwdc22/10045

Anyone aware of a work around for the followiing? Using an unsupervised device. iOS 26.5, MacOS 26.5.1, cfgutil 2.20 (1001.5), App Configurator 2.20 (11B11), on an iMac 2024 and an iPhone 16 Pro cfgutil get-icon-layout works as expected, returning the app layout list. Add an app to any page from the App Library. Rerun the command and a crash is the result. *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil' *** First throw call stack: ( 0 CoreFoundation 0x00000001854a91c0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x0000000184f3291c objc_exception_throw + 88 2 CoreFoundation 0x00000001853db9dc -[__NSArrayM insertObject:atIndex:] + 1864 3 cfgutil 0x0000000104cc2df4 cfgutil + 44532 4 cfgutil 0x0000000104cc2ce4 cfgutil + 44260 5 cfgutil 0x0000000104cc2ce4 cfgutil + 44260 6 cfgutil 0x0000000104cc3104 cfgutil + 45316 7 cfgutil 0x0000000104cd3d14 cfgutil + 113940 8 cfgutil 0x0000000104ccee68 cfgutil + 93800 9 dyld 0x0000000184fbfe00 start + 6992 ) libc++abi: terminating due to uncaught exception of type NSException

When deploying Macs through Automated Device Enrolment (ADE), we've found that automatic date and time configuration still depends on the Location Services pane in Setup Assistant being enabled. What's particularly interesting is that macOS already determines and pre-selects the correct language and country/region before enrolment begins, which suggests that some form of geographic awareness already exists during setup, whether through GeoIP, network-based location detection, or another mechanism. Despite this, the correct time and time zone are not automatically configured unless Location Services is enabled. For organisations pursuing zero-touch deployments, this creates an unnecessary dependency on a privacy-related feature purely to obtain accurate time settings. Today, administrators often resort to workarounds after enrolment, such as: Using scripts to configure time settings via systemsetup. Modifying the authorisation database to permit automated changes. These approaches introduce additional complexity, require elevated privileges, and create deployment dependencies that should not be necessary for such a fundamental operating system function. If macOS is already geographically aware enough to determine the correct language and region during Setup Assistant, it should also be capable of automatically configuring the correct date, time and time zone without requiring user interaction with Location Services. Benefits would include: True zero-touch and near zero-touch deployment workflows. Fewer Setup Assistant prompts and reduced user interaction. Accurate date, time and time zone configuration immediately after enrolment. Elimination of unnecessary post-enrolment scripting and workarounds. Improved privacy by avoiding the need to enable Location Services solely for time configuration. A more streamlined enterprise deployment experience across all MDM platforms. This would bring date and time configuration in line with the existing automatic language and region detection behaviour already present during ADE and significantly improve Mac deployment workflows at scale. I've already submitted Feedback Assistant report FB21973612 for this enhancement request. This has been a well-known pain point for Mac administrators for many years, particularly for organisations striving to achieve fully automated and consistent provisioning workflows.

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 am developing a macOS system service (standalone binary running as a LaunchDaemon) that requires the ability to sign data using a private key which will be deployed via MDM. The Setup: Deployment: A .mobileconfig pushes a PKCS12 identity to the System Keychain. Security Requirement: For compliance and security reasons, we cannot set AllowAllAppsAccess to <true/>. The key must remain restricted. The Goal: I need to use the private key from the identity to be able to sign the data The Problem: The Certificate Payload does not support a TrustedApplications or AccessControl array to pre-authorize binary paths. As a result, when the process tries to use the private key for signing (SecKeyCreateSignature), it prompts the user to allow this operation which creates a disruption and is not desired. What i've tried so far: Manually adding my process to the key's ACL in keychain access obviously works and prevents any prompts but this is not an "automatable" solution. Using security tool in a script to attempt to modify the ACL in an automated way, but that also asks user for password and is not seamless. The Question: Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key? If not, is there a better way to achieve the end goal?

I am currently working on mdm.push-token status item subscription via the DDM User Channel while testing on Beta OS 27. I have observed that the User Channel subscription consistently returns the device's push token rather than a unique user-specific push token. This behaviour is persistent across both macOS and Shared iPad environments. Before I conclude that this is a bug, I would like to clarify if this is the expected behaviour for the DDM User Channel. If so, could anyone provide guidance on the correct or alternative method to retrieve a unique, user-specific push token within the DDM framework to ensure proper notification routing? I have submitted a detailed report with a sys diagnose log via the Feedback Assistant (FB ID:FB23214856). Any insights or documentation references would be greatly appreciated.

Hi Apple Community, Problem : Should be able to use my iDP password when I try to unlock my macOS local User Account.
 Password should sync across my macOS local User Account, when my User Account Password in iDP Changed
 Should have a provision to create a on-demand macOS local account with password of iDP Should be able to Create Primary Account in Automated Device Enrollment with password synced to iDP ( Simplified PSSO in Setup Assistant ) Solution : These can be solved if the Identity Provider implements Platform SSO , but not being implemented by all major Identity Providers Except major iDPs like Okta, Microsoft, Ping 
Since Platform SSO Offers the necessary framework and provision that satisfy the above needs I planned to make a open-source initiative to bridge in PSSO and Oauth ROPG to connect with Any OpenID Provider that supports Oauth ROPG 
I KNOW PSSO DOESN’T MEANT FOR THIS AND NEEDS TO BE IMPLEMENTED BY IDP, AND MEANINGFUL SSO TOKENS CAN BE ONLY ISSUED BY THEM TO HELP THE SSO EXTENSION 
But the native login Experience, FileVault Synchronization, Keychain Unlock everything being handled by OS in PSSO. I thought its best to go in this way The Attachment Includes the Components, Design Decisions of this Project , Questions in the PSSO Framework workflow. Including some Questions from new WWDC26 OpenID Authentication Method introduced in PlatformSSO Please help with the Questions in the Attachment and post if there is any suggestions on the workflow I described Filed Feedback with FB23065453

Hey guys, I'm building a managed macOS app (credential-provider extension) that needs an MDM-provisioned, hardware-bound, attested identity via the ManagedApp framework on macOS 27 which just released days ago, and I've hit a documentation contradiction. By reading through the docs, my understanding of the ManagedApp identity path is com.apple.configuration.app.managed → Identities → com.apple.asset.credential.acme. But the OS27 ACME schema says, for both HardwareBound and Attest: "On macOS, this is a required key. Set the value to false" (https://github.com/apple/device-management/blob/seed_OS_27_0/declarative/declarations/assets/credentials/acme.yaml#L66) — implying a software key. However, the macOS 27 release notes say ManagedApp deploys "hardware-bound identities" on macOS. So I am wondering that on macOS 27 + Apple silicon, can a ManagedApp-provisioned ACME identity actually be HardwareBound: true / Attest: true? If yes, is the acme.yaml "set to false on macOS" text just stale? If no, how is the documented "hardware-bound identities" capability delivered? And would that identity gonna be able to be used by the app / app extension? Thanks!

We would like to enforce the use of Managed Apple IDs on company-owned devices. At the same time, users should be able to install free applications on their own without requiring administrators to deploy every app through MDM, as this creates additional administrative overhead. Why is this required? The primary objective is to ensure that company-owned devices are used only with corporate-managed accounts and to prevent corporate data from being synced, backed up, or transferred to employees' personal iCloud accounts. This helps protect organizational data and reduces the risk of company information remaining accessible after an employee leaves the organization or stops using the device. We are looking for a solution that enforces Managed Apple ID usage while still allowing users the flexibility to install free apps independently.

Hey guys, I posted a similar thread in Privacy channel earlier, but their engineer points me to here: https://developer.apple.com/forums/thread/831492 I'm building a managed macOS app (credential-provider extension) that needs an MDM-provisioned, hardware-bound, attested identity via the ManagedApp framework on macOS 27 which just released days ago, and I've hit a documentation contradiction. By reading through the docs, my understanding of the ManagedApp identity path is com.apple.configuration.app.managed → Identities → com.apple.asset.credential.acme. But the OS27 ACME schema says, for both HardwareBound and Attest: "On macOS, this is a required key. Set the value to false" (https://github.com/apple/device-management/blob/seed_OS_27_0/declarative/declarations/assets/credentials/acme.yaml#L66) — implying a software key. However, the macOS 27 release notes say ManagedApp deploys "hardware-bound identities" on macOS. So I am wondering that on macOS 27 + Apple silicon, can a ManagedApp-provisioned ACME identity actually be HardwareBound: true / Attest: true? If yes, is the acme.yaml "set to false on macOS" text just stale? If no, how is the documented "hardware-bound identities" capability delivered? And would that identity gonna be able to be used by the app / app extension? Thanks!

We found an issue where the DetailURL configured in a Declarative Device Management OS update declaration is displayed on the device’s Software Update screen, but tapping the link does not open the URL on some iOS versions. This issue appears to occur specifically on iOS 26.4. The same behavior could not be reproduced on iOS 17.x or iOS 18.x devices using the same MDM command configuration and the same URL. Environment: MDM command: Declarative OS Update command Command configuration: Target OS Version: 26.5 Build Version: 23F77 DetailURL: Appleデバイスのソフトウェアアップデート宣言型構成 - Apple サポート (日本) Device requirements: Supervised iOS device Managed by MDM Connected to Wi-Fi OS update available No Safari restriction or browser launch restriction configuration profile applied Reproduction Steps: Prepare a supervised iOS device managed by MDM. Send a Declarative Device Management OS update command with the following configuration: Target OS Version: 26.5 Build Version: 23F77 DetailURL: Appleデバイスのソフトウェアアップデート宣言型構成 - Apple サポート (日本) After the command is applied, open the device Settings app. Go to General > Software Update. Confirm that the URL configured in DetailURL is displayed on the Software Update screen. Tap the displayed URL. Expected Result: The displayed DetailURL should open in Safari or the default browser. Actual Result: On iOS 26.4 devices, the URL is displayed on the Software Update screen, but tapping the link does not open Safari or navigate to the URL. On other tested iOS versions, the URL opens correctly. Test Results: Reproduced / Not working: iPhone 15 Pro, iOS 26.4: reproduced 3/3 iPhone 17e, iOS 26.4: reproduced Not reproduced / Working: iPhone SE, iOS 17.7: Safari opens successfully iPhone 14 Pro Max, iOS 17.6.1: Safari opens successfully, 0/3 reproduced iPhone 12 Pro, iOS 18.7.7: Safari opens successfully iPhone 11 Pro Max, iOS 18.7.8: Safari opens successfully, 0/3 reproduced Additional Notes: We confirmed that Safari usage restrictions and browser launch-related configuration profiles were not applied on the affected test device. A sysdiagnose was collected from the affected iPhone 15 Pro running iOS 26.4. From the logs, it appears that the Settings app / Preferences attempts to open Safari, but the URL cannot be opened. The log suggests that an invalid or unexpected URL may be passed from the Settings app when the Software Update screen link is tapped. This issue does not appear to be specific to the MDM server implementation, because the same Declarative OS Update configuration works correctly on iOS 17.x and iOS 18.x devices. Based on current testing, this may be an iOS 26.4-specific issue with how the Software Update screen handles the DetailURL link.

Hi, We're implementing a DDM-capable MDM server. A DEP-enrolled, supervised iPad (iOS 26.4.2) successfully completes manifest synchronization but never proceeds to fetch the individual declaration bodies. Looking for guidance on what we might be missing. Observed flow (from our server logs): We enqueue a DeclarativeManagement MDM command and APNs-wake the device. The command body is: RequestTypeDeclarativeManagement (no Data field) Device acknowledges the command on the Connect endpoint (Status=Acknowledged). Device calls CheckIn with: MessageType = DeclarativeManagement Endpoint = tokens We respond 200 with: { "SyncTokens": { "DeclarationsToken": "", "Timestamp": "2026-05-19T..." } } Device calls CheckIn with: MessageType = DeclarativeManagement Endpoint = declaration-items We respond 200 with: { "Declarations": { "Activations": [{"Identifier":"...","ServerToken":"v1-..."}], "Configurations": [{"Identifier":"...","ServerToken":"v1-..."}], "Assets": [], "Management": [] }, "DeclarationsToken": "" } ---- Nothing further. ---- No request for Endpoint = declaration/activation/ No request for Endpoint = declaration/configuration/ No status report on Endpoint = status The MDM channel is healthy. The same device responds normally to non-DDM commands (DeviceInformation, etc.) immediately before and after this flow. Questions: Is an empty "Management" array acceptable in the declaration-items response, or is at least one declaration (e.g. com.apple.management. organization-info) required before the device will proceed to fetch declaration bodies? The DeclarationsToken returned in step 3 (tokens) and step 4 (declaration-items) are byte-identical. Is that correct, or should they differ in some way? Are there any additional preconditions for the device to begin fetching declaration bodies after receiving the manifest -- e.g. a specific Activation->Configuration linkage we might be missing? Is there a server-side log signal Apple can suggest we look for, or a way to see why the device decided not to fetch? Activation payload sample we publish: { "Type": "com.apple.activation.simple", "Identifier": "...", "ServerToken": "v1-...", "Payload": { "StandardConfigurations": ["<configuration-identifier-from-step-4>"] } } Configuration payload sample we publish: { "Type": "com.apple.configuration.softwareupdate.settings", "Identifier": "...", "ServerToken": "v1-...", "Payload": { ... softwareupdate settings ... } } Any pointers appreciated. Happy to share full server-side logs / payloads if useful. Thanks.

Hi, I have a question regarding the relationship between the Apple Developer Enterprise Program membership and an existing APNs certificate used for MDM. Current Situation We are operating an MDM server. We have already obtained a valid APNs certificate via the Apple Push Certificates Portal. Our Apple Developer Enterprise Program membership is about to expire. The only asset we have in the Enterprise account is the MDM CSR used during the APNs certificate issuance process. Question If the Apple Developer Enterprise Program Membership expires: Will the existing APNs certificate remain valid until its expiration date? Or will it become invalid immediately due to the account expiration? Thank you.

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

We've put in a feedback assistant request, but not sure if we will get feedback in that channel or not and also want to highlight for others. When replacing a basic passcode profile on a macOS device with a passcode declaration, the user is required to change the password after logging out and back in. Explicitly including the "ChangeAtNextAuth" key set equal to false, set required a password change after logging out and back in. Once the declaration is active and the password has been changed, future updates to the passcode declaration do not require a password change unless the existing password is not compliant. Steps to reproduce: Install a basic passcode profile on a macOS device Ensure the existing password matches the requirements specified in the profile Install a passcode declaration with the same settings as the passcode profile currently installed Remove the traditional passcode profile from the device After the passcode declaration is installed, check the local pwpolicy with the command pwpolicy getaccountpolicies and look for the key policyAttributePasswordRequiredTime Log out of the macOS device Log back into the macOS device and you are presented with a change password prompt Expected result: Simply replacing an existing passcode profile with the exact same settings in a passcode declaration should not require a password change if the existing password is compliant. Actual results: After replacing the passcode profile with a passcode declaration, a password change was required even though the existing password was compliant. Initial testing was done with a macOS VM running 15.5. Additional testing has now been done with a macOS VM running 26.4.1 and the same behavior was observed.

Is there any iOS API, framework, or entitlement (public or beta) that lets an app detect when a user disables or removes a Configuration Profile (specifically a DNS-over-HTTPS profile) — without VPN extension, MDM, or supervised mode? Use case: I need to know server-side, in real time, when the user toggles off a .mobileconfig DoH profile they previously installed. Things I've already reviewed and ruled out: NetworkExtension (NEDNSSettingsManager — only fires while app is running) BGTaskScheduler (iOS-scheduled, not real-time) NEFilterDataProvider (requires supervised) VPN / MDM / supervised Anything I'm missing?

We are developing an MDM agent app that uses FamilyControls with .individual authorization to enforce Screen Time restrictions (app blocking, domain blocking via ManagedSettingsStore and DeviceActivityCenter). The Problem We are actively subscribing to AuthorizationCenter.shared.$authorizationStatus to detect authorization changes. However, when the user revokes the app's FamilyControls authorization through Settings (either via Settings > Screen Time > Apps With Screen Time Access, or Settings > Apps > [Our App]), the publisher does not emit any value. All ManagedSettingsStore restrictions are lifted immediately by the system, but our app receives no notification of this change. The only scenario where the publisher reliably emits is when a debugger is attached (i.e., running directly from Xcode). Without the debugger, the publisher is completely silent — even when the app returns to foreground. Code Example We tried subscribing directly to AuthorizationCenter.shared.$authorizationStatus with no intermediary, exactly as shown in the documentation: AuthorizationCenter.shared.$authorizationStatus .sink { status in print("[DIRECT] authorizationStatus emitted: \(status)") } .store(in: &cancellables) This subscription is set up at app launch and stored in cancellables. The result is the same — the publisher does not emit when the user revokes authorization in Settings without a debugger attached. Documentation Reference The documentation for authorizationStatus states: "The status may change due to external events, such as a child graduating to an adult account, or a parent or guardian changing the status in Settings." And: "The system sets this property only after a call to requestAuthorization(for:) succeeds. It then updates the property until a call to revokeAuthorization(completionHandler:) succeeds or your app exits." This suggests the publisher should emit when the status is changed via Settings, but in our testing it does not — unless a debugger is attached. What We Verified We tested with a development-signed build (which includes the com.apple.developer.family-controls entitlement), launched from Xcode, then disconnected the debugger, killed the app, and relaunched from the home screen. Scenario Publisher emits on revocation? Running from Xcode (debugger attached) Yes, immediately Development-signed build (no debugger) No — silent even on foreground return We also confirmed: MDM configuration profiles can disable Screen Time entirely, but cannot restrict the per-app authorization toggle — the user can always freely revoke the app's Screen Time access The Security Gap This creates a significant gap for parental controls use cases: User leaves the app (app goes to background) User goes to Settings and disables Screen Time access for the app All restrictions are immediately lifted User uses the device freely User re-enables Screen Time access and opens the app Everything syncs back to normal — administrator never knows Questions Is there any supported mechanism to receive a notification (background or foreground) when FamilyControls individual authorization is revoked? We are subscribing to AuthorizationCenter.shared.$authorizationStatus but it does not emit. Is the $authorizationStatus publisher expected to work only when a debugger is attached? Is this a known limitation or a bug? Can DeviceActivityMonitor extension detect authorization revocation? Based on documentation it appears limited to schedule/threshold events, but we haven't confirmed this. Is there a planned API improvement to address this gap? Environment iOS 26.2 Xcode 26.3 Swift 6.2.4 FamilyControls .individual authorization Related Threads Screen time API can be disabled easily Changing Screen Time Passcode does not protect apps

Hi, Is there any possible way we can install enrolment provisioning profile using iOS app using User/Account Authentication Enrolment such as described in this thread: https://developer.apple.com/documentation/devicemanagement/implementing-the-oauth2-authentication-user-enrollment-flow

Hi, Is there any possible Apple approved way or workaround if we can bypass the stolen device protection delay of 1 hour when a user try to install our MDM server's enrolment profile on unknown location? I do not want managed apple account solution. I need solution for BYOD devices not for company owned. Thank you, Software Engineer - iOS

How can I remove device management please

If I have a macOS devices enrolled in MDM, with a DDM policy defined to deliver passcode settings to the device I can run: sudo pwpolicy -getaccountpolicies to see the configuration on the device. I can subsequently run: sudo pwpolicy -clearaccountpolicies Then all passcode policies applied in my declarations are cleared from the device allowing the user to set and use any password they want with no bearing on the delivered passcode settings. I have left my macOS devices for days on and off network and the pwpolicy data never returns. The passcode settings do not restore on the device until I do one of the following: manually re-push all declarations from MDM log off and log back on reboot the computer It was my understanding that DDM was meant to assess device state and self heal on its own without requiring an MDM service to re-push any commands. Based on this finding this seems broken or I may misunderstand how DDM is supposed to work. macOS version: 26.4.1