In every operating system numbered 27, Apple removed legacy software update management. Not deprecated. Removed. The MDM commands, the queries and the restrictions your platform has used to push iOS and macOS updates for a decade stop working on iOS 27, iPadOS 27 and macOS 27. Declarative Device Management is now the only way to enforce an update on a current Apple device.
That single change turns DDM from an architecture debate into a deadline. This guide covers what declarative management is, what it actually does for the admin and for the person holding the device, and what changed at WWDC 2026.
The short version
- Classic MDM is imperative: the server sends commands and polls for status. DDM is declarative: the server sends the intended state, the device enforces it and reports changes on its own.
- Legacy software update management no longer functions on any 27.0 OS. Declarative software update is the only path.
- Declarations win. When a declaration and an old MDM command manage the same setting, the declaration takes precedence.
- The device does the work. Policies keep enforcing offline, apply in seconds, and repair themselves without a resync.
- Users get warned, not ambushed. Notifications can start 14 days out, deferrals run from 1 to 90 days, and the forced 60 second countdown is gone.
- It is additive, and your MDM should hide the seam. Declarative where the device supports it, imperative where it does not, from one policy you configure once.
What declarative device management actually is
Classic MDM is a conversation. The server sends a command, the device acknowledges, and the server polls to confirm the state actually took. Every setting is its own exchange. Multiply that by a few thousand devices and your MDM spends its day chasing status instead of managing anything.
DDM inverts it. The server sends declarations: statements about the state a device should be in. The device stores them, applies them itself, keeps enforcing them whether or not it can reach the server, and reports back only when something changes.
The difference is the one between a manager who calls every hour to ask if a task is done and a manager who hands over the goal and trusts you to raise a hand when something blocks. Apple introduced the model at WWDC 2021 with iOS 15. It has been widening the coverage every year since, and with the 27 releases it started closing the old door behind it.
The building blocks
A declaration is not one monolithic object. Apple splits it into types that reference each other, which is what makes the model composable instead of just faster.
| Type | What it holds | Why it matters |
|---|---|---|
| Configurations | The actual settings: a passcode policy, a VPN, a software update rule, an app to install | This is the payload. One configuration, reusable across many activations |
| Activations | The logic. A set of configurations plus an optional predicate that decides when they apply | Conditional policy moves to the device. No more rebuilding smart groups server side |
| Assets | Reusable data configurations point to: credentials, identity certificates, hosted profiles | Define once, reference everywhere. Rotating a certificate stops being a fleet-wide push |
Under all of it runs the status channel. The device subscribes to the values it manages and pushes a report the instant one of them changes. The server learns about drift as it happens rather than at the next scheduled check-in.
An activation predicate is the part most teams underestimate. Because predicates evaluate on the device against status reports and custom management properties, you can ship a policy to a device before the condition is true and let it switch itself on later. A configuration that applies only once a Mac reaches a given OS version, or only when a device reports itself supervised, needs no server logic at all.
Imperative versus declarative, side by side
Say you deploy ten managed apps to a device.
| Imperative MDM | Declarative | |
|---|---|---|
| What the server sends | Ten install commands | One declaration listing the ten apps |
| Confirmation | An acknowledgement per command, then polling | The device reports state as it changes |
| A user deletes app number seven | It stays gone until someone triggers a resync | The device reinstalls it on its own |
| An app update is released | A new command, queued per device | The device updates it, no server action |
| Device asleep or offline | Commands wait in the queue | The declaration applies and holds locally |
| Drift detection | Next check-in, possibly hours | Immediate push from the device |
| Your dashboard | A sea of pending | Current state |
One clarification, because it is a common misreading: a declaration is still delivered to each device individually. The saving is not one message for the whole fleet. It is that a single declaration replaces a stream of commands and a polling loop, per device, for the entire life of that policy.
What changes for the IT admin
Updates that actually land
Imperative macOS updates were famously unreliable. Commands that stalled silently, devices that ignored the deadline, users who deferred forever, and a compliance report you did not fully believe. Declarative software update hands the Mac a target version and an enforcement date, and the Mac drives the update itself. It downloads in the background, schedules around the user, and reports its progress through the status channel.
The practical difference shows up in the reporting. You stop asking "did the command go through" and start reading a state the device is asserting about itself.
Compliance you can prove in the present tense
Polling has a built-in lie. Between two check-ins you have no idea what a device is doing. Somebody disables a setting, drops off the network, falls out of policy, and you find out at the next poll, which might be four hours out.
The status channel closes that window. For an audit, the shift from "we checked this morning" to "we know right now" is worth more than the speed gain. It is also the answer to the question auditors actually ask, which is not whether you have a policy but whether you can demonstrate it was continuously enforced.
Fewer objects to maintain
Because assets are referenced rather than embedded, and configurations are reused across activations, the object count stops growing linearly with your policy matrix. Rotating an identity certificate becomes an asset update instead of a re-push of every profile that contained it. Retiring a policy becomes removing an activation.
Self-healing app deployment
App management declarations changed the failure mode. Under imperative MDM, an app that failed to install, got deleted by a user, or stalled mid-update stayed broken until somebody noticed and triggered a resync. A declarative managed app carries its intended state. If it is missing, the device reinstalls it. If it is out of date and Auto Update is enforced, the device updates it. No ticket, no resync, no admin in the loop.
The managed app controls that ship with it are the ones admins ask for by name: force Auto Update on regardless of the user's App Store setting, restrict downloads to Wi-Fi only so a field team does not burn a data plan on a 400 MB update, and lock or hide a managed app so it cannot be removed.
Less server, less troubleshooting
Server load drops, which sounds like an infrastructure footnote until you pass a few thousand endpoints and your MDM starts straining under its own polling. And when something does break, a proactive status report tells you what changed and when, without you constructing a query to go find out.
What changes for the person holding the device
DDM is almost always discussed from the console. But the people carrying these devices feel the change too, and what they experience is what decides whether your rollout gets remembered as an improvement or as a nuisance.
Updates stop ambushing people
The old enforcement endgame was a 60 second countdown and a restart, frequently in the middle of something that mattered. Declarative software update replaces the ambush with a runway. Notifications can begin up to 14 days before the deadline, and you control their frequency and wording. Deferral windows run from 1 to 90 days, and you can set different windows for a minor update and a major OS upgrade.
The good outcome is the boring one: the Mac downloads and installs during a window when nobody is using it, and the user never sees a countdown at all. Their machine is simply current. When the deadline does arrive, it arrives as the last step of a conversation the user has been part of for two weeks, not as a surprise.
Apps that repair themselves quietly
From the user's side, self-healing app deployment means the app they need is there, in the version it is supposed to be, without them filing a ticket to explain that it disappeared. The Wi-Fi-only control matters here too. Nobody wants their personal data allowance spent on a managed app update at an airport.
Less confusion about what IT can see
This one is subtle and worth saying out loud to your users. Declarations describe intent and are scoped to what the management declaration allows. On a personally owned device the boundary between managed and personal is defined by the enrollment type, not by how aggressively the server polls. Being able to explain that boundary clearly is half the battle in a BYOD program.
Software updates: the case that closes itself
This is the domain with the highest payoff, the one Apple has closed the imperative path on, and the easiest to show results with.
A declarative software update configuration takes a target OS version and an enforcement date. From there the device owns the sequence: check availability, download in the background, notify the user on the schedule you set, install, restart. Progress and failure states come back through the status channel, so a stuck device is visible as a state rather than as an absence of confirmation.
Our guide to MDM patch management goes deeper on the update cadence itself.
What is new in iOS 27, iPadOS 27 and macOS 27
WWDC 2026 was the release where Apple stopped adding to DDM and started moving things into it. Announced on 8 June 2026 and shipping in September 2026, the 27 releases bring the largest single transfer of capability out of legacy profiles so far.
Networking moved. Six new configurations replace legacy network payloads: network.vpn-plugin, network.ikev2, network.ipsec, network.always-on, network.dns-proxy, network.dns-settings and network.relay. If you maintain VPN profiles by hand, this is the year that work changes shape.
Web content filtering moved, to webcontent-filter.plugin. Content caching on supervised Macs moved to content-cache.settings, replacing the old com.apple.AssetCache.managed profile.
Siri, Apple Intelligence and keyboard settings moved out of the restrictions payload into siri.settings, intelligence.settings, external-intelligence.settings and keyboard.settings. The corresponding restriction keys were deprecated back in the 26.4 releases, so the migration window has been open for a while.
Legacy profiles can now be delivered as assets. A ProfileAssetReference lets you point a legacy or interactive profile declaration at a hosted profile, which turns "we still have forty profiles we have not converted" from a blocker into a staging step.
New status items landed: mdm.enrollment-type, mdm.is-awaiting-configuration, mdm.is-return-to-service, device.system.health and security.lockdown-mode. These are predicate fuel. Being able to gate a configuration on enrollment type or lockdown mode, evaluated on the device, removes a category of server-side group logic.
And the headline, again, because it is the one with a date attached: legacy software update management no longer functions in any 27.0 operating system, including the associated commands, queries and restrictions.
What DDM does not change
Enrollment. Devices still arrive through Automated Device Enrollment and Apple Business Manager, and DDM runs on top of that groundwork. If your ABM setup is messy, declarative management will not tidy it.
Your MDM is also still the thing that delivers declarations, so this is not a tool you drop. It is a change in how your existing tool talks to devices. And DDM runs alongside imperative MDM rather than replacing it overnight. If the surrounding acronyms are blurry, our guide on endpoint management and UEM lays out how MDM, EMM and UEM relate.
What Appaloosa handles for you
The migration order, the clash between a declaration and an old profile, the question of which devices are capable of what: Appaloosa handles that transparently. Policies you have already configured are delivered declaratively on compatible devices, and devices on older releases keep getting the imperative equivalent. You do not pick a model per device and you do not maintain two policy sets.
Two decisions stay yours, because they are operational rather than technical. Target a specific OS version rather than "latest", so your fleet lands on a known build and support diagnoses one configuration instead of six. And stagger enforcement dates by group, so a pilot cohort hits the deadline two weeks ahead of everyone else and finds the internal app that breaks before 3,000 people find it for you.
Frequently asked questions
Do I need to re-enroll devices to use DDM?
No. DDM runs over the existing MDM enrollment. If a device is enrolled and on a supported OS, it can receive declarations.
Which OS versions do I need?
The baseline for declarations is iOS 17, iPadOS 17 and macOS 14. Coverage widens with every release after that, and the 27 releases are where several domains become declarative-only.
Is DDM only for supervised, company-owned devices?
No, though scope differs. Supervised corporate devices get the widest coverage, including app installation. Personally owned devices under user enrollment get a narrower, deliberately limited set.
The direction of travel
Apple has stopped hinting. New management capability now ships declarative-first, existing capability is being moved across release by release, and with the 27 operating systems the imperative path started disappearing rather than merely falling out of favor. If you run Apple devices at any real scale, the question is no longer whether to adopt DDM. It is whether the platform you already pay for has.
Appaloosa supports declarative device management. The status channel is live, so devices report state changes in real time instead of waiting to be polled, and declarative configurations cover software update, managed apps, Siri and keyboard settings. Coverage grows declaration by declaration rather than all at once, which is the honest way to describe where every platform is right now. Appaloosa manages iPhones and iPads and Macs through Apple Business Manager and Automated Device Enrollment, so the enrollment groundwork DDM depends on is already in place. To see what runs on each platform, compare the feature matrix.