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

Hello, We are working with an iOS app that is distributed as a Public Unlisted App Store app. Our MDM allows us to import the app by URL, but when added this way, the app is marked as unmanaged in the inventory. Because of that, we cannot assign a Managed App Configuration payload to it in the normal way. What we are trying to achieve: Deliver a configuration profile to all enrolled devices before the app is installed. When the user installs the app from the MDM catalog, the app should immediately see the configuration values. Questions we’re hoping to clarify: Is it technically feasible to pre-provision a Managed App Configuration for an app in this scenario, by pushing a .mobileconfig profile to all devices? If yes, what would be the correct payload format and content of such a .mobileconfig file? We’ve tested a profile format we found here that uses com.apple.managed-app-config PayloadType and a ManagedAppConfiguration key with the bundle ID nested inside, but iOS reports this as “payload not recognized.” From what we understand, that may not be part of Apple’s schema. Any guidance from Apple or the community on whether this use case is possible (and, if so, what the valid profile format should look like) would be very helpful. Note: For a complicated company policy, at the moment we are not able to participate in ABM. Thanks in advance!

Hi Apple Community, At WWDC25, introduced a native device migration feature with iOS/macOS 26 and Apple Business Manager that promises seamless migration from one MDM to another without wiping devices or manual re-enrollment. That said, while testing this in iOS/macOS 26 beta, we ran into an issue: the Wi-Fi settings deployed by the old MDM aren’t retained during the migration. This means devices lose Wi-Fi connectivity partway through, and users have to manually reconnect before the migration to the new MDM can continue. This interrupts what should be a smooth, hands-off process. We wanted to ask if this is a known issue or limitation with the current beta? Are there any recommended ways to avoid losing Wi-Fi profiles during this migration window? Will this improve in future updates so that the Wi-Fi connection is preserved or seamlessly handed off to the new MDM? Any tips, workarounds, or official guidance Apple can share on best practices for handling Wi-Fi profiles during ABM-native device migrations would be hugely appreciated. Added Feedback with FeedBackAssistant ID : FB20150763 Thanks in advance.

Hi Apple Development forums, I am having trouble getting a Wireguard VPN config setup to automatically disconnect on all domain requests other than one specific domain. I have my .mobileconfig designed as so: <dict> <key>Action</key> <string>EvaluateConnection</string> <key>ActionParameters</key> <array> <dict> <key>Domains</key> <array> <string>service.domainname.com</string> </array> <key>DomainAction</key> <string>ConnectIfNeeded</string> <key>ProbeURL</key> <string>https://service.domainname.com/</string> </dict> </array> </dict> <dict> <key>Action</key> <string>Disconnect</string> <key>DNSDomainMatch</key> <array> <string>*.com</string> <string>*.org</string> <string>*.net</string> </array> </dict> <dict> <key>Action</key> <string>Disconnect</string> </dict> </array> The issue I'm having is regardless of whether I note a *.com or simply have the action Disconnect noted - the VPN stays connected after navigating to https://service.domainname.com. would anyone have any thoughts on this? Or am I missing something here?

Hello All, I am currently developing a mobile management system using declarative management and for the most part it is pretty great. There is one consistent issue I have run into and it comes when testing VPP app installs with not enough licenses. When my server detects that it can't provide a license ID it will return a 404, which causes the rest of the DM syncing to stop, and the activation to throw an error. Per the documentation for using simple activation: An array of strings that specify the identifiers of configurations to install. A failure to install one of the configurations doesn’t prevent other configurations from installing The above would imply that if a config fails it should not affect anything else (aside from possibly reporting an error. Am I returning the wrong error code for it to continue or is the behavior correct and the documentation is wrong? Any additional info would be useful

We’re running into a problem when deploying certain .pkg installers via MDM on macOS 15 and above. The installation fails with the following error message: “The app is running and we don’t have the context to quit it, failing install.” Context: The .pkg is being pushed through an MDM solution (not installed manually). This happens consistently across multiple macOS 15+ devices. The target app is often already running when the MDM tries to install the update. Unlike a manual installation, the MDM does not appear to have the ability to quit the running app before proceeding. Questions: Is this a known change in macOS 15 where MDM-delivered installs no longer have permission to terminate apps during package installation? Are there recommended best practices for handling app updates via .pkg through MDM in this scenario? Has anyone implemented a workaround—such as pre-install scripts, user notifications, or policies to quit the app before running the installer—that works reliably on macOS 15? Is Apple planning to update MDM behavior or installer APIs to address this, or should admins expect to handle quitting apps entirely outside of the MDM installation process? Any insights from Apple engineers or other developers/admins who have encountered this would be really helpful.

We’ve run into what looks like a gap in how forceAirDropUnmanaged is enforced on iOS devices. Setup: Device: iOS 17.x (unsupervised, enrolled in MDM) MDM Restriction: forceAirDropUnmanaged = true Managed Open-In restriction also applied (block unmanaged destinations). Verified: from a managed app, the AirDrop icon is hidden in the share sheet. This part works as expected. Issue: When two iOS devices are brought close together, the proximity-initiated AirDrop / NameDrop flow still allows transfer of photos, videos, or files between devices. In this path, forceAirDropUnmanaged does not appear to apply, even though the same restriction works correctly in the standard sharing pane. What I’d expect: If forceAirDropUnmanaged is enabled, all AirDrop transfer paths (including proximity/NameDrop) should be treated as unmanaged, and thus blocked when “Managed Open-In to unmanaged destinations” is restricted. What I observe instead: Share sheet → AirDrop hidden ✅ Proximity/NameDrop → transfer still possible ❌ Questions for Apple / Community: Is this a known limitation or expected behavior? Is there a different restriction key (or combination) that also covers proximity-based AirDrop? If not currently supported, should this be filed as Feedback (FB) to request alignment between share sheet AirDrop and NameDrop enforcement? This behaviour introduces a compliance gap for organisations relying on MDM to control data exfiltration on unsupervised or user-enrolled devices. Any clarification or guidance would be greatly appreciated.

We are experiencing a critical issue where VPP app installations are consistently taking an excessive amount of time, leading to significant delays in asset association. We are deployionThis is a systemic problem that affects all VPP apps, not just an isolated case. Apps: 39470db7-e475-4269-9709-c80641657027 => com.zimride.instant d0876900-2579-463e-99f1-b7c85ef5c5e8 com.microsoft.azureauthenticator Troubleshooting: We have performed extensive troubleshooting and can confirm the following: VPP Token: The VPP token has been successfully renewed and is currently active and valid. License Availability: We've verified that there are sufficient VPP licenses available for the apps being deployed. Device Status: We've attempted the following on the affected devices: Restarted the devices. Switched to different Wi-Fi networks. Uninstalled and re-installed the apps. App Status: The issue is not limited to a single app; all VPP apps are failing to install. License Revocation: We attempted to revoke and reassign licenses for some devices, but this did not resolve the issue. The app was not pushed, and the pending status remained. Troubleshooting: Through our internal investigation, we have determined that the core issue is that the Asset Association Status is consistently taking excessive time. This seems to be preventing the app installation queue from processing. We have observed a significant delay in the processing of events within the Notification Channel. The time between the event being created and a response being received is excessively long, indicating a potential backlog or issue. We have included a few recent examples below for your reference: Event ID: 39470db7-e475-4269-9709-c80641657027 com.zimride.instant Created Time: 2025-08-26 01:02:04 Response Time: 2025-08-26 01:34:05 Event ID: d0876900-2579-463e-99f1-b7c85ef5c5e8 com.microsoft.azureauthenticator Created Time: 2025-08-25 21:16:29 Response Time: 2025-08-25 22:21:07 We would appreciate your help in the following areas: Resolution: Could you provide any known solutions or workarounds for an asset association status that is taking excessive amount of time'? Best Practices: Are there any recommended best practices or additional parameters we should be checking with the MDM that might influence the queueing of VPP app assignments? Queueing Parameters: Could you provide insight into the parameters or conditions that can affect the queueing and processing of VPP app installations on Apple's servers? Please let us know if there is any additional information or logs we can provide.

We have 2 iPhones (16 pro - iOS 18.2, 16 regular - iOS 18.5 ) in single app mode and sometimes we need to shut them down manually. After holding Power and VolumeUp, shutdown screen appears as usual, but the slider isn't responding to touch, as well as the whole screen. After force restart using volume buttons, this issue disappears, but reappears after next phone restart. If we disable single app mode -the issue is gone and touch screen works every time on shutdown screen. Both iPhones share the same behavior. Is there any other way to reliably shut down the iPhone locally without using MDM or a way to fix this issue?

We have an application which is written in Swift, which activates Transparent Proxy network extension. Our Transparent Proxy module is a system extension, which is exposing an app proxy provider interface (We are using NETransparentProxyProvider class and in extension’s Info.plist we use com.apple.networkextension.app-proxy key.) We are using JAMF MDM profile for installing our transparent proxy in customer environment. We are using VPN payload(https://developer.apple.com/documentation/devicemanagement/vpn) for this network system extension. This payload does not have any field for order. As per https://developer.apple.com/documentation/devicemanagement/vpn/transparentproxy-data.dictionary documentation there is another payload for TransparentProxy and we could create a Transparent Proxy profile using iMazingProfile Editor. Noticed that, if we add the Order attribute to the VPN/TransparentProxy payload, while installing the extension, the save to preferences fails with "Error in saving TP configuration in updateOnDemandRule permission denied" error. Can we use this Order field to ordering the installed Transparent Proxy extension in a machine? Customer devices will likely have other Transparent Proxy network extensions as well. We want to allow the Customer to control the order in which each Transparent Proxy network extension receives the network traffic. How can we set the order of the Transparent proxy extension that can be deployed using MDM profile with VPN/TransparentProxy payload? Attached the TransparentProxy payload profile for the reference. DGWebProxy_TransparentProxy_iMazing

When I try to sign in Managed Apple ID in supervised device there appears a prompt stating that "Apple ID" is a work account.This account must be signed in as a work account on this device.When I click continue it takes to VPN and device management tab where MDM profile already exists. Note:The managed Apple ID has a ICloud subscription for it. When I remove the subscription for the Apple ID and try to sign in, it works. Kindly help on this or advise on any additional steps required to enable sign in for managed Apple ID in this scenario

Hi everyone, I’m working on a concept for an iOS app that would allow a user to remotely control an Enterprise iOS device, similar to how AnyDesk or TeamViewer work on desktop. I understand that apps like TeamViewer for iOS offer screen sharing, and some level control but not a full level control. Before I invest further in development, I’d like to clarify a few points: Is there any official Apple-supported way (public or private API) to allow remote control of an iOS device? Has Apple ever approved apps that allow true remote control of iOS (not just screen sharing)? If full control is not allowed, what are the permitted alternatives (e.g. screen broadcast via ReplayKit, remote assistance mode, etc.)? Would such an app be considered for enterprise distribution only (via MDM), or is there a potential App Store path? Any insight or experience from developers who’ve tried this would be very appreciated. Thanks!

Hello, We are currently deploying Apple devices in our organization using Apple Business Manager (ABM) and are looking for a long-term self-hosted MDM solution. We initially considered MicroMDM, but since official support will end in December 2025, we are evaluating NanoMDM. I would like to confirm: Is NanoMDM a stable and production-ready option for long-term use with Apple Business Manager and Automated Device Enrollment (ADE)? Does NanoMDM support all essential features like: Supervision Remote wipe App deployment Configuration profiles Are there any limitations or known issues with using NanoMDM? Are there any other open-source or lightweight MDM solutions Apple developers recommend that are actively maintained? We are aiming for a reliable, secure, and future-proof self-hosted MDM setup. Any guidance or shared experience would be greatly appreciated. Thanks, Vijay Pratap Singh

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

For context, my company develops a data loss prevention (DLP) product. Part of our functionality is the ability to detect sensitive data being pasted into a web browser or cloud-based app. The AppKit release notes for April 2025 document an upcoming “macOS pasteboard privacy” feature, which will presumably ship in macOS 26. Using the user default setting “EnablePasteboardPrivacyDeveloperPreview” documented in the release notes, I tested our agent under macOS 15.5, and encountered a modal alert reading " is trying to access the pasteboard" almost immediately, when the program reads the General pasteboard to scan its contents. Since our product is aimed at enterprise customers (and not individual Mac users), I believed Apple would implement a privacy control setting for this new feature. This would allow our customers to push a configuration profile via MDM, with the “Paste from Other Apps” setting for our application preset to “Allow”, so that they can install our product on their endpoints without manual intervention. Unfortunately, as of macOS 26 beta 4 (25A5316i), there does not seem to be any such setting documented under Device Management — for example in PrivacyPreferencesPolicyControl.Services, which lists a number of similar settings. Without such a setting available, a valuable function of our product will be effectively crippled when macOS 26 is released. Is there such a setting (that I've overlooked)? If not, allow me to urge Apple to find the resources to implement one, so that our customers can preset “Paste from Other Apps” to “Allow” for our application.

The result Plist for the InstalledApplicationList MDM command is reporting duplicate Application identifiers. Sometimes with different version, other times with the same version. The device is MacOS 15.5, Enrolled via ABM (Supervised). Here are a couple samples from the returned list. Duplicate app: <key>BundleSize</key> <integer>398051</integer> <key>Identifier</key> <string>com.adobe.Acrobat.NativeMessagingHost</string> <key>Installing</key> <false/> <key>Name</key> <string>NativeMessagingHost</string> <key>ShortVersion</key> <string>5.0</string> <key>Version</key> <string>5.0</string> </dict> <dict> <key>BundleSize</key> <integer>398051</integer> <key>Identifier</key> <string>com.adobe.Acrobat.NativeMessagingHost</string> <key>Installing</key> <false/> <key>Name</key> <string>NativeMessagingHost</string> <key>ShortVersion</key> <string>5.0</string> <key>Version</key> <string>5.0</string> </dict> Different Version: <key>BundleSize</key> <integer>4197200</integer> <key>Identifier</key> <string>com.adobe.adobe_licutil</string> <key>Installing</key> <false/> <key>Name</key> <string>adobe_licutil</string> <key>ShortVersion</key> <string>11.0.0.39</string> <key>Version</key> <string>11.0.0.39</string> </dict> <dict> <key>BundleSize</key> <integer>4443177</integer> <key>Identifier</key> <string>com.adobe.AcroLicApp</string> <key>Installing</key> <false/> <key>Name</key> <string>AcroLicApp</string> <key>ShortVersion</key> <string>25.001.20432</string> <key>Version</key> <string>25.001.20432</string> </dict> <dict> <key>BundleSize</key> <integer>7380980</integer> <key>Identifier</key> <string>com.adobe.adobe_licutil</string> <key>Installing</key> <false/> <key>Name</key> <string>adobe_licutil</string> <key>ShortVersion</key> <string>10.0.0.274</string> <key>Version</key> <string>10.0.0.274</string> </dict>

Hi Apple team and community, We’re currently integrating with the Apps and Books for Organizations API as part of our device management solution and would like to highlight a few critical points we've encountered — including a reliability issue, an enhancement suggestion, and a request for clarification on API rate limits. 1. Issue: Intermittent 403 Errors with stoken-authenticated-apps Endpoint We are encountering intermittent 403 Forbidden responses from the stoken-authenticated-apps endpoint. Approximately 30–35% of the requests fail with a 403 status code. These failures are inconsistent — the same request (using the same Content Token and Storefront) may succeed upon retry. All requests are properly authenticated and include the required Cookie and other headers as specified in the API documentation. This issue is impacting our ability to reliably fetch app metadata at scale, particularly in workflows. We’d like to know: Is this a known issue? Could it be due to a rate limit or token misconfiguration? Are any changes required on our end to avoid these failures? 2. Enhancement Request: Include externalVersionId in versionHistory Response The versionHistory extension currently returns: versionString releaseNotes releaseDate However, for Declarative Device Management (DDM) workflows such as App Pinning, we need the externalVersionId as well. Without it, we can't reliably correlate version metadata with the specific version ID required for pinning. Adding externalVersionId would: Enable precise version targeting during App Pinning Improve reliability and automation in managed deployments We request that Apple consider including externalVersionId in the versionHistory response to better support DDM-based app lifecycle management. 3. Rate Limit Clarification We found the following note in the Apps and Books for Organizations API documentation: "The Apps and Books for Organizations API limits the number of requests your app can make using a developer token within a specific period of time. If you exceed this limit, you’ll temporarily receive 429 Too Many Requests error responses for requests that use the token. This error resolves itself shortly after the request rate has reduced." While this confirms that a rate limit is enforced, there is no detailed information about the thresholds — such as the number of allowed requests per minute, hour, or day per developer token. To help us implement proper throttling and retry strategies, we request clarification on the following: What is the exact rate limit threshold per developer token? Are there per-endpoint limits, or is it a global cap for all requests using the token? Does the API return a Retry-After header when the limit is exceeded? What is the recommended backoff strategy for clients to follow when receiving 429 errors? This information would help us implement efficient throttling and error handling logic. Any insights from the Apple team or other developers who’ve encountered these issues would be greatly appreciated!

I'm currently testing app updates using the App:Managed declarative device management payload, and I have a question regarding app update status reporting. Presently, by subscribing to the app.managed.list status item, we can retrieve a list of managed applications along with their installation status. Additionally, we enable automatic updates for managed App Store apps using the UpdateBehavior.AutomaticAppUpdates key. However, especially when a critical application update is initiated, we frequently find ourselves needing more detailed information about the update process. For instance, having status items similar to softwareupdate.install-state and softwareupdate.failure-reason would be incredibly helpful for user troubleshooting. My question is: Is there a way to obtain a similar level of detailed, real-time status updates for app updates? Any insights you might have, or existing methods to achieve this, would be greatly appreciated. Thank you.

Hello, I am running into a bit of an issue with the Screen Timeout/Screen Lock setting and would like some clarification on. First for a bit of context, I am enrolling personal iOS devices 18.0+ into the company MDM (Intune) with Account Driven User Enrollment. We are trying to set a screen timeout of 5 minutes and immediately after it asks for the passcode on the device, though this setting is not being applied and the device timeout setting can be set as "Never" on the user's end. This is a big security risk for the company I work for and and the issue with being HIPAA compliant. According to the Microsoft Intune Support, "In iOS 18, when using Account-Driven User Enrollment for BYOD (Bring Your Own Device) scenarios, the screen lock timeout setting is indeed marked as “Not Applicable”. This is because Apple’s privacy-preserving model for personal devices restricts administrative control over system-level settings like screen lock or idle timeout." I am needing clarification on the item mentioned from Microsoft Intune Support and if this setting is no longer able to be applied from the MDM with devices enrolled with Account Driven User Enrollment?

I have come across this Hideable attribute for managed apps, introduced in iOS 18.1, and I've encountered some behavior that seems to contradict the official documentation. According to Apple's documentation for app.managed.yaml, setting the Hideable key to false under the Attributes section should prevent a user from hiding the app. The documentation explicitly states: If false, the system prevents the user from hiding the app. It doesn't affect the user's ability to leave it in the App Library, while removing it from the Home Screen. I have configured this in my app.managed.yaml and successfully applied the profile to my test device via our MDM server. However, I am still able to hide the application from both the Home Screen and the App Library. Here are the steps I'm taking to hide the app: Long-press the app icon on Home Screen Select "Require Touch ID" Select "Hide and Require Touch ID" Authenticate using Touch ID Select "Hide App" After these steps, the app is no longer visible on the Home Screen or in the App Library, which is contrary to the behavior described in the documentation for when Hideable is set to false. My question is: Is this a known issue or a potential bug in iOS 18.1? Or, is there an additional configuration profile or a specific device supervision requirement that I might be missing to enforce this restriction correctly? Any clarification would be greatly appreciated! Thank you!

Hello, I'm currently working on implementing app installation features, referencing the app.managed.yaml declaration on GitHub: https://github.com/apple/device-management/blob/0a4527c5ea21825fd23e08273ccdb9e2302458ce/declarative/declarations/configurations/app.managed.yaml My question pertains to the InstallBehavior.Version key. The current specification indicates its type as <integer>: key: Version title: Version supportedOS: iOS: introduced: '26.0' macOS: introduced: '26.0' visionOS: introduced: '26.0' type: <integer> Is there a way to specify the app version using a string format, such as x.y.z, instead of the integer (App Store External Version Identifier - EVID)? Allowing for a simpler version specification would make app version management through MDM more flexible and efficient. I believe this would significantly streamline the deployment and operation of Apple devices within organizations. Any guidance or consideration for this would be greatly appreciated. Thank you.