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

Hi all: We use MDM profile to apply Full Disk Access permission for app on macOS, After profile deployed successfully, The App can get correct Full Disk Access permission, However, on "Privacy & Security" UI, we found that our app shown disabled, see as however, on some macOS, it showed correctly as below The issue happened on different os version. macOS 15 and macOS 26 When the item shown as disable, even reboot computer several times, the issue still persist. Thanks for your help

The new Device Management Service APIs provide support for creating and updating MDM servers programmatically, including updating the public key. However, we could not find a documented API workflow for retrieving, downloading, or renewing the associated Device Management Service token after a public key update. Could you please clarify whether there is an API-supported method for managing the server token ? If such functionality is not currently available, we would like to request support for token management APIs, as this would help enable fully automated MDM onboarding and certificate rotation workflows.

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 bought an iMac 2018 years ago, but it seems that I am having trouble securing it now, which source I have not been able to pin down. I went to turn on FileVault, but saw an unusual procedure flow. I got a message: "Recovery Key A recovery key has been set by your company, school, or institution." I did NOT get this unusual procedure flow with the other macs (MacMini, macbookAir), to which I applied FileVault enable (OK). This iMac has never been under the governance of any company, school, or institution, because I bought it straight out of the Apple Store, right out of the box. But lately, I think that the security of the system has been breached by a hacker. Vitals: Model Name: iMac Model Identifier: iMac18,1 Processor Name: Dual-Core Intel Core i5 Processor Speed: 2.3 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 4 MB Hyper-Threading Technology: Enabled Memory: 16 GB System Firmware Version: 529.140.2.0.0 OS Loader Version: 577.140.2~30 SMC Version (system): 2.39f40 Serial Number (system): D25XJ01NH7VF I went ahead & enabled FileVault with this warning statement, listed below, thinking that I could find a workaround. I have tried "sudo fdesetup removerecovery -institutional", and this works for staff, but not for administrators, either terminal in macOS 13.7.8 (22H730), or in Recovery Mode. Can someone enlighten me about what needs to be done to right my iMac's security issue, and help remove what seems to be a breach in my security with the MDM governance installation, which looks out of place because this iMac has always been at my house & never used with any instutition?

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, I have an app which I would like to test on macOS27, specifically the use of 'Accessibility' permission which is granted via the new DDM payload introduced in macOS27 (com.apple.configuration.app.settings). Problem is once the app is launched once and the consent popup is displayed and a choice is made ('Allow' or 'Not Now') I cannot reset the system so that the popup appears again for test purposes, i.e. is there a command line I can execute similar to 'tccutil reset Accessibility' which would reset the system? Thanks

I entered FB18878081 - July 16, 2025 and FB23195930 - June 16, 2026

Are there any plans to allow wifi-only Apple TV 4K units to be manually enrolled into ASM/ABM like we can do with every other device/OS? I have several that were purchased as gifts but we can not use them as they need to be manually added to ASM. However, it's not yet possible.

In an MSP environment, we manage hundreds of Mac based client organizations. It would be really helpful to have support in the Apple Business API for automating APNS certificate and ADE / Apps & Books token renewal. 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.

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.

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.

Hi Team, Request your help with the below queries. Regarding target-local-date-time status item https://github.com/apple/device-management/blob/release/declarative/status/softwareupdate.pending-version.yaml#L59. The value reported is not the same sent to the device, looks like it is being converted into UTC and sent. Please confirm if this value sent here will be in UTC always, the github link mentions it will be local date time value and does not mention that i will be in UTC. In the softwareupdate.enforcement.specific schema it is clearly mentioned we should not use any timezone. Please find below a sample payload sent to the device and the status report from the device. Device time zone is IST ("Asia/Kolkata") Target local date time is property for iOS is not matching the schema. The property is "softwareupdate.target-local-date-time" instead of "target-local-date-time". Payload: {{"Identifier":"v1|CONFIGURATION|OS_UPDATE|26.5|8ba807e8-6a75-4c50-a379-b7363c4c82fc","ServerToken":"vH|86iQ8CT5QdgErs5ZNQXpUAX4YntAr5kMxkeRNHcXDKg=","Type":"com.apple.configuration.softwareupdate.enforcement.specific","Payload":{"TargetOSVersion":"26.5","TargetLocalDateTime":"2026-06-30T10:00:00"}} Status Report from device: "StatusItems" : { "softwareupdate" : { "install-state" : "downloading", "pending-version" : { "build-version" : "23F77", "os-version" : "26.5", "softwareupdate.target-local-date-time" : "2026-06-30 04:30:00 +0000" } } }, "Errors" : [ ] } For MacOS TimeZone value is not included in DeviceInformation command, even when the request Queries contains <string>TimeZone</string>. Please find below part of the request sent to the device. The device was on OS version 26.0, which is supported as per documentation. <plist Version="1.0"> <dict> <key>CommandUUID</key> <string>4a79dd95-e4bb-450b-96cc-82f61ae4c89e</string> <key>Command</key> <dict> <key>RequestType</key> <string>DeviceInformation</string> <key>Queries</key> <array> <string>DeviceName</string> <string>OSVersion</string> ... <string>TimeZone</string> .. </array> </dict> </dict> </plist>

Requesting com.apple.managed-keychain Entitlement for Enterprise S/MIME Cert Visibility Platform: iOS | Distribution: MDM (Microsoft Intune) | Not App Store We are developing an internal enterprise iOS app (EMS Assist, com.company.supportcompanion) for Company deployed exclusively to Intune-managed devices. Our requirement: Read S/MIME certificates pushed to the device via Intune SCEP profiles to: Confirm cert presence in the MDM-managed keychain Read expiry date (kSecAttrNotValidAfter) to warn users before expiry Distinguish between missing, expired, and valid cert states What we have tried: Standard SecItemCopyMatching query — returns only app-installed certs, not MDM-pushed certs Graph API (deviceConfigurationStates) — confirms profile compliance but does not expose actual cert expiry or keychain presence Our understanding: com.apple.managed-keychain is required for an app to access MDM-managed keychain items on supervised devices, combined with a matching keychain-access-groups entitlement and the cert profile configured as "always available" in MDM. Questions: Is com.apple.managed-keychain the correct entitlement for this use case? Does it apply to SCEP/PKCS-issued certificates specifically, or only other MDM keychain items? Has anyone successfully accessed Intune-pushed S/MIME certs from an iOS app using this entitlement? Any guidance from the community or Apple engineers would be appreciated.

Hello I am looking at taking advantage of managing some features via DDM in an app. I noticed in the ServicesConfigurationFiles link (https://developer.apple.com/documentation/devicemanagement/servicesconfigurationfiles) it says You can create an executable that uses service configuration files by calling the mcf_service_path_for_service_type method in the libmanagedconfigurationfiles.dylib system library. You pass in an identifier for your service type and the method returns the file system path for the directory that contains the corresponding service configuration files. Use those files to override the standard or default configuration the executable would otherwise use. See libmanagedconfigurationfiles.h in the macOS SDK for more detail. I can't find any more references or information on mcf_service_path_for_service_type, libmanagedconfigurationfiles.dylib or libmanagedconfigurationfiles.h anywhere. Is there any information somewhere about this? Or how to use it? Or a POC small example?

I am interested in managing some configuration files for an app using Declarative Device Management (DDM) and noticed a blurb on the ServicesConfigurationFiles developer page that makes it seem like 3rd party apps can take advantage of DDM service files. But I'm not exactly sure how https://developer.apple.com/documentation/devicemanagement/servicesconfigurationfiles You can create an executable that uses service configuration files by calling the mcf_service_path_for_service_type method in the libmanagedconfigurationfiles.dylib system library. You pass in an identifier for your service type and the method returns the file system path for the directory that contains the corresponding service configuration files. Use those files to override the standard or default configuration the executable would otherwise use. See libmanagedconfigurationfiles.h in the macOS SDK for more detail I can't find any more details in the developer documentation on this. How would this be used? Could someone give an example or small POC?

Is system_profiler the recommended approach for retrieving installed application data on macOS? If not, what is the preferred and reliable alternative to fetch a consistent and complete list of installed applications?

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.