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.