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.

Our organization is attempting to retrieve the External Version Identifier (EVID) history for all published versions. This data is required so that we can pass the exact externalVersionIdentifier integer to our deployment framework to pin specific app versions on our managed devices. We currently have an active App Store Connect account, but our attempts to fetch this data via standard publishing APIs return a 401 Unauthorized error. To help us resolve this technical blocker, please provide explicit engineering guidance on the following four points: API Endpoint Architecture: Is the enterprise Apps and Books for Organizations API (apple.com) the only platform that exposes the externalVersionId history for all versions? If so, what is the exact endpoint path we must call to return the full version-based EVID array? Account Requirements: Can these version-specific EVIDs be retrieved using our existing App Store Connect developer credentials, or is an Apple Business Manager (ABM) account strictly mandatory to bypass the 401 gate? ABM Portal Setup for EVIDs Only: If an ABM account is mandatory, what are the minimum technical steps required inside the ABM dashboard to fetch only the EVID data? Specifically, do we need to "purchase" a volume license for the target app to make its version history accessible via the API? Authentication Parameters: What is the correct token structure for this endpoint? Do we need to pass a specific location server token (sToken / itvt cookie) generated inside ABM alongside our signed developer JWT header? Thank you for your time and technical guidance. We look forward to your engineering team's response.

Buongiorno, In azienda abbiamo molti iPhone gestiti su ABM integrati con Intune, adesso il passaggio su nuovi dispositivi con ripristino dei dati non è possibile avvicinandoli perché la funzione “inizia subito“ non appare. Qualcuno conosce un sistema rapido per la migrazione dei dati da un iPhone a un altro che non sia il Finder? Grazie per l’aiuto

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.

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.

Hi, We have a macOS app that uses NETransparentProxyManager (Transparent App Proxy) with a NETunnelProviderExtension. The Network Extension is configured and deployed via an MDM configuration profile. The profile is pushed through Intune MDM as a user-enrolled device (Company Portal enrollment, not ADE/supervised). The MDM profile sets up the Transparent Proxy extension as follows (sanitized snippet): <key>VPNType</key> <string>TransparentProxy</string> <key>TransparentProxy</key> <dict> <key>ProviderType</key> <string>app-proxy</string> <key>ProviderBundleIdentifier</key> <string>com.example.app.tunnel</string> <key>ProviderDesignatedRequirement</key> <string>identifier "com.example.app.tunnel" and anchor apple generic and certificate leaf[subject.OU] = TEAMID</string> <key>RemoteAddress</key> <string>100.64.0.0</string> </dict> <key>PayloadScope</key> <string>System</string> What we do in code: Call NETransparentProxyManager.loadAllFromPreferences — this correctly returns the MDM-managed profile (1 profile found) We do not call saveToPreferences — the profile already exists We call NEVPNConnection.startVPNTunnel() to connect and NEVPNConnection.stopVPNTunnel() to disconnect Problem: On a user-enrolled MDM device, when the app is running as a standard user (non-admin), every call to startVPNTunnel() or stopVPNTunnel() triggers the macOS VPN consent dialog: "VPN is trying to modify your system settings. Enter your password to allow this." Console log evidence: Failed to authorize 'system.preferences' by client '/System/Library/ExtensionKit/Extensions/VPN.appex' for authorization created by '/System/Library/ExtensionKit/Extensions/VPN.appex' (-60006) (engine 881) Key observations: Even if the user does not provide the admin credentials in the popup and cancel the window, still things work properly in the background i.e start/stop works. This does not happen for admin users on user-enrolled devices saveToPreferences is NOT called — the profile is MDM-managed and already present The prompt is triggered purely by startVPNTunnel() / stopVPNTunnel() from a standard user process Question: Is there a supported API, entitlement, or MDM configuration key that allows NETransparentProxyManager.startVPNTunnel() / stopVPNTunnel() to be invoked by a standard user process on a user-enrolled (non-supervised) device without triggering the system.preferences authorization dialog — given that the VPN profile is already deployed and managed by MDM?

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

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