Is there any mechanism to restrict camera usage on a user-owned device, once they have opted in, consented to the restriction, and installed a management profile? Documentation suggests it was possible with allowCamera, but has be deprecated on unsupervised devices. Am I understanding correctly that it's simply not possible anymore unless the device is supervised?

This test setup is Jamf Pro as the MDM with Entra as the IdP. PSSO is working on Sequoia devices. Prior to Tahoe, PSSO required the following three items: An existing local account, the delivery of Company Portal, and a profile containing PSSO payload. Based on the Tahoe announcement, it looks like PSSO is now available during Setup Assistant, removing the requirement of first creating a local account. I assume this means that the requirements now as easy as deploying Company Portal and the PSSO profile during the Pre-Stage policy. I attempted this on the macOS 26 beta 1 and during Setup Assistant, with the PSSO profile delivered, Setup Assistant prompts me to login to my IdP. However, pressing Continue will result in a failure, notifying me that the application required is not available. The continue button is now inactive but a "try again" button is available. This results in the loop of trying and then failing, stating that the required application is not available. I eventually must quit Setup Assistant which exits it and drops me at the login window. The only account that is visible is the management account. A trip into DFU and an IPSW restore then follows. Am I trying this too soon? Is PSSO at Setup Assistant not yet fully supported? Is there another requirement other than delivering Company App in the prestige alongside the profile? I've enabled the beta channel in MAU but there is no newer Company Portal being offered. Any guidance here would be appreciated as this is the PSSO announcement I've been waiting for since the deprecation of Apple Enterprise Connect.

m personal iPhone is managed by an Unauthorized and Unknown mdm management team, The profile isn’t showing up in VPN Settings and I can’t remove them from having Remote access and control over my Personal Device! I’ve SPENT MANY MONTHS TRYING TO GET SUPPORT VIA EMAILING APPLE DEVELOPER AND SPEAKING TO APPLE SUPPORT WHICH HAS BEEN EXTREMELY EXHAUSTING AND HUMILIATIN! I’ve resorted to contacting Internet crime websit, the federal trade commissio, Better business bureau and Consumer Affairs to file an online complaint against Apple for not complying with their Security and Privacy policy for consumers accounts! Because of this unauthorized and unknown mdm device management profile I don’t have COMPLETE CONTROL OVER MY OWN IPHONE! ! Unable to find a team with the given Team II 'L95TAW5KWP' to which you belong. Pleas Developer Program Support. https://developer.apple.com/support I contacted developer support via email and also tried calling but they don’t respond!

I'm currently implementing a managed app using the new AppConfig specification. I referred to Apple's official documentation: Specifying and decoding a configuration. Based on the example provided in the "Publish your configuration specification" section, I structured my application configuration plist like this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>configuration</key> <dict> <key>account</key> <dict> <key>username</key> <string>test user</string> <key>password</key> <string>test 123</string> </dict> <key>domain</key> <string>test example.com</string> </dict> </dict> </plist> When I deployed this configuration via my MDM server, the server reported valid for the activation, configuration and asset (which is the plist), but the configuration did not reflect or apply within my app. My app was unable to retrieve these settings. After some troubleshooting, I found that removing the top-level <key>configuration</key> wrapper resolved the issue. The following plist structure successfully pushed the configuration to my app: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>account</key> <dict> <key>username</key> <string>test user</string> <key>password</key> <string>test 123</string> </dict> <key>domain</key> <string>test example.com</string> </dict> </plist> My question is: Is the inclusion of the <key>configuration</key> wrapper (as shown in the Apple documentation example) incorrect for the current AppConfig implementation? Or is this structure intended for a future release (e.g., iOS 26 or beyond) and the documentation implicitly refers to it, causing confusion for current implementation? 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.

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

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

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, I am trying to enable declarative management on my device ( it is already enrolled as a sharedIpad with DEP). When sendind the command, the device's response contains an error. It is not acknowledged. Either on the device channel or on the user channel. The device channel returns : 'ErrorChain': [{'ErrorCode': 4, 'ErrorDomain': 'RMErrorDomain', 'LocalizedDescription': 'Feature Disabled: Device Channel.'}], 'Status': 'Error', and the user channel returns : 'ErrorChain': [{'ErrorCode': 12021, 'ErrorDomain': 'MDMErrorDomain', 'LocalizedDescription': '“DeclarativeManagement” is not a valid request type.', 'USEnglishDescription': '“DeclarativeManagement” is not a valid request type.'}], 'Status': 'Error', Does DEP device support declarative management? Thanks.

Is there a way to check in code if a device is under Mobile Device Management? We want to show the users a different screen in the app if it is under device management. This is primarily for devices under Apple School Manager or something similar

out of 37 devices, 7 are inactive( al are ios ). We have checked one of the devices and the broadcast message was sent successful. Additionally, Cx confirmed that the location history is shown properly. We restarted the device, checked the date and time, and found it to be correct. We also switched to a different network, but that doesn't change anything. The sync from the Hexnode app was successful. We reinstalled the MDM profile, yet it doesn't change anything. We renewed the APNs once and checked, but the scan device action remains pending.

中文： 大家好，我通过https://mdmenrollment.apple.com/session获取到了auth_session_token，并能正常使用device/activationlock、devices、profile/devices这些接口，但是不能正常使用devices/disown（https://mdmenrollment.apple.com/devices/disown）这个接口，接口返回401 UNAUTHORIZED，请问应该怎么处理？ English： Hi, I have passed https://mdmenrollment.apple.com/session Obtained auth_dession_token and can use interfaces such as device/activationlock, devices, and profile/devices normally, but cannot use devices/disown normally（ https://mdmenrollment.apple.com/devices/disown ）How should I handle this interface, which returns 401 UNAUTORIZE?

Hi, I have a question regarding reading the configuration of a managed app deployed via an MDM system. The application has an Action Extension and can receive shared files via this extension. The problem I am facing is that I can read the managed configuration in the host app by accessing the UserDefaults.standard.object(forKey: "com.apple.configuration.managed") dictionary. With this, I can configure the host app. However, I am unable to read this configuration key in the Action Extension part of the application. My question is whether there is any possibility to read the managed configuration even in the extension. So far, I have been unable to figure out how to read it. I found the sample code, but it was not very helpful since it is very basic and does not deal with extensions at all. Any hints are appreciated.

When the user pushed the lock device action on a macOS 14, it returned an acknowledgement but the device wasn't locked. Which resulted in loss of data on the device.

There could be a case where-in multiple transparent proxies might exist in the system (for ex., Cisco AnyConnect, GlobalProtect, etc). We want to know if there is a way to order transparent proxies so that the desired transparent proxy gets the request first. During our research, we found a resource which talks about ordering transparent proxies through MDM. https://developer.apple.com/documentation/devicemanagement/vpn/transparentproxy Using this reference, we tried to create a profile and push it through JAMF. Below is the profile that we created and pushed with JAMF. Property List - &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;TransparentProxy&lt;/key&gt; &lt;array&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.paloaltonetworks.GlobalProtect.client.extension&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;1&lt;/string&gt; &lt;/dict&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.cisco.anyconnect.macos.acsockext&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;2&lt;/string&gt; &lt;/dict&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.mydomain.transparentproxy&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;3&lt;/string&gt; &lt;/dict&gt; &lt;/array&gt; We are not sure if this is the right way to create the profile, though JAMF is not throwing any error while pushing this profile. We see this profile on the local machine as "/Library/Managed Preferences/com.apple.networking.vpn-transparent-list.plist". Is there a way to know if the profile took effect and the order of transparent proxies has changed. Thanks in advance.

I'm reaching out to discuss a significant issue related to how iOS handles app login sessions, particularly in the context of MDM (Mobile Device Management) and the Outlook app. In our organization, we use MDM to distribute applications, including Outlook, with certificate-based authentication for BYOD (Bring Your Own Device) devices. This setup allows users to log in seamlessly to their accounts. However, we've encountered a concerning behavior: when a user unenrolls from MDM, which automatically removes the distributed apps and certificates, they can later reinstall the app from the App Store and find themselves automatically logged back into their previous accounts without any authentication prompts. Here’s a detailed breakdown of the situation: Initial Installation: Users enroll their devices in MDM, which installs the necessary apps and certificates on those devices. Session Storage: After the initial login, the app stores the session locally on the device. App Deletion: When users un enroll their devices from MDM, it automatically removes the distributed apps and certificates. Reinstallation: Days or weeks later, when they reinstall the Outlook app from the App Store, they find themselves automatically logged back into their accounts. This behavior raises important concerns: Lack of Authentication: The app retaining user sessions even after deletion allows users to access their accounts without re-authentication, which could lead to potential unauthorized access and undermines the effectiveness of certificate-based authentication and two-factor authentication (2FA). Note: This issue is not limited to Outlook; we've observed similar behavior with many other apps. Need for a Solution - Given the implications of this behavior, we are looking for effective solutions to prevent it. Specifically, we need options within the MDM framework to: Restrict Session Retention: Implement settings that ensure any app deleted via MDM will lose all stored sessions and require re-authentication upon reinstallation. Default Settings for MDM-Distributed Apps: Ideally, this would be a default feature for all apps distributed through MDM, ensuring that user sessions are not retained after app deletion. Has anyone else experienced this issue? Are there any existing settings or workarounds within MDM platforms to mitigate this problem? Your insights and experiences would be invaluable as we navigate this challenge. Thank you!

I’m looking for advice on implementing an Active Supervision Mode for enhanced parental control. My goal is to restrict access to both iOS system apps and third-party applications to create a safer and more tailored digital experience for my child. Here’s what I’d like to achieve: App Restrictions: Block specific apps (both iOS and third-party) and allow access only to approved ones. Time Limits: Set daily usage limits for individual apps or app categories. Content Filtering: Apply restrictions to block inappropriate content and age-inappropriate apps. Remote Management: Manage these settings remotely from my device for added convenience. Activity Monitoring: View app usage stats or receive alerts for policy violations. I understand that Screen Time on iOS offers basic parental controls, but I’m exploring whether iOS supports more advanced capabilities natively or through additional configurations. I’ve also heard that enrolling a device in Apple Business Manager (ABM) and linking it to an MDM (Mobile Device Management) solution might provide greater control. If this is a viable solution, could anyone provide guidance on: Enrolling a personal or family-owned device into Apple Business Manager. Linking an MDM for configuring app restrictions and monitoring usage. Alternatively, if there are third-party parental control apps that work seamlessly with iOS to achieve these goals, I’d appreciate your recommendations! Thanks in advance for your insights!

We provide a MDM product. In our product, payloads and properties which require supervision display those requirements. Two properties forcePreserveESIMOnErase and allowWebDistributionAppInstallation of the restriction payload don’t require a supervised device according to the descriptions in Apple Developer Documentation. However, in our observation, those properties seem to require it. Are those OS bugs or documentation errors? (In which category should I submit a feedback?) Steps to reproduce Prepare a supervised device (I used an iPhone 12 mini with iOS 18.1) and a configuration profile contains the following restrictions: <!-- Does not require a supervised device --> <key>allowDiagnosticSubmission</key> <false/> <!-- Requires a supervised device --> <key>allowESIMModification</key> <false/> <!-- Does not require a supervised device according to its description --> <key>allowWebDistributionAppInstallation</key> <false/> <!-- Does not require a supervised device according to its description --> <key>forcePreserveESIMOnErase</key> <true/> Then, Install the profile with Apple Configurator. Confirm 4 restrictions are shown in Settings > General > VPN & Device Management > PayloadDisplayName > Restrictions. Punch Settings > General > Transfer or Reset iPhone > Erase All Content and Settings, to unsupervise. Install the profile with Apple Configurator. It cannot be installed automatically because the device was not supervised. Manually install the downloaded profile. Check Settings > General > VPN & Device Management > PayloadDisplayName > Restrictions. Expected results 3 restrictions—allowDiagnosticSubmission, allowWebDistributionAppInstallation and forcePreserveESIMOnErase—are shown. Actual results Only one restriction—allowDiagnosticSubmission—is shown. Appendix: Restriction keys and their restricted message shown in Settings allowESIMModification: eSIM modification not allowed forcePreserveESIMOnErase: Preserve eSIM on erase enforced allowWebDistributionAppInstallation: Web app distribution not allowed allowDiagnosticSubmission: Diagnostic submission not allowed

Would it be possible to prevent deletion of specific apps on iOS devices using MDM.

We have a development where we are MDM managing iOS devices and attempting to enforce mutual TLS for all interactions with the MDM. We are DEP provisionng an enrolment profile that utilises an ACME hardware attested Device Identity Certificate. All interactions with the MDM endpoints are correctly utilising the ACME certificate for the client mutual TLS handshake. The certificate has Client Authentication Extended Key Usage. Behind the same API gateway and on the same SNI we are also serving paths to Enterprise application manifests and IPAs. We can see from the phone log and from packet traces the iOS device doesn't offer the Device Identity Certificate for client authentication when retrieving these URLs. We have also tried adding non ACME client certificates from the root trusted by the server to the initial profile with exactly the same outcome. If we temporarily disable the mutualTLS we can see that the request for the manifest has a userAgent of "com.apple.appstored/1.0 iOS/18.2 model/iPhone17,3 hwp/t8140 build/22C5125e (6; dt:329) AMS/1" which is not the same as the mdm interactions. Is it actually possible to achieve mutualTLS to authenticate these downloads or is a different solution required ? Any advice greatly appreciated.