Getting Started with DDM OS Updates in Addigy

In this DDM Updates session, Addigy Solutions Architect Mauricio walks through how Declarative Device Management (DDM) has become the primary way to manage Apple software updates — and what’s changing now that legacy MDM update commands are being deprecated. This is essential viewing for IT admins and MSPs managing Apple fleets who need to move from MDM-based update workflows to DDM.

Key Takeaways
  • DDM (Declarative Device Management) is the mechanism Apple is standardizing for software update management going forward, replacing the older MDM command-based approach.
  • Starting with macOS 26, most legacy MDM software update commands begin to deprecate. Admins should plan for the software update device settings profile to eventually stop functioning, even though it still works today.
  • The core difference is timing: MDM updates are synchronous (the device and server must be in sync at the moment of the update), while DDM is asynchronous (a set of instructions is delivered to the device, and the user can apply it now or let it run at a scheduled time).
  • When you configure update settings and save them in Addigy, DDM creates a property list (a .plist) on the device containing the instructions the machine then follows.
  • The forced-install deadline counts from when the update was released, not from when you configured the setting — so high values like 90 days can keep getting pushed back each time Apple ships a newer release.
  • Admins can extract DDM details into custom facts (whether the plist exists, the target install date, and the target OS version) to make update status visible across device tables, Flex Policies, and alerts.
Requirements and How DDM Differs From MDM

What you need to use DDM for updates

DDM update delivery via property list began in macOS 14 Sonoma and applies through macOS 15 and macOS 26. For mobile devices, iOS or iPadOS 17 is required. The device does not need to be supervised, and on macOS a standard user can perform the update unless an admin restricts it. Both manual enrollments and Apple Business Manager enrollments support DDM. In practice, fleets running recent operating systems on Apple silicon are generally ready for DDM enforcement, while older operating systems will not have it available.

Synchronous (MDM) vs. asynchronous (DDM)

With MDM, the update worked like a delivery that required someone to be home at the moment it arrived — the device and server had to align at update time, and a user who wasn’t at their machine would often miss the prompt, causing friction. DDM instead leaves a “package” of instructions on the device. The user can open it now when convenient, or it executes automatically on the scheduled date. This asynchronous model is the central advantage of DDM over MDM.

Things to plan for with macOS DDM updates

At the deadline, macOS may force-close applications and restart to apply the update, so scheduling outside working hours is the recommended practice to avoid disrupting users. Devices need internet connectivity, sufficient battery (or to be plugged in), and available storage. Users receive a notification that looks similar to a native macOS notification but is labeled as a managed update and shows the scheduled date and time.

Configuring DDM Updates in Addigy

Maximum version allowed

This setting caps what Addigy will deploy — for example, setting it to 15.0 means Addigy will not push anything past 15.0. It does not hard-stop a user, who could still upgrade locally to a newer OS on their own. To prevent users from moving to the next OS, use blocker software.

Blocker software

Found under prebuilt apps, blocker software runs a utility that prevents an upgrade to a specified operating system from completing. The update files may land on the device, but the upgrade itself is blocked — useful when you need to hold machines on a specific OS version.

Setting the declaration and deadline

The forced-install timing is based on when the update was released, not when you configured the setting. Because of this, many admins keep the deadline value low (roughly 1–10 days) rather than at the 90-day maximum, since a high value gets pushed back each time Apple releases a newer version. You then set a weekly enforcement schedule (enforcement only happens on the days you select), and you can exclude specific dates such as holidays. A support article link can also be attached to the update.

Granular and background options

Additional settings let you increase the number of user notifications, restrict updates to admins only, and manage background security improvement settings. Enabling certain automatic-action settings changes how the resulting plist is configured. The moment you save, the property list is created on the device.

iOS works the same way

iOS follows the same workflow — set instructions, a schedule, dates to avoid, and notification preferences — though the underlying delivery differs from the macOS plist. iOS does not require supervision.

Verifying DDM With the Property List and Custom Facts

Where the plist lives

The DDM property list is a system-level plist created the moment you save your update settings. It is located at /var/db/softwareupdate/ (the software update persistence plist). If a savvy user deletes it, it regenerates on the next reboot. Two keys inside it matter most for update tracking: the target local date/time and the target OS version.

Inspect before you change

Use the native defaults read utility to observe the plist contents before making any changes — identify first, then act. Keys set to 0 or 1 represent false/true (whether a setting was enabled).

Three custom facts to build

The first custom fact checks whether the plist exists (return type: Boolean — shown as a green dot, or as the word “true” if you prefer a string). The second reads the target local date/time so anyone on the team can see exactly when a “90-day” deadline actually lands — for example, August 10, 2026 at midnight (return type: string). The third reads the target OS version, such as 26.5 (return type: string). Selecting the wrong return type is the most common mistake and produces a custom fact error.

How does Apple's Declarative Device Management (DDM) handle software updates?

DDM delivers a package of update instructions to a device as a property list. Rather than requiring the device and management server to be in sync at the moment of the update, DDM is asynchronous: the user can apply the update immediately or let it run automatically at a scheduled date and time. When an admin configures and saves update settings in Addigy, the corresponding .plist is created on the device, which then follows those instructions.

When do Apple's legacy MDM software update commands get deprecated?

Deprecation begins with macOS 26, the current operating system. It is not a full deprecation yet — the software update device settings profile still functions today — but admins should begin preparing for it to stop working in the future and plan to move update management to DDM.

What is the minimum macOS version required for DDM updates?

DDM update delivery via property list begins with macOS 14 Sonoma. While some DDM capabilities existed earlier, the property-list-based update mechanism starts at macOS 14 and applies through macOS 15 and macOS 26. Older operating systems such as macOS 12 and 13 still rely on the legacy MDM update method.

What is the difference between MDM and DDM updates?

MDM updates are synchronous — the device and server must align at update time, so a user away from their machine could miss the update. DDM updates are asynchronous — instructions are delivered to the device, and the user can apply them now or wait for the scheduled enforcement. The asynchronous model is the key advantage of DDM, giving users flexibility while still guaranteeing a deadline.

Why does my DDM update deadline keep getting pushed back?

The forced-install deadline counts from when Apple released the update, not from when you configured the setting. If you set the maximum 90-day value and Apple ships a newer release before the deadline, the clock resets to 90 days from that newer release. To keep deadlines predictable, many admins use a low value such as 1–10 days. Building a custom fact for the target local date/time lets the whole team see exactly when an update will actually land.

How do I keep Apple devices on a specific OS version and stop users from upgrading?

Setting the maximum version allowed in Addigy caps what the platform will deploy, but it does not stop a determined user from upgrading locally. To actually hold devices on a specific OS, deploy blocker software from prebuilt apps. The blocker runs a utility that prevents the upgrade from completing, so the device stays on the intended version until you’re ready to move it forward.