Overview: System Updates via DDM – Addigy

Addigy currently supports deploying System Updates for your devices via Mobile Device Management (MDM) and Declarative Device Management (DDM) by setting rules in your policy(s). System Updates via DDM bring about two distinct update cadences; Enforcement Specific and Global Settings. In this article, we will detail everything you need to know about System Updates via DDM so that you can effectively and confidently keep your fleet up to date.

For more information on the general concept of DDM, please follow this link.

Note on DDM enablement:
If DDM is enabled (via Account > Account Integrations > Addigy Add-Ons > DDM OS Updates) macOS 14+ and iOS/iPadOS 17+ will use DDM Enforcement Specific by default and DDM Global Settings if optionally enabled in the policy. If DDM is not enabled at the organization level, MDM will cover all OS types listed in these requirements and up.

Overview - Enforcement Specific vs. Global Settings
Enabling the Integration
Where are Updates Controlled?
Schedule Updates (MDM Only)
Version Control
DDM Updates via Enforcement Specific
DDM Updates via Global Settings
General Notes
DDM vs. MDM Install and Enforcements

Overview - Enforcement Specific vs. Global Settings

Before diving in head first, let's briefly overview each flavor of DDM updates. More information on these specific options can be read further down in the article, which you can easily jump to by using the above guide.

Enforcement Specific

Enforcement Specific declarations set a "due date" for the maximum OS version you allow. The due date will vary based on the settings you configure in Addigy.
In a general sense, it's like telling the device "you have to install x version by y date". If a device is unable to install this version by the enforced deadline, it will enter a "past due" phase that will give the user 1 hour to install the update, and if the time expires, the device will force restart to apply the declaration.

Enforcement Specific Declarations require Addigy MDM and macOS 14+ or iOS/iPadOS 17+. More information and requirements are here.

Global Settings

Global Settings bring about new configurations for macOS 15+ and iOS/iPadOS 18+. When set up to do so, Global Settings will leverage locally run machine learning (ML) to determine a suitable time for installation. Apple's ML will identify the best time to apply the update based on when the device is not busy, specifically considering factors such as battery percentage, network usage, free space requirements, and when the device is asleep. Once it has determined a good time to apply the update, it will do so at that time (which is generally when the device is not being used).

Enabling the Integration

To begin using DDM in your environment, you must enable the DDM OS Updates integration from within your Addigy portal's Account > Integration page. Enabling the integration will not automatically enable updates within your policies, this must be manually configured.

Where are Updates Controlled?

To begin configuring updates, you can go ahead and navigate to any policy and select the Updates tab on the left-hand menu. By default, everything in the policy will be disabled and no updates will be sent to devices.

Schedule Updates (MDM Only)

This schedule applies to devices that receive only MDM OS Updates on tvOS and older macOS, iOS, and iPadOS devices that do not support declarations. Safari and XProtect macOS updates will install automatically, regardless of this schedule. For more information on updates via MDM, please view our article on that here: Overview: System Updates via MDM

Version Control

While the two DDM update workflows function in unique ways, the versions you configure will apply to both.
At the very top of each context menu for each OS type, you will see two settings that relate to version control.

Maximum version allowed

This setting lets you define the maximum version you allow Addigy to deploy. This does not serve as a device-wide version restriction and thus does not serve as a measure to prevent devices from going beyond the defined version. If you would like to restrict device versions, please reference this article.

In the example below, setting the maximum version number to 15.99.99 allows for devices in this policy to get all of the minor and patch versions of macOS Sequoia (15) while not deploying a future version of macOS past 15. This field follows the major.minor.patch versioning standard. These same rules apply to iOS, iPadOS, and tvOS.

Keep devices updated to the latest OS

If selected, Addigy will automatically send the latest OS version to all applicable devices. This includes major versions (upgrades).

DDM Updates via Enforcement Specific

For an overview of Enforcement Specific updates, click here.

Requirements

Device is Supervised via ADE or MDM Manual Device Enrollment
macOS 14 and newer
iOS 17 and newer
iPadOS 17 and newer
DDM Addigy Add-on Enabled

Settings in Addigy

Within the Updates page in a Policy, you will find the following settings, which are only applicable to Enforcement Specific declarations.

Force install (x) days after release, at (y)

This setting is your due date for the OS version, which is based on the number of days the update has been available for download.
As an example, let's say I have a maximum version of 15.3.1. Based on the configuration in the above screenshot, the due date will be May 11th, 2025 at 3 PM device local time since 15.3.1 came out on February 10th, 2025.

Enforcement Days:

This setting designates which days of the week declarations can and cannot take place, including past due updates. The below example will only allow declarations to happen on Monday.

Avoid updates from (x) to (y)

This setting allows you to set a static range of dates to avoid applying a declaration, including past due updates. For example, if I enforce 15.3.1 to install 1 day after release, the below configuration will not allow that update to install from February 19th to February 26th.

Include a support article link with each update

This setting will add your custom link to System Settings (macOS)/Settings (iOS/iPadOS) > Software Update.

macOS:

iOS/iPadOS:

End User Experience

Standard Declaration Prompt (macOS)

Users will see the following prompt when the declaration is successfully sent to the device. Additionally, this prompt will show every hour when the device is within 24 hours of the enforced due date.

Past Due (macOS)

When an update is past the enforced due date, it will enter the "past due" phase, which gives the user 1 hour to install it manually or it will force reboot at the end of the hour.

Standard Declaration Prompt With Passcode Set (iOS/iPadOS)

If no passcode is configured on the device, it will automatically restart with no prompt once the update is downloaded and prepared.

Past Due (iOS/iPadOS)

For the first prompt pictured below, users can select "Emergency" to hide the prompt and temporarily skip the update. If they select Emergency, the same past due prompt will reappear a few minutes later.

If the 1 hour time limit expires, users will see the below prompt.

Enforcement Process

This section outlines the communication workflow that happens between Addigy, Apple servers, and the device itself.

Sending the Declaration

The device completes certain MDM audits and reports to Addigy what updates it has available.
Addigy will look at the device's available updates and compare them to the settings enforced in the update policy.
Once Addigy has determined what update/upgrade to send to each device assigned to the policy, it will fetch and apply the declaration:
Once the declaration time approaches, if it has not already, the device will download the update from Apple and subsequently apply it to the device.

Past Due Interaction

The device misses the due date for the update
When the device is available and communicating with Apple servers, it will schedule the update to install within 1 hour.
- Users can prematurely install the update to avoid a forceful restart.
Once the 1 hour passes, the device will automatically restart to apply the update.
- Any open apps that require additional interaction to be closed will halt the restart, which can cause an unexpected restart if the user is away, comes back, and interacts with the prompt to close the app.

Notes for Enforcement Specific Updates

Below are general things to note as far as Enforcement Specific behavior.

If a device is within the past due period and that process gets interrupted before it finishes (for example, the device turns off), the past due phase will restart with 1 hour when the device is available again.
The device will enter the past due phase the moment the declaration day has passed. For example, a declaration enforced to install on February 19th at 6 PM will be considered past due on February 20th at 12:00 AM (00:00).
If the device does not support the maximum version enforced in the policy, it will go to the next applicable version. For example, when using the "keep latest version" setting, Addigy will only send applicable Sonoma (14) versions to a macOS 14 device that does not support macOS 15+.
For iOS/iPadOS, if a passcode has been configured, users will be prompted to enter their passcode to authorize the update.
- If no passcode is configured on the device, it will automatically restart with no prompt once the update is downloaded and prepared. This may cause unexpected/unwanted downtime.
Per Apple, a device can only install a supplemental update (such as 14.2.1) if the device is already on the relevant minor version (such as 14.2).
- If a device is trying to install a supplemental version from a different minor version (for example, 14.1 to 14.2.1), the following process will occur:
  1. It will install the minor version first (14.2)
  2. The device will reboot to apply this update
  3. Then it will install the supplemental version (14.2.1)
  4. Finally, the device will reboot again to apply the supplemental update
- For a device not on the minor version for an applicable supplemental version, Addigy will declare both versions with the same due date.
Addigy will shift the declaration due date if a new, applicable OS version comes out.
- For example, let's say you have 15.99.99 as the max version in the policy but you have a 60-day deferral period. A device on 15.3 will declare 15.3.1 for 60 days after its release date. When 15.3.2 comes out, Addigy will change the declaration due date to 60 days after the release of 15.3.2.