Apple has just released the update to macOS Sequoia to bring it to version 15.5, and security updates for 14.7.6 and 13.7.6.
The Sequoia update for Apple silicon Macs is just under 3 GB in size, and just over 2 GB for Intel Macs.
Apple’s general release notes for Sequoia 15.5 only mention one new feature, that parents now receive a notification from a child’s device when its Screen Time passcode is used. Otherwise, it’s the usual “enhancements, bug fixes, and security updates”.
Security release notes for Sequoia 15.5 are here, and list 46 vulnerabilities fixed, none of which are reported as believed to have been exploited already. Those for 14.7.6 are here, and for 13.7.6 are here.
One important entry in the Enterprise release notes concerns the future of AFP: “Apple Filing Protocol (AFP) client is deprecated and will be removed in a future version of macOS.” I can hear the howls of anguish already.
large network shares should enumerate correctly in the Finder,
Pro Display Calibrator should work properly on M4 MacBook Pros,
apps registering helper executables should now do so correctly.
The macOS build number is 24F74. Firmware in Apple silicon Macs is updated to iBoot version 11881.121.1, while that in T2 Macs is updated to 2075.120.2.0.0 (iBridge 22.16.15072.0.0,0).
Safari is updated to version 18.5 (20621.2.5.11.8), and there are 8 security bugs fixed in WebKit (15.5).
Support for document versions in iCloud Drive has a curious history. Both iCloud Drive and the macOS versioning system were introduced in OS X 10.7 Lion, in 2011, but haven’t fully integrated over those 14 years. Until 2018, versions were only saved locally and never propagated to other Macs and devices through files shared in iCloud Drive. Then sharing of versions was added, but proved patchy and unreliable, although sometimes versions were propagated in a frenzy. By 2023, that experiment had ended, and behaviour reverted to the original. This article explains how it works now.
Demonstration
To show this, I used Versatility to convert a Pages document into a folder containing each of its seven versions, and moved that folder into iCloud Drive. Once there, I dragged and dropped that folder onto Versatility again to convert it back to a versioned Pages document in my iCloud Drive folder. I then dropped that onto Revisionist to browse those versions and confirm that they remained good.
Although the current version is located in iCloud Drive, with a path from ~/Library/Mobile Documents/com~apple~CloudDocs/, each of its previous versions ‘has local contents’ in a path from /System/Volumes/Data/.DocumentRevisions-V100/PerUID/501/, inside the Data volume’s version database.
On another Mac connected to the same Apple Account and iCloud Drive, that document only has the current version, again with ‘local contents’, as its previous versions are left stored on the other Mac.
If you then edit that document on the second Mac and save a new version there, then make more changes and save another version, those previous versions will remain stored in the second Mac’s version database, but only the current version will be synced to iCloud Drive, and appear as the current version on the first Mac. That still sees the six previous versions stored there from before, but can’t see those added by the second Mac.
Conclusion
Thus each Mac and device – as this applies similarly to versions saved in iOS and iPadOS – sees the common current version synced across iCloud Drive, and only those older versions created and saved on that Mac or device. There is no sharing of document versions in iCloud Drive.
While this behaviour is reliable and consistent, unlike the profusion of versions that occurred in macOS Mojave, it demonstrates how readily versions are discarded when they could or perhaps should have been preserved.
Beware Sonoma
In this respect, I have one important warning concerning versions and iCloud Drive: never use those in macOS Sonoma 14.4. That version of macOS has a serious bug that strips all local versions from any document that’s evicted (its download is removed) from iCloud Drive. Apple fixed that swiftly in the update to 14.4.1, so if you are still using Sonoma, ensure it’s 14.4.1 or later.
How to transfer document versions through iCloud Drive
If you need to work on a document with shared versions, the only solution is clumsy but effective, using Versatility. Keep the live document outside iCloud Drive, in local storage, and transfer it in iCloud Drive using its folder archive generated by Versatility:
Edit the local document on Mac A. To transfer it, drop it on Versatility and save its folder archive to iCloud Drive.
On Mac B, drop the folder archive in iCloud Drive onto Versatility, and save that to its local location for editing there.
To return the live document to Mac A, drop it onto Versatility, and save its folder archive to iCloud Drive, ready to reconstitute on Mac A.
Postscript: Use a disk image
I’m very grateful to @Remo_Pr0 for suggesting an alternative method: save the document in a disk image that you keep in iCloud Drive. Provided that’s larger than 1 GB (smaller sizes are unable to create a local version database), versions will be saved inside the disk image, and preserved for all those Macs that access that document within it. This should also work with a sparse bundle either in iCloud Drive, or in a network share.
If you can think of a better way, please let me know so I can code it into Versatility.
I looked in the macOS cupboard last week and opened yet another can of worms, in those Macs that take many seconds or even minutes to launch some apps. In common with many other thorny problems, there’s little consensus about many of the details, other than this mostly affecting Intel Macs running macOS Big Sur or later, although I have seen reports of similar problems in M1 Macs.
Although some have apparently found solutions, such as Jeff Johnson’s recommendation to disable SIP, the only consistent answer appears to be moving the app to another location and moving it back again. Even that’s only a temporary measure, and sooner or later those apps will launch slowly again.
Last week I thought I might have a chance to get to the bottom of the problem, when Kristian kindly sent me some log extracts from his Mac’s slow launches, and patterns started to emerge. But like every other good can of worms, the deeper I dig into the can, the more worms there are. This article is a convenient opportunity to reveal some of those.
What takes time?
Looking at three test launches of Pages, greatest differences were seen in the time taken to check the many frameworks in the app bundle, shown in purple in the bar chart below.
In the slow launch provided by Kristian, total time was just over 4 seconds, within which checking frameworks took 3.2 seconds, 80% of launch time. A similarly slow launch in my test VM took just over 3 seconds, with 2.5 seconds on frameworks, while a fast launch completed in just over half a second, with less than 0.1 seconds spent in framework checks.
Cache misses and SIP
What I didn’t mention in those log extracts was the role of cache misses in framework checks in the slower launches. At that stage, it looked as if differences were down to whether each framework had to be checked from scratch as its previous assessment couldn’t be found in cached security checks.
I have therefore repeated the VM tests in two further conditions, with SIP disabled, and with Gatekeeper/XProtect checks disabled.
When launched after a restart, with SIP fully disabled, Pages did indeed launch quickly, in a total time of 0.34 seconds with less than 0.05 seconds checking frameworks. However, disabling Gatekeeper resulted in a total launch time that was only slightly quicker than normal at 2.4 seconds, and 1.8 seconds checking frameworks.
Behaviour with SIP turned off was odd, in that no Gatekeeper process assessment was recorded, and there was no mention of any cache misses for framework checks. In contrast, when Gatekeeper was turned off, there was a Gatekeeper process assessment using a previous code evaluation, and cache misses were recorded for all the frameworks checked. My previous experience with disabling Gatekeeper is that its checks still take place and are logged normally, but their results are ignored, so that wasn’t as paradoxical as it might appear.
Calibre
Pages is an atypical example, being an App Store app signed by Apple, so I then turned to the other log record provided by Kristian, from Calibre. This is remarkable for having 68 frameworks, and took a total of 4.6 seconds to launch on his Mac, with nearly 4.4 seconds of that spent checking those frameworks, all of which were cache misses and reported with constraint violations by amfid.
When I tried repeating this in my test VM and with SIP or Gatekeeper disabled, results became far more complicated, so I have summarised them in a table.
Rows in this table record results from each of six launches of the current release of Calibre. The first is that obtained by Kristian on his Mac, the remainder are all obtained from a 4-core VM running macOS 14.7.5 on a Mac mini M4 Pro. Those were:
first run after installation, with the quarantine flag set;
second run a minute or so after that first run, without a restart;
third run after closing the VM and starting it up again;
after downgrading security to permissive by disabling SIP completely;
after disabling Gatekeeper/XProtect checks, but still at Full Security, with SIP enabled.
Total launch time is measured from the initial click in the Finder to the app loading its preferences. Time checking frameworks is measured from the start of the first check called by amfid on one of Calibre’s frameworks, to the completion of the its check on the last framework. XProtect scan is measured between the announcement of the start of Gatekeeper’s XProtect scan, and its completion.
The fastest launch by far was in the second run, when none of the checks were performed, there were hardly any log entries from security subsystems or processes, and it completed in 0.158 seconds. The slowest was the first run, when the XProtect scan took over 6 seconds, and accounted for 77% of the total launch time of almost 8 seconds.
Remaining results fall into two groups: Kristian’s original slow launch, with almost 4.4 seconds taken checking frameworks, all of them being recorded as cache misses, and the three VM tests. The latter were remarkable as launch time was uniform at just over 0.5 seconds, and a fifth of the time spent checking frameworks. That occurred because macOS proceeded to run the app before checking of frameworks was complete. In those three tests, no cache misses were recorded, and time was independent of whether a previous Gatekeeper assessment was used. Two of them even included brief local checks against the app’s notarization ticket.
Neither disabling SIP nor disabling Gatekeeper had any effect on the time taken to check frameworks, nor on the total time taken to launch the app.
Diagnosing slow launches
I have given details of my results because, if there’s one thing they demonstrate, it’s the complexity of determining app launch times. In Pages, much of the delay seems to result from cache misses slowing framework checks, and disabling SIP restored rapid launching, as Jeff Johnson reported. In Calibre, launches proceed without waiting for framework checks to complete, and disabling SIP doesn’t result in any acceleration.
This reflects the complexity of app launch. I’ve here concentrated on security checks, as they have been most commonly blamed for this problem. Other processes that have to be completed during launch include:
LaunchServices registration and coordination
RunningBoard registration and resource management
TCC privacy controls
sandbox and container preparation
iCloud connection
checks for app updates
all other app initialisations
several of which can involve their own security checks.
Although most of those are well recorded in log entries, disentangling them when watching Activity Monitor or in spindumps is more demanding, and there’s ample opportunity to gain false impressions.
But none of these tests or logs represent what happens in the slowest of launches that can take several minutes. Even the 8 seconds total launch time taken on Calibre’s first run pales in comparison to the 300 seconds that some report. There’s a difference of two orders of magnitude, suggesting that really long launch times are different from all the observations and measurements here. There must be something seriously wrong for an app to take several minutes to launch. Investigating that is also a great challenge.
Tackling slow launching
Results above demonstrate how subtle factors can result in fairly modest apps launching in anything from less than 0.2 to almost 8 seconds. If an app regularly takes several seconds to launch, and that irks you, try pre-warming it first. Longer times are more likely to occur after a Mac has been started up from cold, and apps usually launch fastest when they’ve already been run in the same session. Even if your Mac doesn’t have sufficient memory to leave that app running, that could make subsequent launches quicker.
If an app not infrequently takes more than 30 seconds to launch, then finding the cause becomes more important, and if it takes several minutes, you really need to investigate further.
Capturing an excerpt of the whole log for several minutes isn’t going to help, but will just overwhelm you with many MB of inscrutable data. If you know your way around spindumps, you may find them helpful, although they too can only cover brief periods of time. There are some basic steps you can take that can also help you diagnose and address performance problems more generally:
Measure launch time carefully and record it. Counting icon bounces in the Dock is better than nothing, and gives you an objective measure of time to launch.
Try in Safe mode. That disables most customising software, and any improvement in launch times points the finger at extensions, startup items and other software you have installed.
Create a new user and see if that account has the same problems. This can detect user-specific customisations that might be the cause.
Build an external bootable SSD with a ‘clean’ system, install the app(s) there, start up from it, and see whether it still launches as slowly. You can also try this using a more recent version of macOS, to see whether that helps.
The best way to preserve a record of what happened during a slow launch is to wait until the app is running properly, then perform a sysdiagnose, as that saves much of the log in a logarchive. You can initiate that in the Options … popup menu in Activity Monitor, or by pressing Command-Option-Control Shift-. (period or full stop). That logarchive can be browsed using Ulbow or even Console, but not (yet) LogUI.
I’m also keen to look at log records from one of these much slower launches. If you’re interested in cooperating, please comment below or send me an email (see the About page).
For at least the last couple of years, folk have complained that launching some apps takes forever. It has been common for some to take several seconds of bouncing icon time in the Dock, and in a few cases larger apps can take more than 30 seconds to launch. This has been ascribed to ‘security checks’, with some claiming it’s because of delays in online checks of certificates, others attributing it to XProtect, or something else. This article, based on log extracts generously provided by Kristian, demonstrates what’s really holding up these apps.
App launch in Sonoma & Sequoia
I have written at length in previous articles about what happens during app launch in Sonoma 14.6.1 and Sequoia (links at the end). Although there are significant differences, I concentrate here on 14.6.1, as the crucial log records from Kristian are from Sonoma, and its analysis has been more extensive. Key steps are summarised in the diagram below.
For the sake of simplicity here, I’ll confine this article to launching known apps that aren’t in quarantine, and look in particular at Pages, which isn’t notarized, so will behave slightly differently.
Slow Pages
Launch starts with the click action triggering LaunchServices to start launching the app 16.924 Finder sendAction:
16.927 com.apple.launchservices LAUNCH: Opening <private> with 0 items on behalf of 436 role=e flags=8000001 (null)
and LaunchServices then hands the launch over to RunningBoard 16.941 com.apple.launchservices LAUNCH: _LSLaunchThruRunningboard: com.apple.iWork.Pages / <private>
Security checks start early, with amfid 16.966 amfid Entering OSX path for /Applications/Pages.app/Contents/MacOS/Pages
16.969 amfid SecTrustEvaluateIfNecessary
Then, in accordance with system security policy, a Gatekeeper assessment is started 17.031 com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
17.031 com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>
The security system recognises that the code has already been evaluated, so uses the results from that, and its Gatekeeper scan result returns within 0.01 seconds 17.041 com.apple.syspolicy.exec Code already evaluated, using results.
17.041 com.apple.syspolicy.exec scan returning quickly for code: PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: (null)), (bundle_id: (null))
17.041 com.apple.syspolicy.exec GK evaluateScanResult: 3, PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null)), 0, 0, 1, 0, 9, 2, 1
17.041 com.apple.syspolicy.exec Allowing evaluation due to package installation: PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null))
So around 0.075 seconds after starting the security assessment, and only 0.117 seconds after double-clicking to launch the app, it looks like it has approval to proceed. But that doesn’t take into account the frameworks the app bundle contains. There are 17 of those that need to be evaluated before launch can proceed. Each is reported with distinctive lines like 17.564 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/TSKit.framework/Versions/A/TSKit
17.567 amfid SecTrustEvaluateIfNecessary
the last of which isn’t reported until 20.593 seconds elapsed time, that’s 3.55 seconds after we thought security evaluation was complete, and over 3.6 seconds since the double-click.
From then until Pages opens its preferences with the log entry 20.998 Pages Loading Preferences From User CFPrefsD
is another 0.3 seconds, making a total launch time of just over 4 seconds, of which almost 90% was spend checking frameworks.
Performing the same launch in a VM running macOS 14.7.5 on 4 P cores with 16 GB memory on an M4 Pro host is a little faster, and only takes 2.5 seconds to check its frameworks.
Fast Pages
Launching Pages in a Mac mini M4 Pro running Sequoia 15.4.1 is, as you’d expect, significantly quicker. Tracing corresponding log entries reveals where much of the time is saved.
00.513 Finder sendAction:
00.715 amfid Entering OSX path for /Applications/Pages.app/Contents/MacOS/Pages
00.741 com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
00.741 com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>
Framework checks start with 00.772 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/TSKit.framework/Versions/A/TSKit
00.773 amfid SecKeyVerifySignature
and progress through to 00.843 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/AppleMediaServicesKit.framework/Versions/A/AppleMediaServicesKit
00.843 amfid SecKeyVerifySignature
with Pages opening its preferences at the end 01.087 Pages Loading Preferences From User CFPrefsD
Here, framework checks took a mere 0.07 seconds, and the total time from double-click to preferences was only 0.574 seconds.
Slow Calibre
Pages is an example of an app that completed its security checks without error or problems. Many of the apps that can be slowest to launch have additional problems, as shown in Calibre.
But when its frameworks come up for checking, there’s a problem reported in every one of them 31.614 kernel AMFI: constraint violation /Applications/calibre.app/Contents/Frameworks/calibre-launcher.dylib has entitlements but is not a main binary
31.614 amfid Entering OSX path for /Applications/calibre.app/Contents/Frameworks/calibre-launcher.dylib
31.615 amfid SecTrustEvaluateIfNecessary
AMFI runs a total of 68 checks on those frameworks in the app bundle before reaching the last 35.988 kernel AMFI: constraint violation /Applications/calibre.app/Contents/PlugIns/platforms/libqcocoa.dylib has entitlements but is not a main binary
35.989 amfid Entering OSX path for /Applications/calibre.app/Contents/PlugIns/platforms/libqcocoa.dylib
35.989 amfid SecTrustEvaluateIfNecessary
And preferences are opened 4.635 seconds after the double-click 36.140 calibre Loading Preferences From User CFPrefsD
Workarounds
Many different workarounds have been proposed blindly to tackle a problem that doesn’t appear to have properly diagnosed in the first place. I believe that it is possible, although difficult, to disable AMFI, but that’s like going out, leaving your front door wide open, and telling everyone you meet to go in and help themselves. Without AMFI’s protection, your Mac is a sitting duck.
As these framework checks are occurring outside Gatekeeper, and without XProtect even being thought about, mutilating any other part of your Mac’s security systems isn’t going to achieve anything other than exposing it to increased risk. Some report subjectively that moving apps around can bring relief, but it seems temporary, as ultimately AMFI will get those frameworks whatever you try to do with them. And so it should, if you want your Mac to remain secure.
I’ve seen no evidence that this is a bug, nor that it’s ‘fixed’ in Sequoia, which it isn’t. At first I suspected it might have been exacerbated or unmasked by launching apps using other apps, rather than in the Finder, but that’s not true either. What is abundantly clear from my results above is that a faster Apple silicon Mac does the trick, but please don’t misinterpret that as designing security to encourage users to upgrade to newer models, which simply doesn’t follow.
Conclusions
Significant delays in launching apps can result from security checks of their frameworks.
Known apps that aren’t in quarantine don’t normally undergo online certificate checks or XProtect scans, and normally complete Gatekeeper checks swiftly.
The most likely cause of delayed launching of a known app that isn’t in quarantine is protracted security checks of its frameworks.
Those delays are usually negligible in more recent Apple silicon Macs.
There doesn’t appear to be any lasting workaround to expedite launch.
I’m very grateful to all of you who looked at my little AppexIndexer, and particularly to those who commented and made suggestions. I’m delighted to come back with version 1.0 build 8, which I hope gets closer to what you’ll enjoy using. Its changes include:
Adding support for appex UUIDs. Although the log tends to censor most clues about which appex an entry is referring to, it’s more likely to give its UUID, and armed with AppexIndexer you can use that to identify the appex in question.
Providing a range of four sort orders. These are the SDK or type, the name of its parent app, the UUID, and the appex’s display name. Once you have loaded up the list of appexes, you can switch instantly between these sort orders.
‘Live’ search for UUIDs, explained below.
Tools at the top of each window include the UUID search box at the top right, four radio buttons at the left to switch between sort orders, and checkboxes for the two content options of showing appex and parent paths, and UUIDs. Start by clicking on the Get Appexes button to populate the window, then you can set it up how you want.
To help distinguish the name of parent apps, there’s a ‘parent’ emoji preceding each. You’ll also notice that SDKs shown now omit the standard com.apple. opening, as that is universal.
As before, AppexIndexer supports mixtures of continuous and discontinuous selection. Copy those you want, and they’ll paste as text containing all the available fields, not just those being displayed at the time.
Search was quite a challenge, and my solution is inspired by that explained by Tiago Gomes Pereira in his Create with Swift blog.
SwiftUI Search on Lists and similar is nothing like macOS Find, and is better-suited to displaying those entries that match in a single field rather than in all their text content. With its new sort options, AppexIndexer should be quick and simple to locate appexes by all criteria except UUID. Rather than requiring the user to paste in the UUID they want to find, this ‘live’ search should produce perfect matches when you’ve only typed in a few characters from the target UUID. Those don’t have to be characters from the start, but can be any from within the UUID. For example, to find the appex with a UUID of E1366424-89DD-4CEB-85D8-C8E00928313F, you could start typing in e1366, or c8e00, etc., as you wish. You don’t need to use capitals either.
Typing the first couple of characters should narrow the list down quickly, and by the third or fourth you should have a perfect match. If you want to return to the full list of appexes, select that appex entry and empty the search box by clicking on the X button at its right and just that single entry will be selected in the full list.
If you type in an incorrect character, you’ll be informed that no results could be found.
AppexIndexer 1.0 build 8 is now available from here: appexindexer108
I’m afraid that it still requires Sonoma 14.6 or later, but hope that you find it efficient in use and a good tool for exploring appexes.
App extensions, appexes, have become plentiful and widely used by macOS and third-party software, yet discovering and controlling them is patchy and limited. The most coherent access is in System Settings > General > Login Items & Extensions, where some are gathered in the list of Extensions at the end. Others like Safari extensions are controlled in app settings, while most remain hidden out of sight.
To take stock of all these appexes, I turned to the pluginkit command tool, but the lists it generates are seemingly ordered at random, and so extensive that it would require some serious scripting to make any sense. Instead, it’s easier and more effective to put together a little app to do that. So I present you with AppexIndexer, an exploratory utility that displays key information about all appexes recognised by macOS.
Click on its button to Get Appexes and the window below will fill with well over 400 items, arranged in alphabetical order by the first entry in each line, the SDK or NSExtensionPointIdentifier. Some of those should be fairly obvious: for instance, those appexes listed in Photos Editing settings use the com.apple.photo-editing SDK. In a future article I will explore the relationships between settings categories and SDKs given.
Following that comes the display name of that appex, again ordered alphabetically within that SDK group, which should be the same as that used in System Settings. Next comes the path to that appex, so you can inspect it and its Info.plist for further information.
Many appexes also have a parent, so the last two entries given are the name and path to that parent, when they’re available. One quick way to recognise third-party appexes is to glance down the right side of the list, as they invariably have a familiar parent. Appexes built into macOS are far less likely to have parents (and you can read into that what you like!).
Even in a modest installation, you’re likely to see well over 400 in your Mac’s list, from SpamSieve, an Email Extension with the SDK of com.apple.email.extension, through to QuickLook thumbnail previewers, screensavers and wallpaper. I’ve already explained in general terms what these are and how they work, in this article.
One significant feature missing at this stage is Find/Search, which I’m still working on, for LogUI as well. There’s also additional information given by the pluginkit command tool, and more still that’s available from each appex’s Info.plist file inside its bundle. This initial release lets you save the window’s contents using the Save as RTF button, and you can copy any selected entries and paste them as text. Row selection can be continuous using the Shift key, and discontinuous using Command.
Appexes are not only growing in number, but also becoming increasingly important in macOS. In some cases, they include background processes that could be used maliciously as a method of persistence. Although appexes still need to comply with TCC’s strict rules for accessing protected services and data, they can be an effective way to fly under a user’s radar.
AppexIndexer 1.0 build 5 is now available from here: appindexer105
I’m afraid that it requires macOS Sonoma 14.6 or later, to support the features it uses in SwiftUI.
I hope that you find this information of use. Please let me know what features you’d like the app to support, whether you’d like it to access appex property lists, or other useful data, and how you might want to use a future version. While I’ve got my own ideas, I’m interested in yours, and will try to accommodate them.
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.
Login
