macOS packages: move to declarative MDM deployment
Apple now documents the declarative lifecycle for packages on macOS: required or optional installation, updates, removal, and status reporting. For IT, the value goes beyond replacing a script: every .pkg becomes a verifiable policy object on supervised Macs.
1. What Apple officially documents
The com.apple.configuration.package configuration allows an MDM service to install and monitor packages on macOS. It applies only to supervised devices, in the system scope, and on the device channel. The Mac downloads a manifest identified by ManifestURL; that manifest references one package and includes its identifier, version, URL, and SHA‑256 hash.
Apple requires a signed package with a verifiable signature. Installation can be Required, starting when the configuration is applied, or Optional, initiated by the user through a management app. If the package installs an app, that app can subsequently be managed separately through AppManaged.
2. Updates remain an explicit MDM decision
A package does not update automatically. The management service must change the manifest’s bundle-version value and then change the configuration’s ServerToken. The Mac checks the manifest again and installs the new version when required.
This mechanism makes promotion explicit: qualification, pilot, broad rollout, and status reporting can use separate groups. In return, it requires a reliable publishing chain for the manifest, package, hash, and version number. Replacing a file without consistently updating those elements is not a patching strategy.
3. Removal must be decided before installation
When Remove is true at installation time, macOS tracks files and directories the package creates or updates so it can remove them with the configuration or at unenrollment. Later changes, including those made by a post-install script or the user, are not tracked.
Apple specifies that enabling Remove after installation does not recreate that history. If the option is absent or false, only the system metadata for the package is removed. Reversibility therefore needs to be a design decision validated with the vendor and business owner, not a setting added during an incident.
4. What does this change for a Belgian or French organization?
For an SMB, this model reduces dependency on isolated scripts and improves support visibility. For a mid-sized company, large enterprise, or public-sector organization in Belgium or France, it supports a common software chain spanning Apple Business Manager, Automated Device Enrollment, Jamf or another MDM, package hosting, and security governance.
Declarative status distinguishes states such as queued, downloading, installing, installed, and failed, including failure reasons. IT teams can therefore measure deployment without multiplying periodic queries. This does not replace application qualification or license management: status confirms the package’s technical state, not the contractual or functional compliance of the app it contains.
5. Underside analysis: treat the package as a supply-chain artifact
Our view is that a declarative package should be governed like a software artifact: approved source, verified signature, immutable hash, owner, version, scope, removal rule, and deployment evidence. The manifest becomes a contract between hosting, MDM, and the Mac, so its availability and integrity belong in operational controls.
This approach complements the declarative lifecycle for managed apps and declarative Apple software update management. It is especially relevant to security agents, network tools, business connectors, and components distributed outside the Mac App Store.
6. Recommended migration plan
- Inventory packages, owners, sources, scripts, and current update methods.
- Verify supervision, MDM support, and system scope with a pilot group.
- Sign each package and publish a versioned manifest with a SHA‑256 hash.
- Decide before installation whether file removal needs to be enabled.
- Separate required packages from the optional catalog, with promotion criteria.
- Feed status and failure reasons into support dashboards and runbooks.
Objective: move from a file-and-script repository to a signed, observable, and reversible macOS package chain governed through MDM policy.
Structure your Mac deploymentsOfficial source: Apple Developer — Installing packages.