Installing and enforcing software updates for Apple devices
Using declarative device management, organizations can configure different aspects of the software update process. This includes managing software update availability, enforcing software updates, enrolling devices into beta programs, and more.
Requiring a minimum version during enrollment
Starting in iOS 17, iPadOS 17, and macOS 14, MDM solutions can enforce a minimum operating system version during Automated Device Enrollment. If the device doesn’t meet the minimum version expected by the mobile device management (MDM) solution, the user is guided through an update before they can complete Setup Assistant. The same process happens automatically when used with Auto Advance. This helps ensure that devices owned by an organization are on the necessary operating system version before being put into production.
Managing the availability of software updates
Organizations may want to control which versions their users can update their devices to. For example, this control can be used to perform verification of an update with a test group before allowing all users to install it in production, or deploy different deferrals to different groups to phase the rollout of recent updates.
Time-based deferrals
Supervised devices can be prevented from offering OTA software updates to users until a specified period of time has passed since they were made publicly available by Apple. For example, say that an iPhone fleet is using iOS 17.3, and a deferred software update configuration of 30 days is applied. In this scenario, users have iOS 17.4 offered to them on their managed devices 30 days after the iOS 17.4 release date.
As part of the configuration, organizations can specify a custom deferral period from 1 to 90 days. In iOS and iPadOS, this delay applies to both operating system updates and upgrades. In macOS, they can also specify different deferral periods for operating system updates, upgrades, and non-operating system updates. Non-operating system updates include updates for Safari, printer drivers, and Xcode command-line tools. For example, a custom deferral can be used on macOS to defer a software upgrade for longer than a software update.
Note: OTA software updates are typically available for up to 180 days after their initial release date to ensure that an update is always available for managed devices with the maximum deferral value.
A configuration profile can be created for each of the restriction payload settings listed here.
Minimum supported operating systems | Key and value (if any) | Description | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
iOS 11.3 or later iPadOS 11.3 or later macOS 10.13.4 or later tvOS 12.2 or later |
| Default is false. If set to true:
Note: This doesn’t apply to macOS seed builds. | |||||||||
macOS 11.3 or later |
| Default is false. If set to true, user visibility of software upgrades is delayed for 30 days, unless another delay value is specified with | |||||||||
macOS 11.3 or later |
| Default is false. If set to true, user visibility of app updates are delayed for 30 days, unless another delay value is specified with | |||||||||
iOS 11.3 or later iPadOS 11.3 or later macOS 10.13.4 or later tvOS 12.2 or later |
1-90 | Allows the MDM administrator to set how many days a software update is delayed. Required when using When a value is set, user visibility of a software update occurs only after the specified delay (according to when that software was released in the Apple Software Lookup Service). This value controls the delay for
Note: Before macOS 11.3, this value controlled the delay for both | |||||||||
macOS 11.3 or later |
1-90 | Allows the MDM administrator to set how many days a software upgrade is delayed. The maximum is 90 days and the default value is 30 days. When a value is set, user visibility of a software upgrade occurs only after the specified delay (according to when that software was released in the Apple Software Lookup Service). This value controls the delay for | |||||||||
macOS 11.3 or later |
1-90 | Allows the MDM administrator to set how many days a software update is delayed. The maximum is 90 days and the default value is 30 days. When a value is set, user visibility of a software update occurs only after the specified delay (according to when that software was released in the Apple Software Lookup Service). This value controls the delay for | |||||||||
macOS 11.3 or later |
1-90 | Allows the MDM administrator to set how many days an app update is delayed. The maximum is 90 days and the default value is 30 days. When a value is set, user visibility of an app update occurs only after the specified delay (according to when that software was released). This value controls the delay for | |||||||||
Recommended cadence on iOS and iPadOS
In addition to defining time-based deferrals, organizations can define whether users on supervised iPhone and iPad devices have the option to upgrade to a newer, major version or continue on the current one and still receive minor updates, even after an upgrade is available.
For example, on an iPhone using iOS 16.6.1, one of three options can be used:
Offer users only additional updates to iOS 16.
Offer users only the upgrade to iOS 17.
Allow users the choice: additional updates to iOS 16 (for example, iOS 16.7) or upgrade to iOS 17.
The first option is available for only a limited period of time and allows users to benefit from any important security updates while testing is completed to approve the major upgrade for a production environment.
In conjunction with deferrals, a recommended cadence can be used. In the example above, it could be used to keep devices on iOS 16 while deferring software updates only (like iOS 16.7) for the defined period of time.
Requiring authorization by an administrator on macOS
Organizations can change the default behavior to require authorization by a local administrator to install a software update. For example, this can be used in deployments where a device is shared with multiple users to restrict who can perform an update.
Enforcing software updates
Organizations can enforce specific software updates at a chosen time regardless of configured deferrals or if the automatic installation of Rapid Security Responses is turned off. This helps ensure managed devices run a specified version by a certain date and time while allowing users to install the update at a time convenient for them (prior to the enforcement date).
The enforcement date and time are relative to the local time zone of the device. This allows the same configuration to be applied across different regions. For example, if the enforcement date is set to 6 p.m., devices attempt to perform the update at 6 p.m. on the specified date in their local time zone.
When a software update is declared, users are informed about its deadline:
In Settings (iOS and iPadOS) and in System Settings (macOS)
In a notification
Depending on the time left until the enforcement deadline, the notification provides different options (as described below). To allow for increased transparency to users and to keep them informed about the process, additional information about the update can be provided using the “More information” link.
If the user doesn’t immediately begin the installation, the notifications and options shown depend on the remaining time get more frequent leading up to the enforcement date and are meant to encourage the user to install the update at a time convenient for them. To help ensure these notifications are displayed to the user, the Do Not Disturb feature is ignored during the 24 hours prior to the enforcement.
To initiate and authorize the update from a notification or from Settings and System Settings, the system prompts the user for their passcode or password.
In case the user hasn’t installed the update before the local enforcement date:
iOS and iPadOS force the user to enter their passcode if one is set (unless it was entered earlier)
macOS force quits all open apps (regardless of whether any documents are open and unsaved) and performs a restart if necessary
On a Mac with Apple silicon, the Mac uses a bootstrap token (if one is available) to authorize the update or the Mac prompts the user for their credentials
To enforce the installation of an update, upgrade, or Rapid Security Response, a device must meet the same requirements as for a user-initiated update of the same type.
A key benefit of declarative device management is the autonomy of devices. Instead of triggering individual actions, the MDM solution declares the desired state and delegates the task to achieve that state to the device itself. A specific example of this behavior is a situation where the software update enforcement date was missed because the device didn’t meet the requirements. The device automatically detects that the declared state hasn’t yet been achieved and resumes the process when it’s connected to the internet.
To do so—if necessary—the operating system downloads and prepares the update and posts another notification letting the user know the install is past due and an attempt will be made to perform the installation within the next hour. In case the process gets interrupted again for any reason, the process repeats the next time the device is powered on and connected to the internet.
Using status reports available with declarative device management, MDM solutions can also get increased transparency about the status of the installation—for example, waiting for, downloading and preparing, or installing the update. Meaningful error codes have been added in case the release couldn’t be applied or was unable to be successfully completed. Some examples of this are if the device was offline, if the battery charge was too low, or if not enough free space was available.
Updating iPadOS on Shared iPad
Software updates on Shared iPad devices can be initiated over the air using the MDM solution that the Shared iPad is enrolled in. If the device is physically connected, the Finder or Apple Configurator on a Mac can also be used.
To install an update on Shared iPad, users must be signed out but can be left cached on the device. If the installation requires more free space than what is currently available, cached user account data must be removed. Due to the autonomy of declarative device management, a device keeps retrying to install a new release until it’s successful.
To minimize downtime, updates to a Shared iPad should be scheduled to occur during off hours to minimize impact to users and the network.
For more information, see Updates and upgrades to iPadOS for Shared iPad.
Allow the user to temporarily defer macOS software updates and upgrades
For greater control, in macOS 12.3 or later, you can enforce a particular software update or upgrade while allowing users to defer them a specific number of times. An MDM solution that supports this feature can specify the number of times using the InstallLater install action, where this number is defined by the MaxUserDeferrals key.
The install notification is shown approximately once every 24 hours. A deferral occurs when the user closes the Notification window. The user has the following options for the update or upgrade after they click the notification:
Install Now: Downloads the update or upgrade and installs it immediately.
Try Tonight: Downloads and installs later.
If the user selects this option, based on machine learning from the data over the last 21 days, the Mac finds the best time to download and install the update or upgrade—roughly between 2:00 a.m. and 4:00 a.m. (It may not always be during this time).
If the user still has deferrals remaining and if they don’t see the notification or they ignore it, the update isn’t installed that evening. The final notification for installation bypasses Do Not Disturb. Also, the number of possible deferrals can be updated by an MDM administrator by issuing a new command. When doing so, the deferral counter on the Mac is reset.