macOS - Software - Download Latest macOS Installer

What the macOS installer staging Worklet does

This Automox Worklet™ downloads the latest available macOS installer from Apple's software update servers and parks it in /Applications on every Mac endpoint under Automox management. The Worklet reads the current latest macOS build from https://support.apple.com/en-us/HT201260, compares it to the endpoint's reported ProductVersion, and only downloads when the endpoint is genuinely behind the latest release. The installer that lands in /Applications is the same Install macOS <Name>.app bundle a user would receive through Software Update, just placed there without an interactive session.

The fetch itself is driven by softwareupdate --fetch-full-installer --full-installer-version <build>. On Intel endpoints the command runs under sudo. On Apple Silicon endpoints the script picks the first available Secure Token holder – the _automoxserviceaccount when present, otherwise the current console user – because the softwareupdate binary refuses to cache an installer when invoked by an account that cannot bless the upgrade. The download is roughly 12 GB to 15 GB depending on the macOS release, and it can take up to an hour on a constrained connection.

The script is read-only beyond the /Applications drop. It does not modify softwareupdate preferences, write MDM-style configuration profiles, or change the user's account. If the download fails midway, macOS deletes the partial Install macOS <Name>.app on its own, so no cleanup Worklet is required before the next attempt.

Why pre-stage the macOS installer before an upgrade window

Major macOS upgrades fail the user experience test on download time, not install time. A 12 GB to 15 GB Install macOS Sonoma.app or Install macOS Sequoia.app over a hotel Wi-Fi or a constrained home connection can take 45 to 90 minutes before the upgrade itself begins. When the download and the install collide inside a single maintenance window, the laptop is unusable for the entire span, support tickets climb, and the upgrade gets deferred again. Pre-staging splits the two phases: cache during off-hours over the corporate or home network, then trigger the in-place upgrade during the actual window when only the install step remains.

Across a fleet, the bandwidth math is the more painful version of the same problem. Hundreds of endpoints reaching for Apple's CDN simultaneously will saturate the egress link and slow the upgrade for every endpoint behind it. Staging lets you stagger the download across days, while still gating the install on a single shared deadline. Pre-staging is the lowest-cost action you can take ahead of a large-OS-upgrade campaign: schedule this Worklet across a week of off-peak evaluation windows so every targeted Mac arrives at the upgrade policy with the installer already cached in /Applications.

How macOS installer staging works

1. Evaluation phase: The Worklet reads the Darwin major version with uname -r and compares it to 19 to confirm macOS Catalina or later, the minimum that supports cached installers. It curls Apple's HT201260 support page to read the latest macOS major build, then runs sw_vers ProductVersion to read the endpoint's current major build; if they match, the endpoint is already current and the Worklet exits 0. It runs df -h / to require at least 25 GB free and scans /Applications for an existing Install*.app to skip duplicate downloads. On Apple Silicon (uname -m returns arm64) it then runs sysadminctl -secureTokenStatus against the console user and _automoxserviceaccount to confirm at least one Secure Token holder is available. Any failed gate exits 0 and skips remediation; only a fully eligible endpoint exits 1 and proceeds.

2. Remediation phase: The remediation script rebuilds the same variables, branches on uname -m, and runs softwareupdate --fetch-full-installer --full-installer-version <latest>. On Apple Silicon it prefers sudo -u _automoxserviceaccount when that account holds a Secure Token, otherwise sudo -u <console user>. On Intel it runs the command under sudo directly. A non-zero return from softwareupdate exits 1 with a stderr message naming a likely network drop or unsupported version. A final downloadCheck step lists /Applications/Install*.app and exits 0 only when the installer is present on disk, so the policy result accurately reflects whether the cache step succeeded.

macOS installer staging requirements

• Mac endpoint running macOS Catalina 10.15 (Darwin 19) or later; earlier macOS releases cannot cache installers via softwareupdate

• At least 25 GB of free space on the boot volume, measured by df -h /

• Outbound HTTPS reachability from the endpoint to support.apple.com and Apple's swcdn.apple.com / mesu.apple.com software update hosts

• On Apple Silicon endpoints, Secure Token enabled on either the _automoxserviceaccount or the current console user (verify with sudo sysadminctl -secureTokenStatus <user>)

• Hardware on Apple's supported list for the target macOS release; Macs older than 2018 are frequently excluded and should be scoped out of the policy

• Extended Worklet timeout in the policy settings; the full download can run up to an hour on a constrained link

• No conflicting Install*.app already present in /Applications (the evaluation phase will skip the endpoint and report the existing installer name)

Expected endpoint state after the installer is staged

After a successful remediation, /Applications contains an Install macOS <Name>.app bundle that matches the latest release Apple is publishing at the time the Worklet runs – typically Install macOS Sonoma.app or Install macOS Sequoia.app. The bundle is owned by root, sized at roughly 12 GB to 15 GB, and ready to be invoked by the companion upgrade Worklet using startosinstall. The endpoint reports exit code 0 in Automox activity logs, and a subsequent run of this same Worklet exits 0 immediately because the evaluation phase detects the cached installer and skips the download.

Validate from a terminal session or a follow-on Worklet with ls -lh /Applications/Install\ macOS*.app and confirm the bundle's Info.plist version with defaults read /Applications/Install\ macOS*.app/Contents/Info.plist CFBundleShortVersionString. For audit evidence, capture the Worklet's standard output – it logs the exact build number requested from Apple and the path of the resulting bundle. If a future evaluation finds the bundle missing (a user deleted it, or a disk cleanup tool swept /Applications), the next policy run will redownload it, so the endpoint stays staged through the run-up to the upgrade window.