How to handle OS updates for iOS 15 (legacy MDM) vs iOS 16+ (DDM) now that legacy docs are removed?

Question

Created 3w

Replies 1

Boosts 0

Participants 2

Hi everyone,

We are currently developing an on-premises enterprise MDM (Mobile Device Management) server. We are implementing the Software Update feature and need to support a wide range of devices, ranging from legacy versions (iOS 15 and below) to modern versions (iOS 16, 17, and later).

As we know, iOS 16+ supports Declarative Device Management (DDM) for software updates (using configurations like com.apple.configuration.softwareupdate.enforcement.specific), which is now the recommended best practice.

However, we still have enterprise clients running iOS 15 and below, which do not support DDM. These legacy devices require traditional MDM command payloads (such as ScheduleOSUpdate, OSUpdateStatus, and AvailableOSUpdates).

We noticed that Apple has recently deprecated and removed the documentation for these legacy commands (e.g., the "Schedule an OS Update" endpoint documentation has been deleted from the Apple Developer Documentation portal).

We would appreciate advice on the following:

Is a "Dual-Pathway" approach still the recommended architecture for modern MDM servers to handle this transition (i.e., detecting OS version, sending traditional ScheduleOSUpdate plist commands for iOS 15 and below, and sending DDM Declarative configurations for iOS 16+)?
Since the official documentation for legacy ScheduleOSUpdate and related commands has been deleted, where can we officially find the archived technical specifications and plist schemas for these commands to ensure proper backward-compatible implementation?

Thank you so much in advance for your guidance!

Answer 1

Device Management Engineer OP

Apple

3w

Documentation

The public documentation repo has the documentation of the software update policy payload, as well as the scan, available and schedule commands.

These links are to the release branch. If you switch to the seed_OS_27_0 branch you can see that we're not removing the documentation, even though the commands are removed. We're just adding a removed: '27.0' marker, such as here. So you can expect that the documentation for the removed commands will remain available here.

Backwards Compatibility

The ideal solution to backwards compatibility is to update all eligible devices to the latest OSes which support all the device management features you need, and which have all the latest features, bug fixes and security fixes. Of course we don't live in an ideal world, so unfortunately that leaves device management services to deal with backwards compatibility. Yes, the best practice is to use your dual pathway approach.

I would also recommend setting up analytics to see how many devices in your population are still using the old method. At some point the number of legacy devices will be so small that it will be easier/cheaper to retire or replace them than to continue supporting the old pathway.

And you can expect this pattern to repeat. We're always introducing new management features, and some of those will create a new batch of "legacy" devices which won't or can't support the new OS or new feature.

Bob Whiteman - Device management engineer