Per-account-VPN follows the same concept as Per-App-VPN : you deploy an app-layer-vpn profile (which looks very similar to a VPN payload), and you use VPNUUID key to refer to it (in the profile payload for the service, in the Attributes section of the application - see https://developer.apple.com/documentation/devicemanagement/installapplicationcommand/command/attributes?changes=latest_minor&language=objc - for Apps).

It should not matter. https://developer.apple.com/documentation/devicemanagement/installapplicationcommand/command?changes=latest_minor&language=objc InstallApplication command can contain Configuration which is the configuration plist - and this should work for both IPA or via iTunesID (ASM/ABM). In addition, the Setting command allows to update the configuration once the app has been installed: https://developer.apple.com/documentation/devicemanagement/settingscommand/command/settings/applicationconfiguration?changes=latest_minor&language=objc And this is based on bundle id - so unrelated to how the app has been installed.

Not sure what you're exactly looking for, but basically: your app needs to implement code to react to app config being sent. Look at https://developer.apple.com/documentation/foundation/nsuserdefaultsdidchangenotification and NSUserDefaults class documentation. In a nutshell there is a function called when the config is sent by the MDM with a dictionary with all key/values. you need to provide to your customers a plist containing the dictionary. your customers need to use their MDM to send the configuration to the apps. At this point, it really depends on the MDM implementation. Disclaimer : I'm working for one MDM vendor ; with our solution, you can easily import the plist and attach it to the application you want to deploy to devices and we offer some flexibility (you can deploy different plists on different devices based on rules or customize the plist on the fly). But the MDM protocol is quite simple : the config can be sent to the device at installation time or afterwards, and once the config is sent the app receives the callback, the rest really depends on the implementation of the MDM tool.

Understood - but my point is that AvailableOSUpdates command did not require supervision in the past - iOS 12.5.3 unsupervised devices do accept the request, while it's not the case with recent iOS versions like 14.5.1. So the supervision requirement changed over time - and I was just curious to know: if this was expected or if it is a bug. In 2016, the MDM protocol PDF documented: Only Supervised DEP-enrolled iOS devices and DEP-managed Macintosh computers are eligible for software update management. However, the AvailableOSUpdates query is available to non-DEP managed devices. So in 2016 supervision was not required. if this is not a bug, when (Which version) did that change. Our MDM solution still support older devices which can't upgrade to iOS 14.5 and we would like to make sure we send the right command to the right version of iOS. Thanks !

Thanks for the reply. I'd have 2 additional questions: which error should be replied by the server ? WWDC sessions says "The MDM will send a JSON 403 response when the device requests the enrollment profile", but JSON is the format of the content, while 403 is at HTTP layer. Should it just be 403 with empty content ? comparing versions is quite straightforward, but is there any guidance / documentation related to supplemental versions ? For instance, my test iPad would return: <key>OS_VERSION</key> <string>17.0</string> <key>PRODUCT</key> <string>iPad12,1</string> <key>SUPPLEMENTAL_BUILD_VERSION</key> <string>21A5248v</string> <key>VERSION</key> <string>21A5248v</string> Obviously, testing if the version is the one we expect is simple, but I guess that most of the time organizations are asking for a minimum version requirement, which means that we need to test if device VERSION / SUPPLEMENTAL_BUILD_VERSION is more recent than the organization requires. I assume the build number could be parsed...

Thanks for the confirmation. I guess it's the same for DNSProxy (DNSProxyUUID) ?

Has anyone indeed more details ? We tried the following: Build a jwt token, using: headers as headers = { 'typ': 'JWT', 'alg': 'RS256' } and claim as : claim = { 'iss': DEP_SERVER_UUID, 'iat': epoch_time_in_ms, 'jti': RANDOM_UUID, 'service_type': 'com.apple.maid' } The token is signed with the private key which was used to generate the public key added to the DEP server in Apple Business Manager. Using python 3, we're using PyJWT package : https://pyjwt.readthedocs.io/en/latest/api.html This generates jwt token - which seems ok according to https://jwt.io ; token is encoded in utf-8 and then returned in plist as: <?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>TokenData</key> <data> BASE64_ENCODED_VERSION_OF_THE_TOKEN </data> </dict> </plist> So everything is ok, but I can't log in with a managed Apple ID from the same Business Manager if I enforce "Supervised devices". Device is sending the GetToken checkin request, receives the response, but does not let user log in. is there anything missing ? It looks we fulfill documentation requirements, so can't figure out what's wrong. Thanks for any hint !

Hello. Any update on this one ? As user enrollment is supposed to be deprecated with iOS 18, giving a try to User Account Driven Enrollment, and hitting the same - despite Location is properly set when returning authentication end point, the 2nd enrollment phase does not contain the access token in Authorization. Is there anything special to do ?

This just has been published in github doc: https://github.com/apple/device-management/compare/release...seed_iOS-18-1_macOS-15-1 there are app based settings or general restrictions.