You need to apply macOS updates across a fleet of Macs without a person at each keyboard. What does the softwareupdate command let you do, and why do Apple Silicon machines make fully unattended OS updates harder?

## The command surface `softwareupdate` is the client for Apple's update service. The subset that matters in automation: ```bash softwareupdate -l # list what is available softwareupdate -d -a # download all, install later softwareupdate -i -a # install all softwareupdate -i -r # install recommended only softwareupdate -i -a -R # install all, then restart softwareupdate --fetch-full-installer # download a full Install macOS app ``` The short flags have long equivalents (`--list`, `--download`, `--install`, `--all`, `--recommended`, `--restart`), and long forms are better in scripts you expect someone else to read. Two categories hide behind one command. **Minor updates and security content** install in place. A **major upgrade** is a different animal: `--fetch-full-installer` (optionally with `--full-installer-version`) downloads the `Install macOS` application into `/Applications`, and the installer app contains a `startosinstall` binary that drives an unattended upgrade. Conflating the two is a common wrong turn — you do not "softwareupdate" your way across a major version the same way you apply a security patch. ## Why Apple Silicon changes the story On Apple Silicon the OS lives on a signed, cryptographically sealed system volume, and changing it changes what the machine is permitted to boot. That decision is bound to **volume ownership**: a local user account holding a secure token is an owner of the data volume and is the entity allowed to authorise operations that alter the boot policy — including OS updates. Root alone does not satisfy that. A script running as root can install many things, but the OS update path asks for an owner's credentials, which is why the command grew the flags: ```bash softwareupdate -i -r --restart --user adminaccount --stdinpass <<< "$PASSWORD" ``` That works, and it is also the reason nobody wants to do it: you have just put a privileged local password into a script and into process arguments' orbit. It is defensible for a lab, not for a fleet. ## The fleet answer: bootstrap token The supported way out is the **bootstrap token**. When a Mac is enrolled in MDM, it can generate a bootstrap token and escrow it with the management server. The token lets the MDM authorise operations that would otherwise need a volume owner's password — notably granting a secure token to accounts and authorising software updates — without any human credential being scripted. With that in place the management server issues an update command directly, and the machine performs the update on its own schedule. Newer macOS releases push this further with **declarative device management**, where the server declares a target version and an enforcement deadline and the device manages the download, the user nudges and the enforced install itself. In both cases the shape of the answer is the same: authorisation moves from a password in a script to a trust relationship established at enrollment. ## Policy is a profile, not a flag `softwareupdate` executes; it does not set policy. Deferral of visible updates, enforced deadlines, whether to install automatically, and whether users may initiate upgrades come from a configuration profile — the restrictions domain `com.apple.applicationaccess` carries update-deferral settings, with a documented maximum deferral window — or from declarative management. An interviewer asking about fleet updates is usually probing whether you separate the mechanism from the policy layer. ## Operational realities worth naming - **Reboots are the hard part, not downloads.** Any credible plan sequences the restart: notify, defer within a bounded window, then enforce. This is a change-management problem wearing a technical hat. - **Pre-download.** `-d` fetches without installing, so the disruptive part is short and the network burst does not coincide with the maintenance window. - **Version pinning is limited.** You can defer, and you can target a version through management; you cannot indefinitely freeze a fleet on an unsupported release without accepting the security cost. - **Test ring first.** Major upgrades break tooling — build agents, drivers, extensions — so a staged rollout across rings is the professional answer, not a fleet-wide push. ## What a strong answer sounds like Give the command surface briefly, then spend your time on the interesting part: minor update versus major upgrade are different mechanisms; Apple Silicon binds OS updates to volume ownership; the fleet solution is MDM enrollment with an escrowed bootstrap token rather than a scripted password; and policy — deferral and deadlines — is delivered as a profile or declaration, separate from the command that does the work.