Overview: Declarative OS Updates in Addigy (DDM)
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: Scheduled Update Declarations (aka Enforcement Specific) and Updates via Device AI (aka 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 Scheduled Update Declarations by default, and macOS 15+ and iOS/iPadOS 18+ will use Updates via Device AI if optionally enabled in the policy. If overall DDM integration is not enabled at the organization level, MDM will cover all OS types listed in these requirements and up.
Enabling the Integration
To begin using Declarative Updates 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.
These settings will be inherited by any child policies, so be cognizant of where you are configuring Declarative Updates.
If updates have already been configured in a policy, when enabled for the first time, the Declarative Update settings will default to the following options:
Schedule Updates (MDM Only)
This schedule will control when OS updates apply to devices that can only receive MDM OS Updates. Additionally, it will control when to deploy updates for Safari and XProtect on macOS, which will apply to all versions of macOS (even those using Declarative Updates). These updates will install automatically, given that they do not require a reboot. To give OS updates (including non-OS updates) the best chance at running on the device, we suggest setting a schedule during hours that the device will be online. For more information on updates via MDM, please view our article on that here: Overview: System Updates via MDM
MDM OS updates will not apply to Declarative Update eligible devices while the DDM OS Updates integration is enabled.
Note: Updates via MDM will be deprecated by Apple sometime in 2026. If you are only using updates via MDM, it is suggested that you begin transitioning to Declarative Updates as soon as possible.
Version Control
While scheduled and device AI updates function differently, the versions you configure will apply to any update method via the policy.
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 that Addigy can deploy. This does not serve as a device-wide version restriction and it will not block users from updating beyond the defined version. If you would like to restrict users from updating or upgrading to certain 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).
Scheduled Update Declarations (Enforcement Specific)
Scheduled Update 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. If a scheduled update cannot be installed even after the due date, Addigy will reschedule the update for the next allowed time.
Requirements
- Device is Supervised via ADE or MDM Manual Device Enrollment
- macOS 14 and newer
- iOS 17 and newer
- iPadOS 17 and newer
- DDM OS Updates 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 Scheduled Update Declarations.
Force install (x) days after release, at (y)
This setting is your due date for the OS version, which is based on when the particular version was released by Apple.
As an example, let's say I have a maximum version of 15.99.99. Based on the configuration in the above screenshot, the due date for 15.7.3 will be March 12th, 2026 at 12 am device local time, given the update was released on December 12th, 2025.
Enforcement Days:
This setting designates which days of the week declarations can and cannot take place, including past due updates. This example will only allow declarations to happen on a 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 following prompt.
Enforcement Process and Viewing Events
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.
Note: You can filter events in a device's GoLive > Events page by setting the filters like so:
- Filter: Any
- Is: =
- Value: Addigy DDM
or
- Filter: Any
- Is: =
- Value: Addigy Declarative
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.
- If the device was not able to update during the past due timeframe, it will automatically reschedule the update, potentially as past due. The rescheduling depends on your update settings.
Note: If you see the device is constantly getting an update rescheduled every hour, it is likely the update is failing and keeps re-entering the past due phase. If this is the case, please reach out to our support team for assistance with diagnosing further.
General Configuration Recommendation
If you'd like to leverage scheduled OS updates but are not sure what to configure, we recommend configuring it like so:
- A managed update will not be forced outside of Friday-Sunday, meaning end-users will not be disturbed
- The update will be scheduled for the closest Friday on or after your designated OS version has been out for 15+ days
- For example, 26.4.1 was released on Wednesday, April 8th. 15 days after that is Thursday, April 23rd. Since Thursday isn't an allowed day, but Friday is, Addigy will schedule it for Friday, April 24
- Once within 24 hours of the install time (beginning Thursday at 4pm), users will receive this notification every hour. This helps encourage them to install the update themselves before the forced update at 4pm
- If you do not want to force an update at 4pm on a business day, consider pushing the install time up to something later, like 5pm or 6pm
- So long as devices are reachable and have sufficient battery, they should be able to update over the weekend if the update doesn't go on Friday
Important Notes for Scheduled Update Declarations
- 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.
- Devices will directly update/upgrade to the maximum version you have configured. They will not go through different OS versions to reach the enforced max version, including patch (supplemental) updates. For example, a device on 15.2 can upgrade directly to 26.0.1.
- Apple no longer requires a device to update to the minor version that applies to the patch (supplemental) version, if it is not already on the applicable minor version.
- Per Apple, if a patch version is available for a minor version, the device may require an update to the latest applicable patch version, according to what is available on the Apple CDN. For example, if the maximum version is set to 15.7.0, the device may install 15.7.3, given that it is the (current) latest patch version related to that minor version, because the .1 and .2 patch versions are not available in the update catalog.
- Addigy will shift the active 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 and you have a 60-day enforcement period. A device on 15.3 will declare 15.3.1 for 60 days after its release date. If 15.3.2 comes out within the designated 60 days for 15.3.1, Addigy will change the due date to 60 days after the release of 15.3.2.
Updates via Device AI (Global Settings)
Updates via device AI bring about new configurations for macOS 15+ and iOS/iPadOS 18+. When configured to do so, the device will leverage locally run machine learning to determine a suitable time for installation. The device's AI 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 perform the update at that time (which is generally when the device is not in use).
The setting that will enable AI updates is "Configure Automatic Actions". When that is enabled, supported devices will no longer use Scheduled Update Declarations. Other settings can be sent in conjunction with Scheduled Updates Declarations, as noted in this section.
Note: Updates via device AI will not force install at any scheduled time. The machine will determine when it is best to install the update. At the moment, it is not possible to know exactly when the device plans to do the update once it decides.
Requirements
General Requirments
- Device is Supervised via ADE or MDM Manual Device Enrollment
- macOS 15 and newer
- iOS 18 and newer
- iPadOS 18 and newer
- DDM OS Updates Addigy Add-on Enabled
Requirements to Use On-Device AI Updates
To leverage AI-controlled updates, you must configure the following settings:
- "Keep devices updated to the latest OS" version setting selected
- "Configure Automatic Actions" setting configured and set to "Always On"
Power Requirements
Depending on the type of update and how it is initiated, devices must be connected to power or have the following minimum battery charging level to download, prepare, and install a software update with automatic install.
- iPhone
- 30% SOC
- iPad
- 30% SOC
- Mac with Apple Silicon
- 50% SOC
- Intel-based Mac
- 50% SOC
Settings in Addigy
The new update settings from Apple provide a few different options for newer OSs, and some settings you can use with Scheduled Update Declarations.
Set Notification Preferences for updates (source)
Available to use with Scheduled Update Declarations.
Show all notifications -
If selected, users will see all notifications related to updating the device.
Show notifications one hour before -
If selected, devices will only show notifications triggered one hour before the enforcement deadline and the restart countdown notification.
Recommended Cadence (source) iOS/iPadOS only
Specifies how the device shows software upgrades to the user. When multiple OS versions are available, the device behaves as follows:
All -
Shows all software updates and upgrades.
Oldest -
Shows only updates for the oldest (lower numbered) software version allowed by your maximum allowed OS version. For example, if my maximum version is set to 18.3, an iPad on 18.0 will only see 18.3 in Settings > Software Update.
If you leverage the 'keep latest update' setting, it will still show the latest OS version.
Newest -
Shows only a software upgrade to the newest (highest numbered) software version.
Users performing major/minor updates (source) macOS only
Available to use with Scheduled Update Declarations.
Enabled -
Standard users (non-admins) can perform updates and upgrades on the device.
Disabled -
Only administrators can perform updates and upgrades on the device.
Set Deferrals for Software Updates (source)
Major Updates -
Range: 1 - 90 days
Specifies the number of days to defer visibility and autorun of a software upgrade on the device. When set, software upgrades appear only after the specified delay, following the release of the software upgrade.
Minor Updates -
Specifies the number of days to defer a software update only (not a software upgrade or Rapid Security Response) on the device. When set, software updates appear only after the specified delay, following the release of the software update.
Security Updates -
Specifies the number of days to defer non-operating system updates. When set, updates appear only after the specified delay, following the release of the update.
Configure Automatic Actions (source)
Download -
- Allowed: The user can turn on or turn off automatic downloads.
- AlwaysOn: Automatic downloads are always turned on.
- AlwaysOff: Automatic downloads are always turned off.
Install OS Updates -
- Allowed: The user can turn on or turn off automatic installations.
- AlwaysOn: Automatic installations are always turned on.
- AlwaysOff: Automatic installations are always turned off.
Install Security Updates - Note: macOS only
- Allowed: The user can turn on or turn off automatic installations.
- AlwaysOn: Automatic installations are always turned on.
- AlwaysOff: Automatic installations are always turned off.
Manage Background Security Improvement (BSI) (formerly (Rapid Security Response (RSR)) Updates (source)
Available to use with Scheduled Update Declarations.
Enable installation -
If enabled, the system offers Background Security Improvement (BSI) to the user. If the BSI requires a reboot (most do), user interaction will be required or it will try to install when the device is not in use.
If disabled, Background Security Improvement (BSI) aren’t offered for user installation. The system can still install Rapid Security Responses with Scheduled Update Declarations. More on BSIs can be found here.
Enable rollback -
If enabled, the system offers Background Security Improvement (BSI) rollbacks to the user.
If disabled, the system doesn’t offer Background Security Improvement (BSI) rollbacks to the user.
End User Experience
AI-based updates utilize much of the same prompting process that the consumer Apple OS Updates use. The main idea behind machine learning updates is to keep devices updated without user interaction, so users may not encounter as many prompts as they would with Scheduled Update Declarations.
Note: The device will try to fetch the password used to most recently unlock the device. If it cannot fetch this, the user will be prompted to enter their credentials.
macOS:
When the Automatic Actions setting is in use and set to "Always On", the end user will first see a prompt stating that an update is available for installation.
If the user clicks on this notification or navigates into System Settings to view the details of the update, they will see the available version of the update that is cached and booked to install when the device is in an applicable state (e.g. PowerNap). More simply, this green checkmark signifies that machine learning has prepared the update and will try to install it when the device is in a good state to apply it.
On macOS, once the device has figured out a good time to update, users will be warned to close any apps that may block a restart.
If any apps prevent the device from rebooting to apply the update, users will see this warning the next time they log in:
iPadOS:
Similar to the above, when the Automatic Actions setting is in use and set to "Always On" and Addigy sends the settings, the end user will see a prompt stating that an update is available for installation.
If the user clicks on this notification or navigates into Settings to view the details of the update, they will see the available version of the update that is cached and booked to install when the device is in an applicable state. More simply, this green checkmark signifies that machine learning has prepared the update and will try to install it when the device is in a good state to apply it.
Enforcement Process and Events in Addigy
- 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 the applicable version and settings to send to each device assigned to the policy, it will fetch and apply the enforced settings, which can be seen in either Dashboard > Events or GoLive > Events:
- Once the settings have been applied, if configured to do so, machine learning will determine when to install the update and do so when it has figured that out.
Note: You can filter events in a device's GoLive > Events page by setting the filters like so:
- Filter: Any
- Is: =
- Value: Addigy DDM
Important Notes for Updates via Device AI
- AI-controlled updates will only install when the device is not actively being used.
- In the "Pending Update" modal in GoLive, no enforcement date will be posted, given that these do not send traditional due dates.
- You can ensure Addigy is applying the settings by navigating to GoLive > Events for a device and searching for "Any = Addigy DDM", like so:
- Updates controlled via Device AI do not have a due date like scheduled updates. If devices are not updating even after weeks of having these AI settings correctly configured, please reach out to our support team for assistance with troubleshooting.
Important Notes for System Updates
- If Declarative Updates are enabled, supported devices will always opt for that over updates via MDM. More information is in the section below.
- If you have parent and child policy(s) with differing update settings, Addigy will send the most restrictive settings.
- For enforcement dates, let's say you have a 90-day enforcement time configured in the child policy, but 14 days configured in the parent policy, the device will try to update 14 days after the release of the OS version you are sending.
- For what version Addigy will send with conflicting settings, we will send the lowest OS version, and if the device exceeds the lowest version, it will not receive updates from Addigy. For example, if you enforce 15.3.2 in the parent and 15.5 in the child, a 15.4 device will not receive the updates for 15.5.
- Enforcement Declarations can only enforce OS updates and not application updates for things like Safari and XProtect.
- Addigy will automatically deploy app updates via MDM.
- Logs of completed app updates can be viewed on the Events page.
- Alternatively, if using Automatic Actions, setting Always On for Install Security Updates and Downloads will ensure Safari and XProtect are automatically updated via on-device AI.
- On a Mac with Apple silicon, the Mac uses a bootstrap token to authorize the update. If that cannot be done, the Mac will prompt the user for their credentials.
- In GoLive, Addigy will show all pending OS updates, including those not initiated by Addigy. For example, if you see a pending update in GoLive with no method or enforcement date and has a "Prepared" status, it may have been automatically downloaded and prepared by the OS itself.
If you are unsure whether an unwanted update was initiated by Addigy or not, please reach out to our support team for further insight. - Deferrals configured through the "Updates via AI" settings will not apply to Scheduled Update Declarations.
- For example, if you have the Scheduled Update Declarations setting to force install 10 days after release and the AI deferrals are set to 90 days, the scheduled update will go through 10 days after release.
- Per Apple, devices using automatic update installation via machine learning may see the following prompt. This happens if the OS is unable to automatically fetch the current user credentials, which is needed to authorize the update.
- If you are looking to configure beta OS updates, please review this article:
Managing Beta OS Updates via Addigy
Declarative Updates vs. MDM Install and Enforcements
This chart explains the update priority and interactions with MDM updates when DDM updates are enabled in your environment. MDM Updates are responsible for deploying software updates like XProtect and Safari.
| macOS 14+ | macOS 13 & 12 | iOS 17+ | iOS 16, 14, 13, 12, 11, 10, and 9 | iPadOS 17+ | iPadOS 16, 15, 14, and 13 | tvOS 12+ | |
| OS Updates Major & Minor |
DDM (macOS 15+ Global Settings available) |
MDM |
DDM (iOS 18+ Global Settings available) |
MDM |
DDM (iPadOS 18+ Global Settings available) |
MDM | MDM |
| Safari | MDM | MDM | N/A | N/A | N/A | N/A | N/A |
| XProtect Definitions, etc. | MDM | MDM | N/A | N/A | N/A | N/A | N/A |
| Apple Apps | MDM | MDM | MDM | MDM | MDM | MDM | MDM |

