Unlike Apple’s bundled apps in macOS, the great majority of third-party software needs to run on more than just the latest version of macOS. This is a challenge when there’s a major redesign of the interface, as there is in macOS Tahoe. While OS 26 may bring greater consistency across platforms, it’s also important to developers and users that it doesn’t sacrifice consistency between, say, Sequoia and Tahoe.

As I showed recently in my simple little utility DropSum, at times the appearance of windows can be very different between macOS 15 Sequoia and 26 Tahoe. DropSum uses AppKit rather than SwiftUI, and is a little unusual in applying colour to its window. This is used in a popular mechanism to indicate when that window is ready to receive a file being held over it, by changing the view colour from systemOrange to systemGreen. As that coloured view extends over the controls in the window, I have had to be careful to ensure those controls remain readable in both appearance modes, with the Reduce transparency and Increase contrast settings in Accessibility settings, and across recent versions of macOS. That hasn’t proved easy, so what you see below appears to be the best compromise I can achieve. DropSum doesn’t alter its settings or behaviour between different versions of macOS, instead relies on the host API’s appearance modes and Accessibility settings.

Although I have confirmed the observations below on individual systems, to make comparison easier here each screenshot shows two DropSum windows. The upper is running in a Tahoe beta 7 VM (where the window title is left-aligned), and the lower in Sequoia 15.6.1 on the host (where the window title is centred).

Light mode

In both light appearance modes, all boxed text is displayed in black on a white background, making their contents and controls clear. There are marked differences in the hues seen, though, with both systemOrange and systemIndigo (chosen for better contrast in labels) being more intense in Tahoe than Sequoia. As expected, Tahoe’s controls are slightly larger, and the corners of all four text boxes are rounded rather than square.

Reducing transparency made little difference in either rendering, merely whitening the window title bar.

Increasing contrast changes the intensity of some colours. In Sequoia, systemOrange is lightened, and in both windows the traffic light buttons at the top left, and the Clear button, are darkened. Otherwise the most obvious effect is the outlining of all components, including each of the controls.

Apps built to support macOS 26 thus appear consistent between macOS 15 and 26 when used in light mode.

Dark mode

Most apparent here are the contrasting effects of dark mode on the background of the four text boxes. In Sequoia, their background is the systemOrange of the coloured view, but in Tahoe it’s black. The latter makes the text contents more readable, while unselected text in Sequoia is more difficult to read.

Increasing contrast has different effects on colours when in dark mode. In Sequoia all colours including the systemOrange view become slightly lighter, whereas in Tahoe the contrast of some is enhanced, with black becoming blacker and white whiter, but there’s little discernible change in systemOrange, which remains significantly more intense than in Sequoia. systemIndigo is rendered lighter though, making it more difficult to read against the systemOrange background.

Reduce transparency

Apple describes this effect as replacing “the transparent effect used on some backgrounds in macOS with a solid background to improve contrast and readability.” In both Sequoia and Tahoe, and in both appearance modes, the only effect observed is a lightening of the window title bar, as the rest of the window is already opaque.

Increase contrast

Apple describes this as increasing “the contrast of items on the screen (such as borders around buttons or boxes) without changing the contrast of the screen itself.” Although the borders are the most prominent effect in both versions of macOS and both appearance modes, there are also colour changes that aren’t consistent between Sequoia and Tahoe.

Conclusions

• Appearance modes in Tahoe exhibit different behaviours from those in Sequoia, most markedly in dark mode. In this example, Tahoe has the effect of enhancing readability in dark mode.
• Colour rendering of systemOrange also differs between Tahoe and Sequoia.
• Reduce transparency has little effect other than making transparent views opaque.
• Increase contrast primarily adds black (light mode) or white (dark mode) borders to controls, but its small colour changes, as seen here in Tahoe, may impair readability.
• Designing an interface that behaves consistently in both macOS Tahoe and older versions of macOS is a challenge that may not always work out. Developers need to assess their app’s human interface thoroughly in multiple macOS, appearance modes and Accessibility settings.

DropSum is my simple drag-and-drop utility for checking MD5 and SHA256 hashes, and using them to compare pairs of files to see if they’re identical.

This new version brings two changes:

• Text entered in its two text boxes, where you paste hashes, is now cleaned of any spaces and hyphens, and set in lower case, before being used as a hash, although it’s not altered in the text box. This should save you having to edit what you paste there. Thanks to Panda for requesting that.
• I have tried to improve readability when in dark mode in Sequoia and earlier. Thanks to EcleX for requesting this.

That said, the window’s appearance is a compromise between what looks best in Sequoia, and that in Tahoe. To see what I mean, here’s the same app, in its new version 1.2, in two versions of macOS, both in dark mode with Reduce Transparency enabled.

In macOS Tahoe there’s strong contrast throughout, and all text is readable, as it is in light mode.

Yet in macOS Sequoia, white text in unselected text boxes is shown against its orange background, rather than grey or black.

I have a feeling we’re in for an autumn of similar visual discrepancies appearing in other apps, whether or not they’ve been built for compatibility with Tahoe.

DropSum 1.2 for Big Sur and later, including Tahoe, is now available from here: dropsum12
from Downloads above, and from its Product Page.

Its MD5 hash is 9370f006d65eb3f6f65ab97dc78ce345
and SHA256 is f898b580138dc05d273c8b7f16321ad6d6754d76ecabf1c49fcac1d32bc156e6

Enjoy!

As we near the end of Tahoe’s incubation period, and Apple’s engineers code its last fixes and tweaks ready for its launch in just a few weeks, I’d like to reflect on what macOS 26 has to offer beyond its marketing headlines.

While there are several worthwhile new features such as the Phone app, Magnifier, and live translation, there’s nothing to compare with the fundamental changes in recent versions of macOS that brought the SSV, Shortcuts, System Settings and Apple Intelligence. Instead Tahoe is overwhelmingly about its human interface.

Every new design of the Mac’s operating systems that I can recall has elicited outcry from many. Understandably, the majority almost invariably want constancy, the same Finder and app icons that we’ve become so familiar with. It’s only human. It’s also a sure route to what others will condemn as stale, as it hasn’t been refreshed for so many years.

Personally, I don’t like to see a design on my Mac. If I notice it, then it’s a distraction. I’d much prefer to have an interface as clean as the whistles of the late Classic Mac OS period: lean, purposeful and lacking in visual trickery or frippery. But I accept that, without all the adornments and animations, many today would wonder why their Mac needed a GPU. I confess that I was never a fan of the original Aqua interface either. Given that its declared goal was to “incorporate colour, depth, translucence, and complex textures into a visually appealing interface”, I wonder whether much the same could be said of Tahoe.

Perhaps the most striking feature of this redesign is its lack of contrast between elements and tools in window controls and their contents, whether its appearance is set to light or dark mode, or one of its new in-between variants. You can see this clearly in most screenshots of Tahoe, such as those posted by Apple, and as far as I can see it hasn’t improved during beta-testing. This is also universal, and isn’t confined to apps using the more novel SwiftUI, although I have to keep pinching my thigh to remind myself that SwiftUI is now six years old, only two years younger than APFS. The contrast in stability and maturity between the two couldn’t be greater.

You can of course ‘improve’ contrast by enabling Reduce Transparency in Accessibility settings, but in doing so you lose most if not all of Tahoe’s Liquid Glass effects, as they depend on the transparency you’ve just turned off.

Transparency is a good example of design being given priority over readability or content. Because the appearance of the upper layer containing controls or content depends on what is underneath, it’s down to chance whether the greyed text you’re struggling to read happens to be over a background that further reduces its contrast. In the worst case, you could find yourself having to move a window so you can read part of it clearly, not a sign of a good human interface.

My other major concern with Tahoe’s new look is that it seems not to recognise the differences between Macs, iPads and iPhones, in terms of displays, input controls, and apps. Rather than sameness, I’d much rather have consistency that recognises the difference between manipulating Xcode’s compound windows containing dense structured text on a 27-inch display, and checking a family photo filling the 6.1-inch display of an iPhone.

One of my favourite controls in macOS is the Combo Box, a versatile and elegant hybrid of the popup/dropdown/pulldown menu/button and a text entry box. I can’t recall seeing one used in iOS, as it would be clumsy and inappropriate. It’s well supported for macOS in AppKit but hasn’t yet been implemented in SwiftUI. If controls are going to be common across all Apple’s operating systems, then macOS is about to lose one of its best.

It seemed only appropriate that, in the weeks before Apple releases OS 26 across Macs and devices, Tim Cook should go to the White House to pay its corporate tribute in a block of materialised Liquid Glass mounted on pure bling. But the image that I keep thinking of in fear, is that of Elon Musk demonstrating the resilience of his Cybertruck’s window by throwing a metal ball at it, in November 2019. I just hope Tahoe’s Liquid Glass doesn’t go the same way.

We’re now into August, Apple has released the last substantial updates to macOS before the arrival of Tahoe, so where does macOS stand now?

macOS Sequoia has just had its last scheduled update to 15.6 before it’s expected to enter the first of its two years of security-only updates. The main benefits of this update are an important fix to restoring Macs in DFU mode using either the Finder or Apple Configurator, and its long list of security updates, 81 vulnerabilities in total. If you’re already running Sequoia, it’s an important update.

Sequoia is fully supported on the following Macs:

• iMac 2019, all T2 iMacs including iMac Pro from 2017
• MacBook Air 2020 and later, but not 2018 or 2019
• MacBook Pro 2018 and later (all T2 models)
• Mac mini 2018 and later
• Mac Pro 2019 and later
• all Apple silicon Macs.

macOS Sonoma is now entering its second and final year of security-only updates, and in the latest to 14.7.7 has around 50 vulnerabilities fixed. Although that’s a lot less than in 15.6, those are still important if you’re staying with Sonoma for the time being.

Sonoma is fully supported on the following Macs:

• iMac 2019
• all Intel Macs with T2 chips
• all Apple silicon Macs.

macOS Ventura has probably had the last of its security updates, although in the past Apple has sometimes released one more update in the autumn/fall. Its latest update to 13.7.7 has around 41 vulnerabilities fixed, making it essential if your Mac can’t be upgraded to Sonoma or later. If your Mac is supported by Sonoma, now is the time to plan upgrading it so that it can continue receiving security updates from September.

Tahoe

macOS Tahoe has now entered the public phase of its beta-testing, with the fourth version provided to developers. While much of the debate surrounds its Liquid Glass and new look, it does bring new features such as a Phone app to Macs. So far it appears internally stable and doesn’t look likely to be delayed for major bugs to be wrangled.

Tahoe is fully supported on the following Macs:

• MacBook Pro 16-inch 2019, and 13-inch 2020 with four Thunderbolt ports,
• iMac 2020,
• Mac Pro 2019,
• all Apple silicon Macs.

Although the first couple of versions of Tahoe presented themselves to older apps and scripts as macOS 16, since beta 3 it has been thoroughly macOS 26 regardless of how it’s asked. As this hasn’t been mentioned in Apple’s release notes, it’s unclear what it will do in the final release. If you have apps or scripts that could break when they discover the version of macOS running is 26, now is the time to send Apple feedback to make your case for it to report as version 16.

Older Macs

Open Core Legacy Patcher, OCLP, is being updated in the hope that it will be able to run macOS Tahoe on at least some unsupported models, although that probably won’t be available until the end of this year. You can follow progress here, where you’ll see some of the challenges its developers are facing. Another site worth watching is Mr. Macintosh on YouTube.

Next stop, probably in September, should be:

• macOS 26.0 Tahoe
• macOS 15.7 Sequoia
• macOS 14.8 Sonoma

if Apple remains consistent with previous numbering. Farewell to Ventura, old friend!

This is the last batch of ‘simple’ updates to my free apps to bring them up to the expectations of macOS 26 Tahoe. With them comes a minor update to my log browser LogUI, which is recommended for all using Tahoe, as it fixes an annoying if fundamentally cosmetic bug.

Preparing these updates for release was a little troublesome, as I attempted this using developer beta 3 of Tahoe and Xcode 26 beta 3. Little did I realise when I got all four rebuilt, tested and notarized, that this combination had stripped their shiny new Tahoe-compliant app icons. That made these new versions unusable in Sequoia and earlier, as they each displayed there with the generic app icon, despite working fine in Tahoe.

Eventually I discovered that I could build fully functional versions using Xcode 26 beta 2 in Sequoia 15.5, so that’s how they have been produced.

File integrity

Five years ago I build a suite of two apps and a command tool to enable checking the integrity of file data wherever it might be stored. This uses SHA256 hashes stored with each checked file as an extended attribute. At that time, the only alternative saved hashes to a file in the enclosing folder, which I considered to be suboptimal, as it required additional maintenance whenever files were moved or copied to another location. It made more sense to ensure that the hash travels with the file whose data integrity it verifies.

The three are Fintch, intended for use with single files and small collections, Dintch, for larger directories or whole volumes, and cintch, a command tool ideal for calling from your own scripts. As the latter has no interface beyond its options, it continues to work fine in macOS 26.

Since then other products have recognised the benefits of saving hashes as extended attributes, although some may now use SHA512 rather than SHA256 hashes. What may not be apparent is the disadvantage of that choice.

Checking the integrity of thousands of files and hundreds of GB of data is computationally intensive and takes a lot of time, even on fast M4 chips. It’s therefore essential to make that as efficient as possible. Although checksums would be much quicker than SHA256 hashes, they aren’t reliable enough to detect some changes in data. SHA algorithms have the valuable property of amplifying even small differences in data: changing a single bit in a 10 GB file results in a huge change in its SHA256 hash.

At the same time, the chances of ‘collisions’, in which two different files share the same hash, are extremely low. For SHA256, the probability that two arbitrary byte sequences share the same hash is one in 2^256, roughly one in 1.2 x 10^77. Using SHA512 changes that to one in 2^512, which is even more remote.

However, there ain’t no such thing as a free lunch, as going from SHA256 to SHA512 brings a substantial increase in the computational burden. When run on a Mac mini M4 Pro, using its internal SSD, SHA256 hashes are computed from files on disk at a speed of around 3 GB/s, but that falls to 1.8 GB/s when using SHA512 hashes instead.

Dintch provides two controls to optimise its performance: you can tune the size of its buffer to cope best with the combination of CPU and storage, and you can set it to run at one of three different QoS values. At its highest QoS, it will run preferentially on Apple silicon P cores for a best speed of 3 GB/s, while run at its lowest QoS it will be confined to the E cores for best energy economy, and a speed of around 0.6 GB/s for running long jobs unobtrusively in the background.

The two apps and cintch are mutually compatible, and with their earlier versions going back to macOS El Capitan. In more recent versions of macOS they use Apple’s CryptoKit for optimum performance.

Dintch version 1.8 is now available from here: dintch18
Fintch version 1.4 is now available from here: fintch14
and from their Product Page, from where you can also download cintch. Although they do use the auto-update mechanism, I fear that changes in WordPress locations may not allow this to work with earlier versions.

Compression/decompression

Although I recommend Keka as a general compression and decompression utility, I also have a simple little app that I use with folders and files I transfer using FileVault. This only uses AppleArchive LZFSE, and strips any quarantine extended attributes when decompressing. It’s one of my testbeds for examining core allocation in Apple silicon Macs, so has extensive controls over QoS and performance, and offers manual settings as well as three presets.

Cormorant version 1.6 is now available from here: cormorant16
and from its Product Page. Although it does use the auto-update mechanism, I fear that changes in WordPress locations may not allow this to work with version 1.5 and earlier.

LogUI

Those using this new lightweight log browser in Tahoe will have discovered that, despite SwiftUI automatically laying out its controls, their changed sizes in Tahoe makes a mess of the seconds setting for times. This new version corrects that, and should be easier to use.

LogUI version 1 build 70 is now available from here: logui170

There will now be a pause in updates for macOS Tahoe until Apple has restored backward compatibility of app icons, hopefully in the next beta-releases.

If you’re building apps using Xcode 26 beta on macOS 26 beta, you should beware of the combination of their third betas. If you’re unlucky like me, you’ll discover those shiny new app icons generated by Icon Composer no longer work on any older version of macOS. This is mentioned in the Xcode 26 b3 release notes, and the workaround given is “none”.

Problem

I’ve built over 20 apps now using Icon Composer’s new icon files, with Xcode 26 b2 on macOS 26 b2. All look good in Tahoe and in previous versions of macOS, at least in Sonoma and Sequoia.

Today I built my first apps using icon files already generated by Icon Composer, but this time with Xcode 26 b3 on macOS 26 b3. In every case, I got a build warning that Xcode “failed to generate flattened icon stack for icon named…”. Although the app icon displays fine in macOS 26 b3, when moved across to Sequoia there’s just a generic icon. Inspecting the app bundle reveals that there’s no icns file inside. The Xcode warning implied this might be related to CoreSVG.

Workaround

I next tried building the same projects using Xcode 26 b2 on macOS 26 b3, but that made no difference at all.

What does appear to be effective is to build in Xcode 26 b2 on macOS 15.5. So far each of the apps I’m trying to build has then worked fine in both Tahoe and Sequoia, and that magic icns file is back.

I wish you success.

This week’s batch of app updates includes two for working with metadata, a fun obfuscator of text, and my in-house performance test for storage. In each case, they have been given a new app icon that should display well in all versions of macOS from Big Sur to Tahoe. Their windows have been overhauled to accommodate Tahoe’s larger controls, and they have been rebuilt.

Spotlight and metadata

Metamer gives access to 16 of the most useful types of metadata that can be saved as extended attributes to any file, and others that are text-based if you wish. It has a built-in scratchpad you can use to assemble groups of keywords, for instance. It thus gives access to a wide range of metadata that you can use in Spotlight search.

Metamer version 1.6 is now available from here: metamer16
from its Product Page, and via its auto-update mechanism.

To accompany that is Spotcord, which scans folders to build vocabularies of keyword metadata (kMDItemKeywords in Spotlight’s terms), subjects and other specified types. Although it can look for those Spotlight derives from image analysis, experience shows that few are likely to be accessible outside Spotlight itself. This is the first release version of Spotcord, which had lingered in beta far too long.

Spotcord version 1.0 is now available from here: spotcord10
and from its Product Page. It doesn’t use the auto-update mechanism, though.

Text obfuscation

Dystextia is a bit of fun using Unicode lookalike characters to obfuscate Roman text. For example, it will convert this line into
Dуstехtіа іs а bіt оf fun usіng Unісоdе lооkаlіkе сhаrасtеrs tо оbfusсаtе Rоmаn tехt.
or even
Dу𝚜𝚝ех𝚝іа і𝚜 а bі𝚝 о𝚏 𝚏𝚞𝚗 𝚞𝚜і𝚗ɡ U𝚗ісоⅾе ⅼоо𝚔аⅼі𝚔е с𝚑а𝚛ас𝚝е𝚛𝚜 𝚝о оb𝚏𝚞𝚜са𝚝е Rо𝚖а𝚗 𝚝ех𝚝․
if you prefer. This is easy to reverse using AI, but throws find and spellchecking out of the window.

Dystextia 1.9 is now available from here: dystextia19
from its Product Page, and via its auto-update mechanism.

Storage performance testing

In contrast, today’s last update is the app I use to measure read and write speeds of storage, from internal SSDs to external hard disks and NAS systems. This offers a flexible range of test methods, all based on the same API calls used by apps to ensure they represent real-world performance. This comes with a detailed Help book that explains how testing and data analysis are performed.

Stibium version 1.2 is now available from here: stibium12
from its Product Page, and via its auto-update mechanism.

Coming next

My next batch of updates concludes the straightforward ones, and will bring Dintch, Fintch and Cormorant.

I currently don’t intend updating any of my command tools like blowhole, as they appear to continue working fine in Tahoe.

I have started work on updates to Unhidden, SilentKnight/Skint, and the Viable family of virtualisers. Each needs more work before they will work properly with Tahoe, in the case of SilentKnight/Skint a complete new version designed for future macOS.

I currently don’t intend updating ArchiChect, Taccy, Signet, Scrub, LockRattler or the command tool silnite for Tahoe, as they’ve now been superseded or outdated. If you want one of those reinstated, please let me know.

Much of the data handled on and off our Macs and devices is protected by encryption. That has been designed to ensure encryption can’t be broken in a reasonable amount of time using current and future computing resources. Using conventional computers, for instance, it would take a great many years to break data encrypted using 256-bit AES, so in practice this has been considered to fully secure, for the past.

Threat

For the last 50 years or so, researchers have been working on quantum computers that could radically change that. Instead of using normal binary bits with values of 0 and 1, those use qubits measured in terms of probability, making them non-deterministic. That changes the way they work, and some tough problems in the binary world can be speeded up so much that, given a suitable quantum computer, they could compute in far shorter times. This has already been applied to greatly reduce search times in big data, and has the potential to break most recent forms of encryption.

Progress in making suitably powerful quantum computers to be able to decrypt data encrypted using classical techniques has been slow, but we’re now reaching the stage where that’s likely to be feasible in the next year or three. Now is the time to start deploying more advanced forms of encryption to protect our data from the imminent future.

Data in transit

In February last year, Apple announced that iMessage was transitioning to the use of protocols that are quantum-secure, and those were introduced the following month in macOS 14.4, iOS and iPadOS 17.4 and watchOS 10.4. When macOS 26 Tahoe and its matching OSes are released in a couple of months, they bring further important steps towards fully secure encryption, in encrypted network connections using quantum-secure mechanisms in TLS 1.3.

Classical encryption is at its most vulnerable when encryption keys are exchanged over the Internet, and public key systems can be completely broken by quantum methods. Thus, Apple’s first changes are being made to protect data in transit, where it can be intercepted and stored for later decryption using a quantum computer. Securing iMessage is an important start, and the new features in Tahoe and its sisters extend similarly improved protection to other data transfers.

Apple’s operating systems provide support for encryption and related techniques in CryptoKit, making quantum-secure methods available to third-party apps as well. For OS 26, CryptoKit gains Module-Lattice based key encapsulation or ML-KEM, part of the FIPS 203 primary standard for general encryption. Signatures gain the Module-Lattice based digital signature algorithm or ML-DSA, part of FIPS 204.

Data in storage

Whereas public key cryptography systems can be completely broken by quantum attacks, the news for symmetric key schemes such as those used in FileVault and APFS encryption is considerably better. Although quantum computers will be able to break classical techniques more quickly, that should prove neither quick nor easy.

In Intel Macs with T2 chips and Apple silicon Macs, encryption keys are protected by the Secure Enclave, never leave it, and are never exposed to the main CPU. Attempts to gain access through the Secure Enclave are subject to robust defences: for example, the Secure Enclave Processor allows only 5 attempts to enter a Mac’s password before it increases the time interval enforced between entry attempts, and after 30 unsuccessful attempts no more are allowed at all, and the Mac has to be fully wiped and reset.

Trying to remove internal storage is designed to frustrate the attacker. Although internal storage is referred to as an SSD, the storage used isn’t complete in the sense that you couldn’t remove it and install it in another computer, and most of its disk controller functionality is performed by sections in the host chip, including its Secure Enclave. Even models like the Mac Studio that have socketed storage don’t make this easy: remove its special SSD module and it won’t work in another Studio unless it has been completely wiped and reset, destroying its keys and contents.

Apple’s strategy for the protection of encrypted internal storage is thus intended to block access at every level, so that post-quantum brute-force decryption would have little if any impact should it become available in a few years. The standard encryption method used, AES-256 in XTS mode, may need to be revised as quantum decryption becomes more feasible, and Apple is now recommending that doubling the key size should be sufficient to make encryption suitably resistant to forcing with a quantum computer.

Summary

• Future quantum computers will be able to break some classical encryption methods.
• Public key methods used to protect data in transit across the Internet are the most vulnerable to quantum attack.
• macOS 14.4 and iOS 17.4 have started progressively replacing iMessage protection to make it resistant to quantum attack.
• OS 26 will extend that protection to cover connections over TLS 1.3, where supported by servers.
• Protection already provided to stored data, such as FileVault, is considered to remain robust.
• Encryption of static data can be made more robust to quantum cryptography by doubling key size from 256 to 512 bits.

Resources

Quantum computing (Wikipedia)
Post-quantum cryptography (Wikipedia)
FIPS 203-206 (NIST standards)
Securing iMessage with PQ3 (Apple)
macOS Tahoe TLS 1.3 support (Apple)
Cathie Yun presentation Get ahead with quantum-secure cryptography, WWDC 2025 (via Apple Developer app etc.)
CryptoKit for developers (Apple)

Some time in the next week or two, Apple is expected to release its first public beta of macOS 26 Tahoe. This article is intended to help you decide whether to risk or resist that tempting offer.

As with Sequoia last year, to install the public beta-release you no longer have to download a special enabler from a closed website. This is now done through an extra option in Software Update. All you need to do is sign up here, and once the public beta is released you should see it offered in Software Update, when your Mac is signed in using the Apple ID you signed up with. There’s also an option there that caters for those who wish to use a different Apple ID for betas.

Can your Mac run Tahoe?

Tahoe is officially supported on just four models of Intel Macs with T2 chips, and all Apple silicon Macs. It’s expected that at least some older Macs will be able to run Tahoe using OCLP, but won’t do so until that has been updated later this year.

The full list of supported models is:

• MacBook Pro 16-inch 2019, and 13-inch 2020 with four Thunderbolt ports,
• iMac 2020,
• Mac Pro 2019,
• all Apple silicon Macs.

As in Sequoia, Apple Intelligence is only available on Apple silicon models.

What do you get in the beta?

Apple’s official account of new features is fairly detailed. I have drawn attention to a new disk image format in this article.

Changes are dominated by Liquid Glass and other features in its new interface, which is still evolving. This brings changes in app icons, and may require further work to adjust interface elements to accommodate its changes.

Other significant new features include:

• Magnifier app using a connected camera;
• Journal app now available in macOS;
• Phone app available in macOS;
• Metal version 4.

Apple provides extensive release notes for betas.

Although Tahoe is thoroughly macOS version 26, you will discover that it can also pose as version 16, as explained here.

Can you lose that Mac?

The next question you should ask is whether you could afford to completely lose your Mac for a while, as a result of a problem with the beta. Although that’s most unlikely to happen, it’s a risk you’ve got to be prepared for when you install any pre-release version of macOS.

Never, under any circumstances, install a beta of macOS on any Mac you rely on for production. Betas invariably involve firmware updates, so even if you install the beta on an external disk, it will change your Mac’s firmware. Undoing that is hard enough for an Apple silicon model, and it’s not possible on Intel Macs. All you can then do is wait for another beta, or maybe the final release in the autumn/fall, which should update the firmware to something more compatible.

Betas also normally come with updated versions of key components such as iCloud, the APFS file system and Time Machine. Consider carefully what havoc they could produce if there’s a bug affecting other storage used by that Mac, and its backups.

If the worst comes to the worst, you could end up having to restore that Mac to an older version of macOS. Apple explains how to do that, and you should read that account carefully before making any decision. If you’re thinking of installing betas on an Apple silicon model, beware that process requires another Mac running Apple Configurator 2, or macOS Sonoma or later, and restoring it in DFU mode.

Internal or external SSD?

One way to reduce the risk posed by beta versions of macOS is to install them on external storage. While that can enforce some degree of separation and protection, it still means that firmware is updated, and still brings significant risk of disaster. Don’t try this with a production Mac, even from an external disk.

If you’re going to install the beta on an external disk, you’ll need to be comfortable with the procedure for Apple silicon Macs. Although it does become straightforward with practice, some seem unable to get it to work at all. Intel Macs are far simpler, of course, although one important catch with T2 models is that you have to downgrade their security using Startup Security Utility in Recovery mode, if you haven’t already done so, or they can’t boot from an external disk. This article steps through the procedure.

Multiple systems on the same disk

You can also install multiple boot volume groups on the same disk, letting you choose which version of macOS to start up from. This provides even less separation or protection than installing them on separate disks, so should never be attempted on any production Mac.

Apple recommends that you do this into separate boot volume groups within the same APFS container, which has the great advantage that they share the same free space within that container. However, there are times when that can work against you, and you may prefer to opt for separate containers instead. The choice is yours.

Virtual machine

Some consider the best way of keeping out of trouble when running beta versions of macOS is to install them into a Virtual Machine (VM). This can’t alter the firmware of the Mac hosting the VM, and that alone makes it far safer. This is simplest on Apple silicon Macs, with their extensive built-in support for running virtualised macOS. Use any of the virtualisers, including Parallels, UTM, and my own Viable. Full instructions for Viable are given here, with additional information for Tahoe here.

iCloud

Some betas bring substantial changes to iCloud, and in the past that has caused lasting havoc to accounts and on iCloud storage. I’m not aware of any particular issues that have been reported in this respect with Tahoe betas, but many testers prefer to use a different iCloud account for Macs when running beta-releases of macOS.

Kernel panics

If you do decide to install the Tahoe beta, or have already done so, I have a big favour to ask on behalf of tens of millions of users, and most of Apple’s engineers. By all means take a good look at its new features, and give Apple plenty of feedback on what you think of them. But please pay careful attention to the basics, exercising your Mac with peripherals such as external displays and hubs. Should you discover problems, please work with Apple to ensure that it knows what they are. If you can, test out features such as Time Machine (being careful not to put your existing backups at risk), which seldom get much attention from beta-testers.

In particular, send Feedback reports on any kernel panic your Mac encounters when running a beta. The normal system report, sent after your Mac has restarted, is helpful, but further details are much better still. Even betas should never suffer kernel panics; if yours does, please help Apple’s engineers fix that problem before Tahoe is released.

For those who do beta-test Tahoe, I wish us success, and hope you enjoy testing, and helping Apple make Tahoe even better for all of us.

In this last batch of updates to my apps for the next few weeks, there are four more popular tools, covering Unicode normalisation, appexes, logs, and document versions.

Unicode normalisation

Perhaps the earliest problem with APFS was its lack of Unicode normalisation for file and folder names. This has been a standard way to address accented and other characters that appear identical but have different codes. Apple addressed that, first in providing a normalisation layer on top, then by incorporating it into APFS. However, it can still prove a problem, both within apps and when working with other file systems. Apfelstrudel is a simple app that reveals any potential problems with normalisation, and helps you use the form most appropriate. Version 1.6 has an overhauled interface, and has been rebuilt with a new app icon ready for macOS 26 Tahoe. This version supports macOS from Big Sur onwards.

Apfelstrudel 1.6 is now available from here: apfelstrudel16
from its Product Page, and via its auto-update mechanism.

Appexes

App extensions, or appexes, are numerous in recent versions of macOS, and widely used by apps. This simple utility shows all those managed by PlugInKit, complete with their UUIDs, to help you manage them. Version 1.1 has an overhauled interface, and has been rebuilt with a new app icon ready for macOS 26 Tahoe. This version supports macOS from Sonoma 14.6 onwards.

AppexIndexer 1.1 is now available from here: appexindexer11
and from its Product Page. It doesn’t yet support auto-update.

Logs

Until I started development of LogUI, Ulbow was my preferred app for browsing the Unified log. It has extensive features, with full support for the use of predicates, a chart showing the most frequent sources of log entries, and support for creating and using logarchives, including those from iOS and iPadOS. Unlike LogUI, it uses the log command to obtain log extracts, enabling it to show entry times in nanoseconds. It also displays extracts in Rich Text rather than as a list. Version 1.11 fixes a crashing bug when handling some logarchives, has an overhauled interface, and has been rebuilt with a new app icon ready for macOS 26 Tahoe. This version supports macOS from Big Sur onwards, and is recommended for all users.

Ulbow 1.11 is now available from here: ulbow111
from its Product Page, and via its auto-update mechanism.

Document versions

While Revisionist (also recently updated) provides a suite of tools to work with macOS document versions, Versatility handles one of those tasks with greater ease, creating version archives, and reconstituting them into documents. Simply drop a file onto its window and it will be converted into a folder containing each saved version as a separate document. Drop one of those archive folders onto its window and it will be reconstituted into a document with all those previous versions. This makes it simple to preserve versions when moving documents between volumes or computers, and for archival purposes. Version 1.1 has been rebuilt with a new app icon ready for macOS 26 Tahoe, and supports macOS from Big Sur onwards.

Versatility 1.1 is now available from here: versatility11
from its Product Page, and via its auto-update mechanism.

Next updates

Most of my other apps that haven’t yet been updated for Tahoe should still run perfectly well, although their app icons won’t appear the same as before. I’m now turning my attention to the successor to SilentKnight and Skint, and my virtualisers Viable, ViableS, Vimy and Liviable. Once I’m done with those, I’ll return and complete my other apps.

Enjoy!

Summer is an unpredictable time of year. With the Atlantic hurricane season already upon us, we could see searing heat or devastating storms. So it is with the announcements made at WWDC earlier this month: do we have time to try out some of the new features coming in three months, or must we get on with wrangling deprecations and changes looming in macOS Tahoe?

A glance through Apple’s beta release notes might suggest it should prove innocuous, and the great majority of code that’s already happy in Sequoia should have no problems in Tahoe, and so far that’s my experience. That should leave us plenty of time to adjust our app icons so they display properly in the Dock and elsewhere, but it’s there it gets more subtly complicated.

Fix app icons

I don’t think I can over-stress the importance of using Icon Composer for creating replacement app icons. If you don’t, then Tahoe seems determined to deface many traditional icons so they become almost illegible and unusable. The only exemptions are those already conforming to the fixed outline of a square with rounded corners. Any irregularity such as putting a pixel outside that, and they’re relegated to the sin bin.

Here are two icons for the same app viewed in Tahoe. The left one uses a traditional AppIcon.icns icon image, while that on the right is the same circular PNG that has been applied using Icon Composer and added as a .icon file. So far my attempts to get this to work using Xcode 16.4 have been unsuccessful, and the only solution has been to use a beta-release of Xcode 26.

Overhaul controls

That brings with it another problem, as it automatically converts AppKit and SwiftUI layouts so they use Tahoe’s new interface style, and that can generate further work. If you look closely at Apple’s demos of Tahoe at WWDC, you may notice that its controls have changed in size and shape. Not only do most have more rounded corners, but they also have different dimensions.

Interface conversion for apps that use AppKit or SwiftUI is clever, as it preserves the original for use in previous versions of macOS, and only adopts the new style when in Tahoe. Build your app with its smart new Tahoe-compatible icon and run it in Sequoia, and it looks just the same as it did.

This demo, Mallyshag, looks the same in Sequoia, but has become a mess in Tahoe because of those changed control dimensions.

Those three buttons are significantly wider, so now overlap one another and are wider than the text box below. They need a careful overhaul before they’re ready for Tahoe. Conversion can also have unexpected side-effects: for example, I’ve had some selectable text fields changed to be editable as well. You can see an example that I missed in the left view in XProCheck’s window. I now check carefully through every detail in windows that have been migrated by Xcode to support Tahoe.

This doesn’t just apply to AppKit windows in Interface Builder. Although SwiftUI dynamically positions controls, I’ve found it necessary to increase the minimum width of some views to ensure they remain fully usable.

Aside from any code changes needed, migrating an app to Tahoe thus requires:

• creation of a new app icon using Icon Composer;
• adding the .icon file to the Xcode project and setting it as the app icon;
• careful checking and rectification of all windows and their contents.

NSLog

There’s one last thing that may have escaped your attention in Apple’s release notes: NSLog. When Apple introduced the Unified log in macOS Sierra, it preserved the longstanding use of NSLog as a means of making entries with a minimum of fuss. More formal methods are more cumbersome, although they’re also more powerful, so NSLog still remains popular with developers, at least until Tahoe’s change.

A long way down the release notes, and oddly announced under the subheading of New Features, Apple states that NSLog will no longer record anything of use in its entries in the Unified log, although they’ll still be reported in full in Xcode and to stdout. One of the other purposes of my test app Mallyshag was to verify just what is now recorded by NSLog.

This is the entry obtained using LogUI when running either version of the app in macOS 15.5:

And this is the extent of entries seen in macOS 26:

So what in earlier macOS might have been a useful
Error number 1467296 in Mallyshag
is redacted to the contentless stub <private>.

If you still use NSLog, you’ll almost certainly want to move on to a better alternative, again being careful to avoid ending up with its contents redacted.

Outcomes

Come the release of macOS 26 Tahoe, there’ll be three groups of apps:

• those that haven’t been ported at all, whose icons will be almost unrecognisable;
• those whose icons display correctly, but with flaws in interface controls;
• those that work as expected, with conformant icons and controls.

Some will also write dysfunctional messages in the log, because they’re still using NSLog, although few users are likely to notice that.

That doesn’t take into account those apps relying on alternatives to AppKit and SwiftUI for their interface, as those have a great deal of ground to cover in just a few months if they’re going to be ready in time for Tahoe’s release.

That’s why I’ve started unusually early in getting my apps ready for the autumn/fall. I’m sure that summer still has some surprises in store.

Mallyshag?

This is a local Isle of Wight name for a caterpillar, usually a large and hairy one. It just seemed appropriate.

This next batch of updates to my apps includes more popular tools, covering iCloud, document versions, sparse bundles, and Time Machine backups.

iCloud

Cirrus gives you detailed insight into what’s stored in iCloud Drive, provides a ready-made log browser for checking what’s going on, and a simple test for syncing. Version 1.16 has an overhauled interface, and has been rebuilt with a new app icon ready for macOS 26 Tahoe. This version supports macOS from Big Sur onwards.

Cirrus 1.16 is now available from here: cirrus116
from its Product Page, and via its auto-update mechanism.

Document versions

Revisionist gives you direct access to versions of documents saved automatically by macOS, and a powerful suite of tools to work with them. You can run checks to discover which documents have saved versions, then browse those, previewing them with Quick Look. It can save individual versions as new files, and create archive folders containing all versions, that can be reconstituted into the original with those versions preserved. Version 1.10 has an overhauled interface, and has been rebuilt with a new app icon ready for macOS 26 Tahoe. This version supports macOS from Big Sur onwards.

Revisionist 1.10 is now available from here: revisionist110
from its Product Page, and via its auto-update mechanism.

Sparse bundle disk images

Spundle creates and maintains sparse bundle disk images, offering a range of supported file systems, and features such as compaction to maintain their efficiency. Version 1.9 has an overhauled window, and has been rebuilt with a new app icon ready for macOS 26 Tahoe. This version supports macOS from Big Sur onwards.

Spundle 1.9 is now available from here: spundle19
from its Product Page, and via its auto-update mechanism.

Time Machine backups

The Time Machine Mechanic, T2M2, is the standard utility for checking your Mac’s Time Machine backups. It checks and reports on their performance, free space on backup storage, how much has been transferred in each backup, and much more. Version 2.03 has an overhauled interface, and has been rebuilt with a new app icon ready for macOS 26 Tahoe. This version supports macOS from Big Sur onwards, backing up to APFS.

Depending on any changes finalised in the full public release of Tahoe later this year, I may need to make further adjustments to its code.

T2M2 2.03 is now available from here: t2m2203
from its Product Page, and via its auto-update mechanism.

Enjoy!

A quick check of just one of my working volumes revealed that it contains over 20,000 PDFs, the earliest dating from 1994, just a year after its introduction. Six years ago, I had become fed up with trying to use other PDF readers and set out to write my own, that soon became Podofyllin. It has some unique features, of which the most important to me is that it can’t and won’t change a PDF. Podofyllin is the latest app I have rebuilt, tweaked and given a new icon to, primarily for compatibility with macOS 26 Tahoe.

What I hadn’t realised was that, at some time during Sequoia, one of Podofyllin’s key features had quietly stopped working, apparently as a result of a silent change in macOS. This update fixes that, and restores (almost) full functionality, with just one feature still absent.

Perhaps its most important feature after preserving original PDFs unchanged, is its support for opening multiple views of the same document. Shown above are three different windows, each showing the same document, and at the lower left Writing Tools is just about to produce a summary from one of them.

The main window has thumbnails on the left, a conventional rendered page view in the middle, and the whole text content to the right. You can also open an unlimited number of accessory windows, each displaying different pages from the same document.

Another unique feature (the recently troublesome one) is a window to display the contents of the PDF file in raw format, so you can inspect its structure, metadata, and more.

This source code window shows two versions of the code, one as written in the file, the other ‘flattened’ as used in Quartz 2D to render it, together with a summary. Quite a few PDFs contain hidden content, usually left over from an earlier edit. Some save contents in versions, and for those Podofyllin can recreate and save those as separate PDF documents.

The one feature that used to work in the past that I still can’t revive is exporting page contents in Rich Text format, something I suspect isn’t working in macOS.

I have also taken the opportunity to overhaul the Help file thoroughly, to make it more accessible and navigable.

Podofyllin 1.4 is now available from here: podofyllin14
from its Product Page, and via its auto-update mechanism.

Like other recent updates, this new version requires Big Sur or later. If you’re still running Catalina or earlier, please check Podofyllin’s Help document, as that explains how you can disable its auto-update mechanism.

I’m delighted to welcome the prodigal Podofyllin back at last.

Here are three more updates to some of my most popular apps, primarily for improved compatibility with macOS 26 Tahoe, but with improvements in their interface for other versions of macOS from Big Sur onwards.

xattred 1.6

This toolset for working with extended attributes (xattrs) has several improved window layouts, a couple of fixes in its code to cope with deprecations, and a new icon that should work far better with Tahoe, without compromising its appearance in older macOS.

xattred 1.6 is now available from here: xattred16
from its Product Page, and via its auto-update mechanism. If you’re still using it in Catalina or earlier, please disable its auto-update as detailed in its Help book, so you can remain with version 1.5 or earlier.

Precize 1.16

This provides a great deal of useful information about files, from their inode number, detailed size including that of extended attributes, and access to bookmarks and their analysis. I have tweaked its main window to improve its interface, rebuilt it, and provided it with a new app icon that should be an improvement on all versions of macOS from Big Sur onwards.

Precize 1.16 is now available from here: precize116
from its Product Page, and via its auto-update mechanism. If you’re still using it in Catalina or earlier, please disable its auto-update as detailed in its Help book to remain using your earlier version.

DelightEd 2.4

This text-only Rich Text editor was originally developed to work better with Dark mode, when it was introduced in Mojave. Since then I have used it to produce all the Rich Text I use in apps, ensuring it continues to work properly across both Light and Dark modes. It also has unusual features to support interlinear text. This version has had a few tweaks in its window layout, and has been rebuilt to make it fully compatible with Tahoe and features like Writing Tools, as well as gaining an updated app icon.

DelightEd 2.4 is now available from here: DelightEd24
from its Product Page, and via its auto-update mechanism. If you’re still using it in Catalina or earlier, please disable its auto-update as detailed in its Help book so you can remain with an earlier version.

In the works

I’m currently in the throes of producing a new version of my PDF reader Podofyllin, which I use daily. Unfortunately, this will remove its ability to view the code inside PDFs, as Apple appears to have disabled all the features it relied on to perform that, and they no longer work in Sequoia. However, it still has some unusual features, such as opening multiple views of the same PDF, and can’t edit or save any changes to the original file.

I have spent some time inside Viable, my macOS virtualiser, trying to get it to use the new ASIF disk image, but so far have been unable to get it to work. I will be pursuing that when I get the time.

Enjoy!

In addition to its rounded corners and Liquid Glass, macOS 26 Tahoe brings substantial change in app icons. These follow the move to squares with rounded corners brought in macOS 11 Big Sur, and now enforce that outline on all apps, including Apple’s. The result is that icons of irregular shape, such as those used by SilentKnight and the rest of my apps, will be intentionally shamed by reduction in size and placement in a sin bin of a grey square with rounded corners. Although some developers are busy implementing workarounds, Apple has made it clear that it expects conformity with this new style.

While app designers and developers have to work within those stricter constraints, Tahoe opens up new user options in the display of app icons, extending the light and dark appearances that have been standard since macOS Mojave seven years ago. System Settings now provide a choice of four rendering modes for the display of icons and widgets, in dark, clear, tinted and default, with a further option for tinting colour.

To accommodate these changes, Tahoe has a new app aimed at those designing and implementing app icons, Icon Composer, free for anyone to download from here, and compatible with macOS Sequoia and later. Although not intended for customising icons within existing apps, it provides insight into these new design constraints and rendering modes.

In the past, app icons have been able to distinguish themselves by their form, colour and internal details, with the first two becoming dominant as their size is reduced in a heavily loaded Dock. By enforcing a uniform outline, Apple’s new interface style makes this task harder. I already have difficulty distinguishing Messages, FaceTime, even Numbers and Archive Utility, which in turn forces me to separate them in the Dock, and I still occasionally open the wrong app as a result. Other confusions have become common: Xcode, Developer and several third-party app icons are also hard to distinguish when at small size. Apple clearly hasn’t listened to criticism from users and developers, and has only made this worse in Tahoe.

We’re therefore left to make the best we can within these new rules. My recent redesigns for my own apps are an initial attempt to make their icons as distinct as I can, and to remain so in older versions of macOS at the same time.

I’ll start with the new icons for Mints, SilentKnight and SystHist, seen in the Dock in existing macOS in light mode.

and dark mode

Here, with the addition of XProCheck, are four of the many possibilities in Tahoe, first in light mode with default rendering

then in dark mode, again with default rendering

Clear rendering decolourises them into monochrome with valuable contrast

but tinted rendering makes their details even harder to read

As I gain experience in using Icon Composer, and understand better how Liquid Glass may be able to enhance the results, I intend improving on these. For the time being, though, what you see in these updated versions works better across all recent versions of macOS and Tahoe. As with other features of macOS 26, these will take further tuning on my part, and patience on yours. Please bear with me in the coming weeks and months.

SilentKnight’s history goes back to an unfortunate error in late 2016 when Apple shipped a batch of brand new MacBook Pros with SIP inadvertently disabled. At that time the only way to tell that was in Terminal, so I set about creating an app to make it easier to check. That became the first release of LockRattler in December 2016.

Demand for this grew steadily, as did LockRattler, and within a year it was checking additional security data in macOS.

At the same time it became clear from several reports that some Macs had EFI firmware that was woefully out of date. Some models were particularly prone to this, but at the time there were no lists of up-to-date firmware versions, and no local means to check them. In the summer of 2019, I started development on what was to become SilentKnight, originally named EFIcienC. This relied on a database that I built from looking inside macOS updaters to discover the latest firmware versions that should have been installed, but sometimes weren’t.

That soon took the familiar look of SilentKnight.

Three years later, there wasn’t much that SilentKnight didn’t check for.

Since the first version of SilentKnight, Apple has steadily been putting its house in order, and Macs have undergone great change. Next year’s major version of macOS 27 will no longer support Intel Macs, and that questions whether there’s a role for SilentKnight in the future.

Much of what SilentKnight does today is rapidly becoming redundant:

• T2 and Apple silicon firmware updates are now reliable and tied to macOS versions, so no longer need to be checked separately.
• In Apple silicon Macs, disabling SIP requires reducing boot security, so doesn’t need to be checked separately.
• XProtect updates are now delivered via iCloud and are more reliable, and not amenable to forced update.
• XProtect Remediator updates have become infrequent, every month or so.
• XProtect Remediator scans require separate, more detailed checks to interpret them properly.
• The TCC database has changed and is no longer updated as it used to be.
• Few security data updates are now delivered by softwareupdate.

Although SilentKnight has been a comfort over the last six years, its value is declining rapidly, and I don’t intend supporting it for macOS 27. It will though continue to support Macs running Tahoe and earlier, including all Intel models. Instead, I’d much prefer to develop Skint as a lightweight replacement for Apple silicon Macs in the future. Please provide me with your thoughts in comments here.

For those still using LockRattler, that hasn’t been updated for Sonoma or later, and the command tool companion to SilentKnight, silnite, doesn’t support Sequoia or later. They have both given good service over the years, but Macs and macOS have moved on.

XProCheck 1.7

If you use SilentKnight, you’ll be aware that XProtect Remediator scans have changed over the last year or so. Prior to that, the only time that scans by its plugins were cancelled was after an update. Now they’re run against a timer, and if they overstay their time limit, that plugin scan is cancelled. When this first started to occur, it wasn’t clear whether this was going to be a lasting behaviour, but it’s now well-established and common if not universal.

This new version of XProCheck now reports cancelled scans separately, using a emoji rather than a warning. I have also optimised its main view to look better when running in macOS 26 Tahoe, and made its app icon compatible with Tahoe’s requirements.

XProCheck 1.7 for macOS Big Sur and later is now available from here: xprocheck17
from its Product Page, and via its auto-update mechanism.

LogUI 1.0 build 68

Although this new build of my log browser LogUI is primarily to improve compatibility with macOS 26 Tahoe, including a new conformant app icon, this may bring a pleasant surprise for those who want to browse huge log extracts. According to a presentation at this year’s WWDC, “on macOS, lists of over 100,000 items now load six times faster.”

LogUI 1.0 build 68 for macOS Sonoma and later is now available from here: logui168
and from its Product Page.

App icons

Even if you didn’t watch any of the presentations at WWDC this year, you should by now have noticed that app icons are changing for Tahoe. Please bear with me as I progressively bring mine into conformance. I will explain more, with illustrations, in my Sunday morning article here.

I’m delighted to offer you updates to three of my most popular apps, SilentKnight, Mints and SystHist. Although these are primarily for improved compatibility with macOS 26 Tahoe, they bring additional improvements for earlier versions of macOS, back to Big Sur. They also require at least macOS 11.5 Big Sur.

SilentKnight 2.12

This utility for checking security settings and updates should now be fully compatible with Tahoe, and report the correct KEXT version in that, as well as the correct version number of macOS. Its views have been updated for Tahoe, as has its app icon. I have taken the opportunity to explain better how to update XProtect in Sequoia and Tahoe, both in the Help files and in the text advice given in its main window.

SilentKnight version 2.12 for Big Sur and later is now available from here: silentknight212
from its Product Page, and through its auto-update mechanism.

Mints 1.21

This collection of tools for obtaining custom log extracts and exploring both near and far corners of macOS should now be fully compatible with Tahoe. Its views have been updated for the new interface, as has its app icon.

Mints version 1.21 for Big Sur and later is now available from here: mints121
from its Product Page, and through its auto-update mechanism.

SystHist 1.21

This sophisticated update browser should now report details of updates for Tahoe as well as those going back as far as they’re available on your Mac. On my iMac Pro they go right back to macOS 10.14.1 update, installed here on 18 November 2018, and XProtect version 2101 in the following month. Its view has been updated for Tahoe, as has its app icon.

One point to note with this app is that you may see multiple updates listed in the left-hand pane for some versions of macOS. That isn’t an error, but reflects any additional downloads and installations that may have been made through that Mac, such as those on external storage, or copies of a macOS Installer app.

SystHist version 1.21 for Big Sur and later is now available from here: systhist121
from its Product Page, and through it auto-update mechanism.

For those still requiring support for macOS Catalina and earlier, I’m leaving the previous versions of these apps so they’re still available from their product pages. However, you may wish to disable their auto-update mechanism, as detailed in the Help docs, so you’re not repeatedly pestered to update from your current version.

Other apps

I have now started a rolling update process that should see all supported apps updated to work better with Tahoe, including new app icons. So far all the other apps that I use regularly, including xattred, DelightEd and Podofyllin, appear to work perfectly well in Tahoe, although they will look better after a refresh.

I will also be moving LogUI to Tahoe shortly, and am starting work on a thoroughly refreshed suite of virtualisation apps centred on Viable.

Quick Look is one of those unsung heroes that have transformed our Macs and workflows. What used to require a specialist app can now be accomplished in the Finder using a combination of Quick Look and Gallery view to browse collections of images.

This started back in Classic Mac OS, when apps created thumbnail images and attached them as ICN# resources to the original files for display in the Finder. It wasn’t until Mac OS X 10.5 Leopard in 2007 that Apple added Quick Look to perform this automatically using cached thumbnails and previews. Since then our Macs have worked hard to ensure that, wherever we want them, we can see faithful miniatures, at least until macOS 11 Big Sur.

Although the redesign brought by Big Sur in 2020 was generally well received, one feature I complained about at the time was its effect on Quick Look thumbnails and previews, in rounding their corners to conform to its design style. But style triumphed over fidelity, and for the last five years Quick Look has been forced to tell lies in every image thumbnail and preview.

By now you’ll have guessed I’m no fan of Apple’s new-found obsession with rounding every right angle in sight. I have yet to see any objective evidence that this has any purpose beyond aesthetics. If you’ve seen screenshots of the first developer beta-release of macOS 26 Tahoe, then you’ll surely have noticed that, rather than restoring fidelity to Quick Look, this fiction has grown and only become more prominent. I demonstrate this in a series of four screenshots showing the same image that have been rescaled to similar display sizes.

This first is taken from a small, almost thumbnail-size, image in the Finder’s Gallery view. As this has been scaled up, it’s pixellated. I draw your attention to the upper corners, where trees have been cropped at what once would have been right angles.

Seen here is the same image in a larger Gallery view. The extent of the cropping at the upper corners is now apparent, where this contains details that were removed from the smaller image above.

When opened in Preview, the upper corners are no longer rounded, and show the full extent of the image, but the lower corners remain cropped by enforced rounding, apparently to make them ‘concentric’, as is the vogue.

To see the whole image rendered faithfully, I had to resort to a third-party app, here GraphicConverter 12, which has the honesty to display all four corners without cropping.

One of the cornerstones of the Mac from its earliest days is expressed in the principle of WYSIWYG, what you see is what you get. It enabled the ‘desktop publishing revolution’ that convinced so many to pay the premium for Classic Macs, and ever since has guided the development of Mac OS. Without it there would be no purpose to Quick Look in its efforts to render images faithfully.

That doesn’t merit mention in the principles expounded in Apple’s latest revised Human Interface Guidelines. Three are given there, hierarchy, harmony and consistency, but not fidelity. Rounding corners of rectangles is included there under the principle of harmony: “Align with the concentric design of the hardware and software to create harmony between interface elements, system experiences, and devices.”

I can live with concentricity in windows and controls, even with app icons forcibly constrained within rounded rectangles. What I simply can’t accept is a Macintosh, of all computers, cropping every thumbnail and preview for the sake of aesthetics, however harmonious that might seem. For without fidelity, the Mac fails.

Although there was no ambiguity in Apple’s announcement that later this year it will be releasing macOS 26 Tahoe, together with version 26 of its other operating systems, there have been claims that this might just be a ‘marketing version’ and not really the case. There is some evidence that could be misinterpreted as confirming that, where some of Apple’s developer web pages refer to macOS 16.

But others choose to differ.

Cast your mind back five years to macOS 11 Big Sur, when what had been expected to be macOS 10.16 but was announced as 11.0 instead. That had the potential to upset a lot of code and scripts that had become used to checking the minor but not major version number. Apple foresaw those problems, and devised an ingenious scheme that allowed Big Sur to be simultaneously both 10.16 and 11.0. It’s hardly surprising that has been implemented once again for Tahoe.

Rules

There are two fundamental rules provided by Apple:

• In compiled languages, the version returned by macOS depends on the SDK which the software has been built against. When built against the 15 SDK or earlier, Tahoe returns 16 for compatibility with previous numbering and all existing apps; when built against the 26.0 SDK, it returns 26.0 for forward compatibility.
• In scripted languages run within a shell environment, there’s an environmental variable to control the version number given. Set SYSTEM_VERSION_COMPAT=1 and Tahoe returns 16; leave that variable unset, or SYSTEM_VERSION_COMPAT=0, and it returns 26.

AppleScript

Move a script across to Tahoe, and it will be compiled in the 26 environment, so
system version of (system info)
returns 26.0, as will that code inside an AppleScript app built on Tahoe.

Scripts and other languages

One method commonly used to look up the macOS version number is to obtain the string value for the ProductVersion key in /System/Library/CoreServices/SystemVersion.plist. However, depending on the environment of the caller, Tahoe plays tricks with that file, which should return a version of 26.0. If the caller has set SYSTEM_VERSION_COMPAT=1, then the version number returned isn’t obtained from that property list at all, but its companion SystemVersionCompat.plist, which is 16.0.

You can test this at the command line, by entering the two commands
SYSTEM_VERSION_COMPAT=1 cat /System/Library/CoreServices/SystemVersion.plist
and
SYSTEM_VERSION_COMPAT=0 cat /System/Library/CoreServices/SystemVersion.plist

Which is it – 16 or 26?

macOS Tahoe is very definitely, and not just for marketing purposes, macOS 26, but depending on how you ask that question, it could pretend to be 16 if you wish.

Disk images have been valuable tools marred by poor performance. In the wrong circumstances, an encrypted sparse image (UDSP) stored on the blazingly fast internal SSD of an Apple silicon Mac may write files no faster than 100 MB/s, typical for a cheap hard drive. One of the important new features introduced in macOS 26 Tahoe is a new disk image format that can achieve near-native speeds: ASIF, documented here.

This has been detailed as a major improvement in lightweight virtualisation, where it promises to overcome the most significant performance limitation of VMs running on Apple silicon Macs. However, ASIF disk images are available for general use, and even work in macOS Sequoia. This article shows what they can do.

Apple provides few technical details, other than stating that the intrinsic structure of ASIF disk images doesn’t depend on the host file system’s capabilities, and their size on the host depends on the size of the data stored in the disk. In other words, they’re a sparse file in APFS, and are flagged as such.

Make an ASIF disk image

Currently, there are only two ways to create one of these new disk images, either in Tahoe’s Disk Utility, or using its diskutil command tool, as in
diskutil image create blank --format ASIF --size 100G --volumeName myVolume imagePath
to create an ASIF image with a maximum capacity of 100 GB with a single APFS volume named myVolume with the path and name imagePath. You can also use a from option to convert an existing disk image to ASIF format.

These are only good for Tahoe, as there’s no support for their creation in Sequoia 15.5 or earlier. Neither is there any access documented for the hdiutil command tool, more normally used to work with disk images, although its general commands should work fine with ASIFs.

Resulting disk images have a UTI type of com.apple.disk-image-sparse, in contrast to RAW (UDIF read-write) images of type com.apple.disk-image-udif, which can be used to distinguish them.

Economy

When first created, a 100 GB ASIF disk image took less than 1 GB disk space, but after extensive use and adding a second volume, its size on disk when empty again ranged between 1.9-3.2 GB. No attempt was made to compact the disk image using hdiutil, and its man page doesn’t make clear whether that’s supported or effective with this type of disk image.

Performance

Read and write performance were measured using Stibium over a total of more than 50 GB in 160 files ranging in size from 2 MB to 2 GB in randomised order. When performed using a 100 GB ASIF image on the 2 TB internal SSD of a MacBook Pro M3 Pro running macOS 26 beta, transfer speeds for unencrypted APFS were 5.8 and 6.6 GB/s read and write. Those fell to 4.8 and 4.6 GB/s when using an APFS encrypted volume in the disk image.

Although there’s currently no way to create an ASIF disk image on a Mac running Sequoia, I compressed the disk image using Apple Archive (aar) to preserve its format and copied it to a Mac mini M4 Pro running macOS 15.5, and repeated the performance tests on its 2 TB internal SSD. Unencrypted APFS there attained 5.5 and 8.3 GB/s read and write.

Use

Apple recommends switching from the previous RAW (UDIF read-write) disk images used for the backing store of VMs to ASIF for their greater efficiency in file transfer between hosts or disks. As the disk image in a VM is created when the VM is first made and installed, this awaits implementation in virtualisers. Because the only access provided at present is the diskutil command tool, apps will need to consider creating an ASIF image where that’s available, in macOS 26 Tahoe.

Although ASIF appears to be supported by Sequoia 15.5, the danger with a VM based on an ASIF image is that it may not be compatible with older versions of macOS. Apple hasn’t yet revealed which of those can mount and use this new format.

Previous tests on different types of disk image demonstrated that, prior to ASIF, the best performance was achieved by sparse bundles. The following table compares those with ASIF.

Allowing for the differences in chips, ASIF is clearly faster than both UDRW read-write and UDSP sparse images, whether plain or encrypted. It’s also likely to be significantly faster than sparse bundles, and has the advantage that it uses a single file for its backing store.

Conclusions

• Where possible, in macOS 26 Tahoe in particular, VMs should use ASIF disk images rather than RAW/UDRW.
• Unless a sparse bundle is required (for example when it’s hosted on a different file system such as that in a NAS), ASIF should be first choice for general purpose disk images in Tahoe.
• It would be preferable for virtualisers to be able to call a proper API rather than a command tool.
• Keep an eye on C-Command’s DropDMG. I’m sure it will support ASIF disk images soon.

Just before the start of WWDC, I released an update to my log browser LogUI adding support for accessing logarchives. I promised that there was more support for logarchives on its way. LogUI 1.0 build 65 dedicates a whole window to them, in its Logarchive Tool.

There are many situations where you can’t access the active log, and you can’t create a logarchive using the log command tool or a sysdiagnose. These include:

• When you only have access to the contents of the Mac or device’s storage, particularly in forensics, or following hardware failure.
• When you want access to the logs in a backup. Time Machine backups normally include full log files, for example.
• When you don’t have ssh or similar access to a remote Mac.
• When the log records may be incomplete or damaged.

Provided that you can copy two folders from the hidden /var/db folder on that Mac or device, LogUI can turn those into a browsable logarchive.

Create a logarchive from folders

On your Mac, create a folder somewhere convenient such as ~/Documents. As this method doesn’t use the log command, this can be on an external disk if you wish.

From the source Data volume copy the folders at /var/db/diagnostics and /var/db/uuidtext to your folder, so it looks like this.

Open LogUI, and from its Window menu open its Logarchive Tool. This offers you four tools and two checkboxes. Click on the Create Logarchive tool and first select the folder you created, containing the log folders. Then give the new logarchive a suitable name and save it somewhere convenient.

LogUI should then inform you in its window that creation has completed. As this is performed using undocumented code for an undocumented format, it may not always work correctly. If there are any problems, repeat the same with the Debug checkbox ticked, and it will give you a detailed commentary of what it does, which should help you understand what went wrong.

Getting info about a logarchive

The trickiest part of accessing logarchives is knowing what they contain, more specifically the time periods for which they have log records. LogUI’s Logarchive window provides two aids to provide you with that information, in its Catalogue and Analyse tools.

Catalogue simply lists all the tracev3 files in the logarchive, giving the datestamps each was created and last modified, together with the period between those, and the file size.

Leave that open as you browse that logarchive, to guide your way through its entries.

Analyse goes further, in telling you about the entries in each of the persist tracev3 files in the logarchive. It tells you the most common processes that wrote the entries in each of those files, allowing you to hone in on which are of most interest. If you want to extract that information for analysis in a spreadsheet, tick the CSV checkbox and it will be shown ready to import into your favourite spreadsheet.

Finally, to save the contents of the current window as a text file, click on the Save Text tool at the right.

I have now checked LogUI’s compatibility with the first developer beta of Tahoe, and found and fixed one obscure bug in the Logarchive Tool before this new build. LogUI should now be fully compatible with macOS 14.6 and later, including Tahoe. It’s available now from here: logui165
and from its Product Page.

Enjoy!

The golden rule with any pre-release version of macOS is never to install it on a production Mac, one that you rely on for doing anything important to you. Although even developer betas are generally fairly robust and shouldn’t cause data loss, sometimes they can be catastrophic and require putting your Mac into DFU mode and restoring it from scratch.

Rather than compromise and run Tahoe from a bootable external disk, which only reduces the risk, why not run it in a VM, where it should be safely isolated from the rest of your Mac? Provided that you have an Apple silicon Mac running Sequoia 15.5 and a little time, this is easy to set up. Its major disadvantage is that your VM won’t be able to run the great majority of apps in the App Store, as that still isn’t supported in lightweight VMs. But your VM can have full iCloud access, and its Data volume can be protected by FileVault as well.

Before you try installing your VM, you’ll need to install a software enabler. This can be Device Support for macOS 26 beta, available from Apple’s developer site alongside the IPSW image file for Tahoe, or you can install the beta-release of Xcode version 26 instead. If you do neither, when you try to run your Tahoe VM you’ll be warned, and invited to download the enabler, but that isn’t likely to work, leaving you with an unusable VM.

Then download the IPSW file from Apple’s developer site, or via Mr. Macintosh’s link to Apple, install that and run your VM.

I’m grateful to Joe for letting me know an alternative route, by upgrading an existing Sequoia VM. For that you’ll need the full installer, again through Mr. Macintosh’s link, so you can install that in the VM and run it from there.

These should work with all virtualisation apps, including commercial products like Parallels Desktop, and free apps including my own Viable and Vimy, which also appear fully compatible with Tahoe hosts.

Happy virtual Tahoeing!

As expected, Apple announced the next major version of macOS and its other operating systems, on the opening day of WWDC yesterday. This followed a disarming vision of Craig Federighi sporting a forest of grey hair and racing a Formula 1 car around the roof of Apple Park. Mercifully, that turned out to be a promotion for a new Apple TV+ production titled F1, rather than anything about to happen to macOS. And he didn’t crash.

Previews of each new OS were prefaced by the promise of “big announcements for all of our platforms”, and inevitably opened with plans for Apple Intelligence and Private Cloud Compute. Language support is going to be further extended, and additional new features are going to be announced later during this cycle. Perhaps most important is the news that third-party developers are to be given access to on-device Large Language Models (LLMs) through a Foundation Models Framework. This looks highly accessible, and it will be exciting to see what that enables.

As widely forecast, these new major versions bring a redesign intended to harness the power of Apple silicon, with a look dubbed Liquid Glass. This features layers of translucent controls that adapt to your actions, for example moving out of the way when scrolling. Although this is harmonised across devices, fears that macOS will be ‘dumbed down’ to resemble iOS appear unfounded. Indeed, iPadOS is steadily moving closer to macOS with a more Finder-like Files app, and iPads will at last be able to run background tasks.

Some features of Liquid Glass appear visually stunning, for example when providing 3D effects of depth in lock screen photos. Overall, from the little that has been shown so far, it looks impressive without being obtrusive or irritating. To get the best out of Liquid Glass, apps will need to be rebuilt against the improved API, and their appearance tuned lightly. Some special visual effects may need access to new API features, though.

To get the best out of this new look, icons need to be layered, and adapted for new appearance options including transparent. Apple has provided a new Icon Composer app to support that. Although I doubt whether it will become as popular as ResEdit was in Classic Mac OS, I can see Icon Composer being used more widely than the rest of Xcode.

Hardware support

Surprisingly, four Intel models continue to be supported by Tahoe. The full list given by Apple reads:

• MacBook Pro 16-inch 2019, and 13-inch 2020 with four Thunderbolt ports,
• iMac 2020,
• Mac Pro 2019,
• all Apple silicon models from 2020 onwards.

Although those Intel models will be able to use many of the new features in Tahoe, they continue to be unable to access any Apple Intelligence.

This means that Tahoe will continue to be a large Universal binary, and could in theory be supported by OCLP, although that’s likely to be more challenging. Apple has stated explicitly that Tahoe will be the last major version of macOS to support Intel Macs.

Version numbering

As rumoured, Apple has changed the numbering of all its OSes, bringing them in synchrony to version 26. This even applies to the new beta-release of Xcode for Tahoe.

Although that might come as a surprise to some code and scripts, because it’s a higher major version number than Sequoia this should present far fewer problems than did macOS 11 Big Sur. You might still like to check anything of yours that does check version numbers to ensure it doesn’t trip up.

Details

In keeping with the redesign, improvements in folder and icon appearance were mentioned early. Easy folder customisation is coming, allowing the standard icon to be enhanced with the superimposition of symbols and emoji, and its colour changed. Icons can be tinted by the user, as well as being layered in Icon Composer.

Continuity features that integrate Macs with devices are being extended with support for Live Activities added to macOS. The Phone app will be added as well, in its improved form from iOS 26.

Shortcuts gains ‘intelligent’ actions, and will have direct access to LLMs in Private Cloud Compute. Spotlight has undergone a major update, but in Global Spotlight features rather than local search. From the Spotlight icon, there will be intelligent actions integrated with Shortcuts, quick keys abbreviations, and it will be contextually aware. To take advantage of these, third-party apps will need to use App Intents.

Games will be integrated into a new Games app, and gain translucent controls.

The powerful GPUs in Macs supported by Tahoe should also become more capable, with the introduction of Metal 4.

Finally, Tahoe is dropping full first run security checks on notarized apps, which should ensure they all launch blazingly fast. Although a few malicious apps have been inadvertently notarized in the past, running XProtect checks on them seem pointless, as the notarization process involves more extensive checks than those performed by XProtect. If malware has managed to sneak past Apple’s checks and become notarized, then nothing in macOS is going to detect it as being malicious.

Release dates

Apple has already released the first developer beta-test version of Tahoe and its sister OSes. The first public beta is promised for July, and full release of macOS 26.0 is due in the fall/autumn.

I’ve already started testing my own apps.