For many, the significance of macOS 16 won’t lie in its additions, but in its potential removals: will it support any Intel Macs, and if so, which? For such a contentious issue, speculation has been disappointingly limited in the run-up to the anticipated announcement at the start of WWDC next month.

I have seen popular but unfounded assertions that Apple supports Macs with its current version of Mac OS for a period of five years. There are different interpretations as to whether that time should run from a model’s date of first release, or when it was discontinued. As many Macs have been offered for sale for over a year, that can make a big difference. As I demonstrated yesterday in my latest brief history, previous transitions haven’t followed any consistent rules.

History

The last 68K Mac was available up to October 1996, but with the transition to PowerPC Macs, Classic Mac OS dropped support for 68K models in October 1998, after only 2 years support.

The last PowerPC Mac was offered by Apple over a brief period between October 2005 and August 2006, but support for it was dropped from Mac OS X after exactly 3 years in August 2009. Even if you start the clock when that G5 model was first released, any five-year rule would have required it to be supported by current Mac OS X for at least another year.

Late Intel Mac models are more complicated, as the last volume sales of Intel iMacs ceased in March 2022, but Apple continued to offer the Intel Mac Pro until June 2023. If Apple did have a five-year rule it would now be committed to maintaining full macOS support for some Intel Macs until the autumn/fall of either 2027 or 2028, even if by then most of them had been replaced by Apple silicon models.

Savings

Other opinions claim that Apple will continue to support just some remaining Intel Macs beyond macOS 16, but others currently running Sequoia will be dropped. The flaw in that is cost, as significant reductions in cost would only be achieved by eliminating all Intel support.

If macOS 16 were to support a single Intel Mac, then there would be little change in its cost. It would still need to consist largely of Universal binaries, there would still need to be kernel extensions to support Intel chipsets and old graphics cards, and most of all those would need to be included in every update to macOS 16 until it ceases security updates in the summer of 2028.

There’s also the question of continuing support for Rosetta 2, together with all its supporting Intel dyld caches; they alone account for around 1 GB of every downloaded update for Apple silicon Macs. Apple has ensured that, unlike Rosetta in transitional versions of Mac OS X, Rosetta 2 can be dropped with Intel support in macOS, as it will remain available in lightweight virtual machines running previous versions of macOS, for the rare cases it’s still needed.

Demand

Like many other business decisions, termination of support is largely driven by marketing and cost. Apple appears to have continued supporting 2019 iMacs as the last Intel models without T2 chips largely because of Enterprise customers who have continued using them in their large fleets. On the other hand, it dropped support for the 2013 Mac Pro, sold for six years up to December 2019, after macOS 12 Monterey was replaced by Ventura in 2022, less than three years after the last of that model was sold.

Decision time

Without knowing the demand from Enterprise users for continuing support of Intel Macs in the next major version of macOS, and the number of Intel Macs that have been upgraded to run Sequoia, it’s anyone’s guess as to what Apple has decided. We won’t know that for a couple of weeks yet, but I’ll guarantee that either way there’ll be disappointment. If macOS 16 doesn’t support any Intel Macs, there’ll be those who are upset because they won’t be able to upgrade, and if it does there’ll be those who are upset at its features that are only available on Apple silicon Macs.

But if it does turn out to be Arm-only, perhaps the biggest losers will be those who hope for OpenCore Legacy Patcher (OCLP) support to enable their cherished Mac to continue running the current macOS. If macOS 16 is no longer Universal, then it will simply never run on any Intel Mac. Apple could see that as a good way to convince those who have been sitting on the fence that it’s time for a new Mac.

Apple pre-releases some of the components for the next major version of macOS in the previous version. For example, when macOS Monterey 12.3 was released on 14 March 2022, a new XProtect.app bundle appeared in /Library/Apple/System/Library/CoreServices, and passed almost unnoticed until it was updated to version 2 in macOS 12.4 on 16 May 2022. By June that was being updated frequently, and is now a significant part of macOS protection against malware.

This article looks back at versions of Sequoia that have brought new components to identify those we might see more of next month, when the first betas of macOS 16 reach developers.

Officially announced

One new feature that Apple has already made available in macOS 15.4 and later is privacy control of access to the pasteboard, described here. It’s likely that a new Pasteboard item will be added to Privacy & Security settings in macOS 16, allowing you a choice between:

• automatically allowing all pasteboard access without notifying the user (as previously);
• always denying all pasteboard access, unless the user explicitly chooses to access the pasteboard for pasting;
• asking the user for permission to grant pasteboard access, although that will automatically be granted when the user explicitly chooses to access the pasteboard for pasting;
• the default, to ask the user for permission when an app rather than the user seeks access to the General pasteboard; all other pasteboards would always allow access.

This appears complicated, and I expect may need simplification during beta-testing, or users could be baffled. Apple’s note details a default setting you can use to preview this behaviour in macOS 15.5 for individual apps in testing.

To celebrate the 40th birthday of its accessibility support, Apple has announced some new features we can expect in macOS 16. Among them is a Magnifier app that will use an iPhone running iOS 19 through Continuity Camera as a live video magnifier. Others include:

• Vehicle Motion Cues, already available in iOS and iPadOS;
• Braille Access, a full-featured braille note-taker;
• Accessibility Reader, to make text easier to read across a wide range of disabilities.

New apps

macOS 15.5 introduces a new app in CoreServices named Apple Diagnostics. This is currently non-functional, but appears to give access to some form of online diagnostic service in the future.

New kernel extensions

Three kernel extensions to watch for in macOS 16 are:

• AppleDisplayManager, introduced in 15.2, and still at version 1.0
• AppleAOP2, introduced in 15.4, and still at version 1.0; AOP is the Always On Processor in Apple silicon Macs;
• AppleProcessorTrace, introduced in 15.4, and still at version 1.0.0.

New public frameworks

Two were added to 15.4, and remain at version 1.0, for CLLogEntry which appears to be part of Core Location, and SecurityUI which hasn’t yet been mentioned anywhere.

New private frameworks

Many new private frameworks have been added by updates to Sequoia. Although most of these remain at their initial build of 1.0, some have seen surprising increases, including:

• AppSystemSettings, introduced in 15.2, now at build 3.3.5
• CryptexKit and CryptexServer, introduced in 15.4, now at build 493.120.7
• DeepVideoProcessingCore, introduced in 15.4, now at build 1.17
• various GameServices, introduced in 15.4, and already at build 819.4.46
• OSEligibility, introduced in 15.2, now at build 181.120.32.

Among the new private frameworks with intriguing names that remain at their initial version are: Bosporus, Morpheus and MorpheusExtensions, an OnDeviceStorage group, and most recently CodableSwiftUI.

Your guess is no doubt better than mine as to what these all do, but I expect some of them will appear in macOS 16, in one guise or another.

With Apple’s annual Worldwide Developers Conference less than a month away, speculation about what’s coming in macOS 16 is starting to warm up. So far that has concentrated on increasing consistency in interfaces across the different platforms, which could mean almost anything. As far as macOS is concerned, that’s largely up to AppKit and SwiftUI, its two major interface libraries.

AppKit remains widely used, and is still the more complete of the two. Descended from the UI framework in NeXTSTEP, it was in the core of Mac OS X at the start, and has been the mainstay for the Finder and Apple’s own apps for the last 25 years. It has a close relative in UIKit for iOS and iPadOS, although they are less comprehensive in their features.

SwiftUI is an interesting experience for the macOS developer, and is currently an archipelago of delights in a sea of disappointment. Some of its features are powerful, but a great deal is still lacking. Support for views and features widely used in modern iOS and iPadOS apps is impressive, and it opens up features such as the List View that I praised recently. But when it comes to essentials that are confined to macOS, such as menus, a great deal of work remains as it comes up to its sixth birthday on 3 June.

This is demonstrated in one of the best tutorials I’ve seen on using SwiftUI for macOS, in this case to develop a Markdown editor, written by Sam Rowlands of Ohanaware. No sooner has he set up a split view to accommodate both the Markdown source and its preview in the same window, than he writes: “The TextEditor in SwiftUI ticks the box of offering a way to edit a large volume of text, but that’s about all it does. Apple have a much more powerful text editor already in the macOS as part of their AppKit framework, so we’re going to wrap that instead.”

This was my experience a while ago when I looked at a range of document formats. Open the Help book in LogUI and what you see there is cast not in SwiftUI, which still doesn’t offer a PDF view, but reaches back to AppKit. While creating a useful Rich Text editor using AppKit is amazingly quick and simple, even plain text editing in SwiftUI is feeble. There are plenty of experts who will advise you “SwiftUI’s text editor is very limited. It doesn’t support much more than entering large amounts of plain text. If you want rich text editing, you will have to use either NSTextView or UITextView.”

These are fundamental features that should by now be easy going for any macOS interface library that’s six years old.

Continuing dependence on both AppKit and SwiftUI presents Apple with the problem of having to update both to reflect changes it intends making to improve interface consistency, then for iOS there’s also UIKit. Not only that, but all three libraries have to integrate and work together.

SwiftUI has undergone constant change over those six years. One of its most substantial changes has been the move from the Observable Object protocol to the Observable macro. Apple describes how to migrate in this article, complete with sample code. But that poses the developer a problem, as adopting the latter is only possible in apps written for macOS 14 or iOS 17 or later. That’s why LogUI requires a minimum of macOS 14.6, as do many of the better SwiftUI apps. Writing SwiftUI apps to support macOS older than Sonoma and Sequoia is thus a serious undertaking, and whatever macOS 16 and its new version of SwiftUI bring, you can be sure they’ll make backward compatibility even more impractical.

Documentation for SwiftUI is also broken. Apple seems to have stopped writing conceptual explanations about ten years ago, and structured guides have been replaced by terse and usually uninformative references to individual functions and other details of the macOS API. The only way to try to gain understanding of SwiftUI is to turn to third-parties, who are more interested in the lucrative iOS market rather than macOS, and think a series of example projects are a substitute for a systematic guide.

If there’s one sound investment for the future that Apple could make from its much-vaunted half trillion dollar investment in the US, it would be to hire a large team of technical authors and catch up with its ten-year backlog of documentation.

Whether you gasp with horror or delight when Apple reveals what’s coming in macOS 16 next month, spare a thought for all the changes that have to take place in AppKit, UIKit and SwiftUI, all the documentation that won’t get written, and how code is going to struggle to be compatible with macOS 16 and Sequoia or earlier. Then for good measure throw in the inevitable load of new bugs. So you still want to beta-test macOS 16?

Lambing dates remain one of life’s great mysteries. Here in the UK, farmers in the north usually lamb earliest, often only just after Christmas when it’s usually bitter cold and snowy up there. Down here in the balmy south, lambs are born three months or more later, typically in April, when they’re often struggling to keep cool in the sunshine. Last week we saw the first of this year’s lambs, and Apple’s Spring OS fest, including Sequoia 15.4.

Size

That update was large, but that isn’t exactly unusual:

• 7 March 2024, Sonoma 14.4 was 3.6 GB (Apple silicon) with 64 vulnerabilities fixed, “the most substantial update of this cycle so far”;
• 27 March 2023, Ventura 13.3 was 4.5 GB with 49 vulnerabilities fixed, being “substantial, and brings many improvements and fixes”;
• 14 March 2022, Monterey 12.3 was 5.3 GB with 45 vulnerabilities fixed, being “very substantial, introducing major new features like Universal Control and Spatial Audio, changing several bundled apps, and fixing many bugs”;
• 26 April 2021, Big Sur 11.3 was 6.62 GB with over 50 vulnerabilities fixed, “the largest update to macOS since Mojave, and quite possibly the largest ever”.

(Figures and quotations from links here.)

Although the 15.4 update wasn’t quite as large as 11.3, at 6.2 GB for Apple silicon, it has comfortably surpassed it in the number of vulnerabilities fixed, 131 in all, and came close to the size of the 15.0 upgrade at 6.6 GB. What’s most disappointing is that, while the first release of Sequoia merited long and detailed accounts of much of what had changed, for 15.4 there’s precious little information beyond its lengthy security release notes.

A stroll through the version numbers of its bundled apps and /System/Library confirms the extent of changes. There was no point in my trying to compile an article listing them, as it might have been briefer to report what hasn’t changed. What’s more to the point is what’s new in 15.4, what are its Spring lambs?

Novelties

Among the new kernel extensions is the first version of AppleProcessorTrace, and there’s a brace to support hardware in Apple silicon chips including a T6020 and T8103 for PCIe, and a T6032. Those appear to be for M2 Pro, M1 and M3 Ultra chips, respectively. There are two new public frameworks, one named CLLogEntry that is presumably for Core Location log entries, the other tantalisingly named SecurityUI. Neither seems to align to anything in Apple’s developer documentation, so might be preparing the ground for what we’ll hear about in early June at WWDC, when the lambs have grown a bit.

I keep a track of the total number of bundles in several of the folders in /System/Library. Since the release of Sequoia 15.0, that containing Private Frameworks has grown from 4,255 to 4,398. Because of their layout, this total overestimates the real change in numbers, and that probably represents a true growth of around 70 Private Frameworks in Sequoia so far.

These Private Frameworks contain code features used privately by Apple’s apps, but not exposed to third-party developers. Although much is of little or no use or advantage, they also contain much that supports changing features in macOS. Using Private Frameworks is a sure way to madness, and something explicitly forbidden in the App Store, but, like the unaffordable car or boat we like to gloat at, there’s no harm in wondering what they will bring in the future.

The list of new Private Frameworks in Sequoia 15.4 is long, and includes: AUSettings, Bosporus, ComputationalGraph, CoreAudioOrchestration, CryptexKit, CryptexServer, DailyBriefing, DeepVideoProcessingCore, Dyld, ExclaveFDRDecode, FPFS, FindMyPairing, various GameServices, GenerativePlaygroundUI, MCCFoundation, MLIR_ML, MobileAssetExclaveServices, Morpheus, MorpheusExtensions, an OnDeviceStorage group, OpenAPIRuntimeInternal, OpenAPIURLSessionInternal, PIRGeoProtos, RapidResourceDelivery, SecureVoiceTriggerAssets, SecurityUICore, and VideoEffect.

While many of those names can inform speculation about what we’re about to see in macOS 16, three merit a little more decoding.

Cryptexes are secure disk images loaded during boot that currently deliver Safari and its supporting components, and the dynamic libraries for all those frameworks, public and private. Accessing them from user-level code isn’t something you’d expect to happen, so those two Private Frameworks, CryptexKit and CryptexServer, hint at further expansion in their use and support.

Bosporus

The Bosporus Strait in Turkey connects the Black Sea to the Sea of Marmara, thence through the Dardanelles to the eastern Mediterranean. It’s a busy thoroughfare formerly used heavily by ships carrying grain and other bulk cargoes from Ukraine and Russia.

View of Constantinople and the Bosphorus (1856) is one of many views that Ivan Aivazovsky made of this great city, which he visited on many occasions. The artist kept his studio in Crimea, on the opposite (northern) shore of the Black Sea.

Morpheus

Morpheus is the god of dreams, whose name is the source of the word morphine. Although usually distinct from Hypnos, god of sleep, he’s sometimes associated with Nyx, goddess of the night, most famously in reference to a passage from Virgil’s Aeneid, painted below by Evelyn De Morgan.

She pairs Nyx with Morpheus in her Night and Sleep, from 1878. The further figure is a young woman wearing long red robes, her eyes closed, clutching a large brown cloak with her right hand, and most likely Nyx. Her left arm is intertwined with a young man’s right arm. He also has his eyes closed, and is most probably Morpheus. He clutches a large bunch of poppies to his chest with his left arm, while his right scatters them, so they fall to the ground below.

Virgil’s lines in Book 4, line 486 read:
hinc mihi Massylae gentis monstrata sacerdos,
Hesperidum templi custos, epulasque draconi
quae dabat et sacros servabat in arbore ramos,
spargens umida mella soporiferumque papaver.
haec se carminibus promittit solvere mentes
quas velit, ast aliis duras immittere curas…

Translated (at Perseus at Tufts University), this reads:
From thence is come
a witch, a priestess, a Numidian crone,
who guards the shrine of the Hesperides
and feeds the dragon; she protects the fruit
of that enchanting tree, and scatters there
her slumb’rous poppies mixed with honey-dew.
Her spells and magic promise to set free
what hearts she will, or visit cruel woes
on men afar.

Spargens umida mella soporiferumque papaver, one of Virgil’s greatest lines, is conventionally translated as “scattering moist honey and sleep-inducing poppy”, and describes well the effects of the opiate drugs derived from opium poppies, including morphine.

I look forward to watching the lambs grow up through the coming summer, and learning about those lambs that came with Sequoia 15.4 at WWDC.