Installing macOS on external bootable disks connected to Apple silicon Macs has been one of the most frustrating experiences of my life, and has driven some more experienced than me to abandon their attempts altogether. The latest bug in this was reported by Michael Tsai earlier this week, and can prevent you from installing any version of macOS prior to Sequoia, on an external disk connected to an Apple silicon Mac running macOS 15.3.2, and likely earlier versions of Sequoia.

To reproduce this, I partitioned an external 2 TB SSD connected to my MacBook Pro M3 Pro, which originally shipped with Sonoma 14.1. I have on many occasions installed macOS on that SSD for use with Apple silicon Macs, and hadn’t had a failure with it. To ensure favourable winds, I connected the SSD to the USB-C port at the right of the left side of the case, which isn’t the designated DFU port.

Apple disables installers for previous major versions of macOS from running in more recent versions. Trying to run a Sonoma installer in Sequoia is therefore doomed to fail. Instead, the installer has to be converted into a bootable installer volume, and the Mac booted from that to perform the installation. Although you can use a USB ‘thumb’ drive for that purpose, I prefer to use a 100 GB partition on a convenient external disk, in this case the same SSD on which macOS was to be installed. One of the quirks of bootable installers is that they must still use HFS+ rather than APFS, hence they get a partition of their own.

The three partitions I created were:

• APFS container with two APFS case-insensitive unencrypted APFS volumes in 900 GB
• APFS container with one APFS case-insensitive unencrypted APFS volume in 1 TB
• HFS+ Journaled volume in 100 GB.

I used two Sonoma full installer apps, one for 14.6.1 taken from my library, the other for 14.7.4 freshly downloaded from Apple, both installed from InstallAssistant packages into /Applications. Each was successfully installed individually into the HFS+ volume on the external SSD following the instructions given by Apple.

In each test, I entered the external installer from Recovery mode as detailed by Apple, and started installation to one of the two APFS volumes in the first APFS container on the external SSD. After long periods attempting the installations, both failed with exactly the same error reported by Michael Tsai: com.apple.OSinstallerSetup.error error 702

Between the two attempted installations, both the HFS+ volume and the destination APFS container were erased and set up again. Following those two failures, I successfully installed macOS 15.2 and 15.3.2 direct to the three APFS volumes on the external SSD without any problems, and verified that all three Sequoia installations had been completely successful.

I therefore conclude that, in Sequoia 15.3.2 at least, it’s not possible to install any version of macOS prior to Sequoia 15.0 on an external SSD connected to an Apple silicon Mac. If your experience differs, then please let me know how you did it.

Michael Tsai appears to have been successful only when running the installation from Sonoma. If you do need access to a non-virtualised installation of Sonoma or earlier, it appears the only way you’re likely to succeed is from Sonoma, which would require you to perform a full DFU Restore to revert the Mac to macOS 14.

Useful tricks

• The Mac must be capable of running that version of macOS.
• The external disk must be connected to a port other than the DFU port.
• When installing an older major version of macOS, perform this from an external bootable HFS+ volume as detailed by Apple.
• Use an HFS+J partition on an external SSD rather than a USB ‘thumb’ drive.
• Boot from the installer volume through Recovery mode.
• When using a laptop model, run it from mains power throughout macOS installation.
• If essential, you can revert the Mac’s internal SSD to an older version of macOS and firmware using a full DFU Restore with an appropriate IPSW image file.
• Use a Virtual Machine instead, if you don’t need to be able to run software from the App Store.

With Mac OS X came a new tool for installing and updating the system, quite different from what had been used in Classic Mac OS. The Mac OS X Installer app uses packages (.pkg), and metapackages (.mpkg) containing multiple packages to be installed together. Apple thus provided installations and updates as metapackages that could either be downloaded from its update servers using Software Update, or from the update’s web page. The same method was used until Big Sur, when updates changed again.

A system update in Mac OS X 10.1.3 in March 2002 was installed by the Installer app following authentication.

This update required just 148 MB of disk space, and could readily be accommodated by any of these volumes of 11.5 GB capacity.

Most updates were concluded by a period ‘optimising system performance’, as determined by the post-install scripts in the package.

Here, Software Update is delivering Security Update 2004-05-03 to Mac OS X 10.3.3 Panther. Some system components like QuickTime were still supplied and installed separately, but the great majority of Mac OS X was integrated into a whole, and there were no options to install separate components.

Over this period, the system and user data shared a single boot volume, and updating the system mainly involved replacement of updated files. Installer packages contained those replacements together with scripts that were run to update the contents of the boot volume. For much of this, firmware updates were still supplied and installed separately, although later they were integrated into macOS updates.

Until the introduction of System Integrity Protection (SIP) in El Capitan, the only protection provided to system files and folders was in their permissions. Incomplete or incorrect installations and updates were therefore not uncommon, as despite its name, SIP didn’t have any means of verifying the integrity of system files. A procedure was introduced to verify directory structures and permissions against those listed in the Bill of Materials (BoM) for macOS updates, by repairing permissions, but that was still unable to verify the integrity of the files themselves.

Installer metapackages are highly portable, and were commonly downloaded to be installed on multiple Macs. To keep updates as small as possible, they were provided in two forms: a Delta update converted only the previous release, while a Combo update contained everything required to update the last major version and all intermediate minor versions in a single step.

The High Sierra 10.13 upgrade in September 2017 brought greatest change, with its inclusion of Apple’s new file system APFS. Macs that didn’t have a Fusion Drive had their system volume converted to APFS during the upgrade, although it was another year before the same happened to Fusion Drives.

Updates didn’t always work out right for everyone. This was a common problem with High Sierra Supplemental Update of 29 November 2017, for example.

This all changed with the first version of macOS to boot from a signed snapshot, Big Sur, in November 2020, to support the improved Secure Boot of Apple silicon Macs. This abandoned the use of Installer packages, relying instead on an Update Brain integrated into each installer app and downloaded update.

From then onwards, Apple has provided several different presentations of macOS installers and updates:

• Updates are only delivered through Software Update or its command tool equivalent softwareupdate, and have to be downloaded from Apple’s servers, or delivered through a local Content Caching Server.
• Full macOS installer apps are offered in the App Store then delivered through Software Update.
• Full macOS installer packages are available through softwareupdate or direct from Apple’s servers, and are named InstallAssistant. When installed, these create a full installer app.
• Full macOS installers are offered in Recovery, from where they’re downloaded from Apple’s servers.
• Full IPSW images containing firmware, Recovery and macOS partitions can be installed to restore Apple silicon Macs in DFU mode, using Apple Configurator 2 or later versions of the Finder. Those effectively reset that Mac to factory condition with that version of macOS pre-installed.

There are further complications to this. For instance, an older macOS Installer app can’t be run in a newer major version of macOS. The workaround for that is to create a bootable installer volume, and boot from that to run its older installer.

macOS updates are supplied compressed, and require up to 30 minutes preparation before they can be installed.

There are now no optional installations, as every copy of any given version of macOS is identical within its Signed System Volume (SSV).

The size of these new updates is considerably greater than those of older Installer packages, particularly in Big Sur, as engineering optimisations were being performed.

This chart shows cumulative sizes of updates to macOS on Intel Macs from 10.14 Mojave, with its traditional single boot volume, through to macOS Sonoma 14.6. Each point represents the cumulative sum of all updates to that major version of macOS required to reach that minor version. Thus the point for 14.2 is the total of update sizes for 14.1, 14.1.1, 14.1.2 and 14.2. Sizes used aren’t those reported by Software Update, but those of the download itself, as reported in articles here, indexed on this page. Lines shown are best fits by linear regression.

Update sizes rose markedly from Mojave, with its single boot volume, to Catalina, with its boot volume group, and again to a peak in Big Sur, with the SSV. They fell again as Monterey introduced greater efficiency, and Ventura and Sonoma have been almost identical, and smaller than Mojave.

Apple silicon Macs started with the huge updates of Big Sur, which were even larger than those for Intel models, and benefitted from the improved efficiency of Monterey and Ventura. Unlike Intel Macs, though, Sonoma has seen further reduction in update sizes, although in each update they remain significantly larger than those for Intel models.

macOS Ventura in 2022 experimented with Rapid Security Responses (RSRs), much smaller updates intended to provide urgent security fixes to Safari and some of its supporting components. These take advantage of cryptexes, cryptographically verified disk images stored on the hidden Preboot volume. Updating cryptexes alone is far quicker too, as the SSV is left untouched. Unfortunately, the second RSR resulted in serious problems with Safari so had to be replaced three days later. The last RSR was released on 12 July 2023, and they appear to have been abandoned since.

Upgrading to the first release of the next major version of macOS had required downloading its full installer app from the App Store. Apple broke from this in macOS Ventura in October 2022, when that new macOS was installed as an update instead. Although this reduced its size and installation time required, it caught many users on the hop, as Apple provided no warning of the change. This approach has since become standard with both Sonoma and Sequoia.

Installing and updating the Mac’s operating system has probably changed more over the last 41 years than any other feature.

Installing and updating the Mac’s operating system has probably changed more over the last 41 years than any other feature. Initially in Classic Mac OS there was little more to do than install the System and ‘bless’ that disk to make it bootable. As the System became more complex and grew various extensions this required a more formal installation process, and Mac OS and its components were stored inside the System Folder. In this article, I summarise how this worked towards the end of Classic Mac OS, in version 9.1 in 2001, the same year that Mac OS X 10.0 Cheetah was released.

By this time, Mac OS was distributed on CD-ROM rather than a stack of floppy disks, and it was quite usual to install only selected parts of it. Installation was considerably easier if you had more than one volume available on your Mac’s hard disk, as that allowed you to run from one volume while installing or updating into another. As those were HFS+ volumes, they were fixed-size partitions of the disk, corresponding to containers in APFS.

ROM updates were provided separately, and you had to check Apple’s support site to discover whether your Mac required an update. If it did, then that had to be performed as a separate step before upgrading Mac OS.

Another vital task before installing or upgrading Mac OS was to run the new version of Disk First Aid provided on the CD-ROM to check and repair disks. Minor errors were common, but if left they could bring disaster, leaving one or more volumes completely broken.

Once all mounted volumes had been checked and repaired using Disk First Aid, you opened the Drive Setup utility provided on the installer CD-ROM. Although the Mac OS installer would by default update any disk drivers it could, it was best to do this manually first, then restart the Mac, so those updated drivers could be used during installation.

Classic Mac OS installer apps relied on proprietary compressed archives called tomes containing the software to be installed. A full installation of Mac OS 9.1 consisted of multiple tomes for each of its components including the main system, Internet access, ColorSync, and so on.

Once restarted you then ran the installer, which was largely self-explanatory. If you were updating a volume that already had Mac OS on it, you could opt to perform a clean install by selecting this as one of the install options. There was also a freeware Clean Install Assistant to help move over old System Folder contents easily.

Although recent installers had improved considerably, most normally opted for a ‘custom’ installation by clicking on the Customise button, rather than just accepting that recommended.

That enabled you to browse through the components to be installed, and to ensure that nothing important to you was missed out. If you didn’t get those right first time, you could always run the installer later to add the bits you forgot.

It was also common practice to check what was in the Recommended Installation for each component. There were a great many components in the main Mac OS 9.1 install item, some of which were seldom wanted. You needed to take your time and browse these thoroughly before pressing ahead. Once the installation had completed, you then used the Startup Disk control panel to select the volume containing Mac OS 9.1, and restarted.

Starting up from the newly installed system then opened the Mac OS Setup Assistant to configure the new system. You might then find that some drivers were missing, in this case for a Graphire pad. Many of those could be found and installed from the Internet.

The installer could also be run to install or re-install individual components of Mac OS using its Customize button.

For example, to re-install the OpenGL components from within Mac OS 9.1, you opted for a custom installation mode for the Mac OS 9.1 group, and unchecked all the other components. Because these were listed in a hierarchical series, this was fairly quick provided you were careful not to leave any checked inadvertently.

Some components, such as QuickTime, weren’t readily installed from the Mac OS Installer. If you looked through the folders on the CD-ROM could locate their installer scripts. Sometimes, double-clicking that script would start the installation process. However, particularly with Mac OS 9.1, you would probably see this error message. In that case, you’d have to perform a manual install from its file tome, using the freeware TomeViewer utility.

You dragged and dropped the installation tome file on TomeViewer, and it opened up its contents as a list like this. You could either get it to extract the entire contents of the tome, or you could select one or more files and extract them into a folder before installing them manually into the System Folder of your choice.

Once you had saved the individual components you needed, you dragged and dropped them onto your System Folder. It would automatically put them into the correct folders within – Control Panels, Extensions, etc. However, some might require to be put in sub-folders within those. If you were unsure, you could always copy the layout of a fully functional System Folder.

Installing and maintaining Mac OS 9.1 was a complex process even when you were content to follow the recommended installation, and it could easily occupy you for several hours to get it just right.

One of the better trends in recent versions of macOS has been to make apps more self-contained, and to disperse their dependent files less. It’s not that long ago that any app of substance needed its own folder in either of the Library/Application Support folders, in various more obscure locations, as well as in the user’s ~/Library/Preferences folder. When you migrate from one Mac to the next, this leads to inherited clutter that requires painstaking manual clean-up.

This in turn has led to a flourishing industry hiring out housekeeping services and other utilities that attempt to perform the clean uninstall that is surely the responsibility of any app that scatters its files to the four corners of your Mac. After all, if it doesn’t know what files it installs, it shouldn’t be offered to the public.

A few remaining apps that still come as Installer packages may offer uninstaller scripts, and macOS now automatically removes any system extensions installed by an app when that app is removed. LaunchAgents, LaunchDaemons and other helper executables that used to require installation of their property lists into Library folders can now retain them within the app bundle. Containerisation of sandboxed and some other apps has the useful side-effect that it can provide clues as to what might need to be removed with an app, but in other respects can confuse instead of clarifying.

Apple’s motivation for these changes in macOS is more about improving security, and less about convenience to the user. Containers are the sandbox within which an app is constrained. Keeping more of an app’s components inside its bundle gives them the protection afforded by the CDHashes in its signature, and verification against those obtained during notarization, making it far harder for those components to be hijacked maliciously.

Starting from the premise that an app developer should know full well what their app does install and where those files are to be found, wouldn’t it be best for that app to provide a list? Perhaps a property list of the app’s manifest of files it installs outside its bundle might be a workable solution? Then a user who wants to completely uninstall an app can use that list to hunt and remove stragglers like a private log file tucked away in ~/Library/Logs. This would also facilitate the task of cleaning up using a housekeeping utility or app remover.

A simple example might be my app Mints. In normal use, the only file it installs outside the app bundle is that containing its preference settings, in ~/Library/Preferences/co.eclecticlight.Mints.plist. However, it does have a feature that will create a folder of test files inside ~/MintsSpotlightTest4syzFiles, and provides a button to delete that folder and its contents.

A manifest property list might provide two entries to account for those:

• a mandatory item for ~/Library/Preferences/co.eclecticlight.Mints.plist,
• an optional item for ~/MintsSpotlightTest4syzFiles and its contents.

A person or app wanting to clean up after the removal of Mints should then delete the first and, if the second is present, should delete that too. As Mints isn’t sandboxed, no folder should be created in ~/Library/Containers, and it doesn’t write private logs in ~/Library/Logs either, so there’s no point in checking for its mortal remains in either of those locations.

Almost every app already has a Resources folder inside its app bundle, which should be a suitable place to save this manifest.plist file, although as that is deleted when the app is removed, it would perhaps be most helpful for those manifests to be copied into a separate folder in /Library for reference and later use once the app has gone.

I’d be interested to read your opinions, and suggestions for better alternatives.