Dear Apple developer community,i am trying to successfully use the device to device migration feature which was introduced in iOS 12.4I am a developer for a mobile client management solution and we have the problem that we cannot use this feature when DEP devices are involed. As long as we use devices which are not included in the DEP program, we can directly migrate our data from one device to another.It doesn't matter if the source and target devices are supervised or not. (both devices iOS 13.1)We do not use the DEP profile setting "DeviceToDeviceMigration" to skip this setup step.We do not use the configuration profile restriction "allowProximitySetupToNewDevice" (default true)So in theory, there should be no problem using this feature.When i leave the DEP program with the target device, I can again use the feature.Is there anything we are missing or is this a bug in iOS 13.1?Greetings,Mike
Post
Replies
Boosts
Views
Activity
Hi there,
since iOS 14 Beta 8 (also tested with today's release of iOS 14 GM) the device doesn't send the "HasUpdateAvailable" property of an installed app anymore when querying the installed apps of the device with an MDM solution.
See property documentation:
https://developer.apple.com/documentation/devicemanagement/installedapplicationlistresponse/installedapplicationlistitem
(even listed as a required property)
Command documentation:
https://developer.apple.com/documentation/devicemanagement/list_the_installed_apps
My MDM solution needs this property to determine if app updates are available for apps deployed with the VPP mechanism.
Is this a bug or intended behavior?
Greetings,
Mike
Hello everyone,
I was trying out Declarative Device Management on my iOS 16 device to get a feeling of how it works. While trying out the new protocol i managed to find some bugs in the behavior of Declarative Device Management.
When subscribing to the "passcode.is-compliant" state the device initially sends the state "passcode.is-compliant==false" but will never (even after hours) send "passcode.is-compliant== true", even when the device is definately complying to a complex passcode policy and even when no passcode policy is present. This state also didn't work as a predicate for an activation in the form of "(@state(passcode.is-compliant) == TRUE)". The referenced configuration was never activated even after the device definately complied with the installed passcode policy.
When subscribing to the "passcode.is-present" state the device will initially send the correct state but then never update the state even when clearing the passcode and re entering it again multiple times and even after waiting for 10 minutes.
When using an activation with predicate "(@state(passcode.is-present) == TRUE)" the device will correctly install the referenced configuration but after removing the passcode it will not remove the configuration even though it should
After reenrolling the device and reactivating Declarative Device Management the device reported the state "passcode.is-present==true" even though the device didn't have a passcode present.
Can anyone else confirm this behavior?
Thanks and have a nice day