macOS 26 Tahoe has many smaller enhancements to make life easier. Among them is a novel way of customising folder icons, as explained here.

Traditional custom folder icons

One of the most ancient features in macOS is adding a different icon to a file or folder, by pasting it into the top left of the Get Info dialog for that item. I have detailed how to do that, and how it works, in this article. While that still works, it has some significant limitations and is fiddly.

Another disappointing behaviour in previous macOS is the effect of adding coloured Finder tags to folders, which don’t change the colour of the folder as displayed.

Tahoe custom folders

macOS 26 changes the behaviour of folder icons in three ways:

• Default folder colour is now set in Appearance settings. In most cases, that will be left to use the Theme colour.
• Applying a coloured Finder tag to a folder now changes the colour of that folder, as well as displaying a coloured dot.
• Folders can be customised additionally using the Customise Folder… command in the Finder’s File or contextual menu.

The last of those merits further attention, and an explanation of how it works.

Customising folders

Rather than adding an arbitrary icon to a folder, Tahoe’s custom folders consist of a traditional folder icon with a symbol or emoji superimposed. These are selected from a wide range of vector graphic symbols drawn from Apple’s huge SF Symbols collection, or the standard range of Unicode emoji.

Symbols appear embossed with little difference in tone, so aren’t easy to distinguish unless the folder icon is quite large. This isn’t suitable for use in the Finder’s Column or List views.

The familiar range of emoji is usually clearer and readily distinguishable in most sizes.

Adding a coloured Finder tag to a customised folder makes it even more distinctive, and increases colour contrast with the emoji.

Not only does this look good, but it solves the problems associated with old-style custom folder icons. Copy that folder anywhere within your Mac, and its new look goes with it. Move it into iCloud Drive, and it goes there too. Although Macs and devices running older versions don’t show the custom folder in its full glory, those running OS 26 do. Yes, open Files on your iPhone and you’ll see the custom icon there too.

The only shortcoming that I can find is that, while you can search for specific Finder tags in Spotlight, you can’t search for the symbol or emoji displayed on the folder icon. There is a search attribute Custom Icon, but these folders aren’t considered to have that attribute.

How it works

Tahoe’s custom folders rely on a combination of two extended attributes (xattrs) attached to the folder:

• com.apple.FinderInfo, 32 bytes that is also used in other Finder settings;
• com.apple.icon.folder, new to Tahoe and containing details of the symbol or emoji to be displayed.

Both have to be attached to the folder for it to be displayed correctly.

com.apple.icon.folder is of particular interest, as it has an S flag, and is itself usually displayed as com.apple.icon.folder#S. The S tells macOS that xattr should be preserved during syncing with services such as iCloud Drive. A full list of xattr flags is given in the Appendix. This xattr contains a Unicode string such as
{"emoji":"🔍"}
for an emoji, or
{"sym":"person.crop.circle")
for one of the vector graphics in SF Symbols. The first is self-explanatory, while the second uses the name of that symbol in the SF Symbols library. This currently only supports a subset of the whole library, and my attempts to get it to use others from SF Symbols have so far failed.

Conclusion

macOS has succeeded because of its attention to detail. Tahoe’s new custom folders are an excellent example. Enjoy them!

Appendix: Xattr flags

Flags can be upper or lower case letters C, N, P, S or B, and invariably follow the # separator, which is presumably otherwise forbidden from use in a xattr’s name. Upper case sets or enables that property, while lower case clears or disables that property. There are currently five properties:

• C: XATTR_FLAG_CONTENT_DEPENDENT, which ties the flag and the file contents, so the xattr is rewritten when the file data changes. This is normally used for checksums and hashes, text encoding, and position information. The xattr is preserved for copy and share, but not in a safe save.
• P: XATTR_FLAG_NO_EXPORT, which doesn’t export or share the xattr, but normally preserves it during copying.
• N: XATTR_FLAG_NEVER_PRESERVE, which ensures the xattr is never copied, even when copying the file.
• S: XATTR_FLAG_SYNCABLE, which ensures the xattr is preserved during syncing with services such as iCloud Drive. Default behaviour is for xattrs to be stripped during syncing, to minimise the amount of data to be transferred, but this will override that.
• B: XATTR_FLAG_ONLY_BACKUP, which keeps the xattr only in backups, including Time Machine (added recently).

These operate within another general restriction of xattrs: their name cannot exceed a maximum of 127 UTF-8 characters.

If you have a Mac Studio M3 Ultra and want to upgrade it to run macOS 26.0 Tahoe, then I’m afraid you’re going to have wait for Apple to build a new release that will install on your Mac.

I’m very grateful to Ken who has tried unsuccessfully to upgrade from 15.7 to 26.0. There are plenty of others reporting exactly the same: the upgrade goes well until towards the end, then aborts and the Mac is restarted back into 15.7. The problem seems to originate from an error in its neural engine driver.

Having just taken a look through a comparison between kernel extensions shipped with macOS 15.6 and 26.0, there are several Apple silicon hardware kexts that seem to have gone missing in 26.0, although whether that’s the cause only Apple’s engineers should know.

Apple is advising all those affected to put their Tahoe upgrade on pause until it releases a new build that does fully support the M3 Ultra. Until then, 15.7 is the limit for Apple’s most powerful and expensive Macs yet.

Among the many new features Apple lists for macOS 26 Tahoe is a new disk image format, Apple Sparse Image Format or ASIF. In that list it appears as a feature for virtualisation, and is explained as: “Create virtualized disk images with a virtualized file format that can be formatted to any kind of file system.”

Yet in the help pages for Disk Utility, the claim goes further: “A modern sparse read/write image. The space it uses on your disk is proportional to the data it contains, making it efficient and general-purpose.” In Apple’s developer documentation for virtualisation, there’s more detail still:
“Apple Sparse Image Format (ASIF) files transfer more efficiently between hosts or disks because their intrinsic structure doesn’t depend on the host file system’s capabilities. The size the ASIF file takes on the file system is proportional to the actual data stored in the disk image.”

This article considers whether this new ASIF disk image format, as implemented in macOS 26.0, is more suitable for general purposes than the other two leading contenders. Should you use ASIF instead of sparse bundle or read-write (UDRW) disk images?

Testing

To assess the performance of these disk images, read and write speeds were measured in macOS 26.0 Tahoe running on a Mac mini M4 Pro with a 2 TB internal SSD. Each disk image was created using Disk Utility, with a single APFS volume in a disk of maximum size 100 GB stored on the internal SSD, with FileVault enabled. Each format was tested using plain APFS, and separately using APFS Encrypted with 256-bit AES.

When each disk image was created and mounted, a single folder was created in it, and the image unmounted. The disk image was mounted again, and a standard write test performed into the folder using Stibium. That writes in random order a total of 160 files ranging in size from 2 MB to 2 GB, totalling 53 GB. Once the write speed had been measured the image was unmounted again and Stibium closed. For the read test the image was mounted again and all 160 files in the test folder were read in random order using Stibium to measure their speed.

Results

Read and write performance for each of the tests are shown in the table, where results are ranked by read speed.

All three disk image formats achieve similar read and write speeds with unencrypted images. There were substantial differences in performance, though, when encryption was used. With encryption, the sparse bundle was faster than both RAW (Read-Write, UDRW) and ASIF. The new format read at exactly half the speed of a sparse bundle, and at 57% of write speed. ASIF with APFS Encrypted was the slowest of the seven tests in both read and write.

Differences in the size on disk of images were small. Empty disks were smallest for sparse bundles and ASIF, and following deletion of all test files, ASIF returned to the smallest size, indicating that it’s the most space-efficient.

Why use ASIF?

If ASIF doesn’t perform any better than existing formats, and any gains in space on disk are small, when and why should you use the new format? To appreciate its strengths, you need to consider how the other two formats work in terms of the file system they’re hosted on, and the file system they run internally.

A sparse bundle stores its contents on many band files inside its bundle. When its internal file system is able to compact free space, used space can be compacted into a minimum number of bundles, and those containing just free space can be deleted. Thus the total size of its bundle will vary according to the space required to store its contents. Coupled with efficient read and write support this results in good space efficiency and performance.

When a Raw Read-Write disk image has an internal file system that is capable of Trimming free space, as APFS and HFS+ can, that process will compact free space within the image. When the image is stored on a host file system that supports sparse file format, as APFS does, the space in the image that is free can be skipped, resulting in a space-efficient sparse file. However, a host file system like HFS+ that doesn’t offer a sparse file format is unable to take advantage of that.

ASIF is claimed to be able to accomplish similar economy of storage space without relying on the host file system’s special file formats, making it more suitable when the conditions required by sparse bundles and Raw Read-Write disk images aren’t available.

Although this new feature has been announced for virtualisation, it’s most probably only going to be useful for those running VMs stored on file systems other than APFS. Prior to the introduction of ASIF, VMs hosted on APFS have used Raw Read-Write style storage which has benefited from sparse file format, whether they’re macOS or Linux. Where ASIF may be of greatest benefit is for VMs run from network shares or cloud services, whose host file system won’t be APFS.

Recommendations

• ASIF should be the disk image format of choice when neither sparse bundles nor Raw Read-Write images can achieve similar economy in host storage space.
• In other circumstances, where sparse bundles or Raw Read-Write images can provide space-efficient storage and full performance, they are still to be preferred.
• At present, ASIF isn’t generally a better replacement for sparse bundles or Raw Read-Write images, particularly when their internal and host file systems are APFS.
• ASIF is likely to be of greatest benefit to those running macOS or Linux virtual machines from network shares or cloud services, where the VM can’t be hosted on APFS.

Apple has just released macOS 26.0 Tahoe (build 25A354), together with security updates to Sequoia taking it to 15.7, and for Sonoma to 14.8. As expected, there are no further security updates provided for Ventura, which is now unsupported.

The upgrade to Tahoe is once again provided as an ‘update’ rather than a full Installer app. If you want to run the Installer app to upgrade, download it from the App Store rather than using Software Update. If you’re updating Sequoia or Sonoma and your Mac is capable of running Tahoe, be very careful to select the right update in Software Update.

The Tahoe upgrade weighs in at 7.7 GB for Apple silicon Macs upgrading from a recent version of Sequoia. For Intel Macs it should be 6.1 GB.

On Apple silicon Macs, iBoot is updated to version 13822.1.2. Intel Macs have their firmware updated to version 2092.0.0.0.0 (iBridge 23.16.10350.0.0,0). Safari is version 26.0 (21622.1.22.11.14). The Darwin kernel version is 25.0.0.

Security release notes are also available:

• Tahoe 26.0 lists 75 vulnerabilities fixed, none of which is reported as already being exploited.
• Sequoia 15.7 lists 34 vulnerabilities fixed.
• Sonoma 14.8 lists 38 vulnerabilities fixed.

Useful links

Prepare to upgrade macOS – what you should have done already
What should you do when an update goes wrong?
When you should use Safe Mode, and what it does
What to do when there’s something fundamentally wrong with an Apple silicon Mac
Eclectic Light software updates for Tahoe

Last updated at 1928 GMT 15 September 2025. My apologies for some previous incorrect versions, which were the result of an unintended update.

macOS 26 Tahoe’s big thing is its redesigned interface, with additional variations to appearance modes and its new Liquid Glass effects. Whether you’re installing the upgrade because of those, or in spite of them, allow me to take you on a quick tour of how you can set its interface up, and which controls do what.

There are three sets of controls:

• Appearance mode, Light or Dark, in Appearance settings;
• Display variations to Reduce transparency or Increase contrast, in Accessibility settings;
• Icon & widget style, in Appearance settings.

That comes to a total of more than 20 combinations before factoring in icon tinting colour, so there’s no shortage of choice.

Light mode

There are three overall variations of light mode, depending on those Accessibility settings.

The starting point and default is in light mode without Accessibility, and icon & widget style set to Default. Note the effects of transparency on the menu bar, widgets, the Liquid Glass effect in the left side of the Dock, and the upper row of icons in the Finder window. If you like those, you don’t have to change any settings.

This is light mode with Reduce transparency enabled in Accessibility settings. This disables all Liquid Glass effects and restores the traditional menu bar and Dock. The effect on Desktop widgets is perhaps less beneficial.

In light mode with Increase contrast (automatically coupled with Reduce transparency) enabled, the predominant effect is the outlining of controls within each window, rather than any change in contrast. Colours used by the system, such as the traffic light controls at the top left of each window, and those in themes, are darker, but those elsewhere, as in icons, aren’t changed. The effect here is to make controls clearer rather than actually changing contrast.

Dark mode

Without changing Accessibility and leaving Icon & widget style set to Default, dark mode shows transparency and Liquid Glass effects as you expect. These are again most visible in the menu bar, Dock, and the upper row of icons in the Finder window.

With Reduce transparency enabled in Accessibility settings those transparency and Liquid Glass effects are removed.

Enabling Increase contrast outlines controls clearly, but any changes in system colours are more variable than in light mode.

Icon & widget style

This is new to Tahoe and only affects the rendering of icons and widgets.

Using light mode without any Accessibility changes, the Default setting for Icon & widget style is the baseline, showing icons in their ‘normal’ state.

Dark icon settings in light mode contrasts more but their readability may suffer.

When Icon & widget style is set to Clear, most are decolourised, making them significantly harder to read, and impossible to distinguish in the sidebar of System Settings.

The final option is for Icon & widget style to be Tinted, where they’re rendered in monochrome using a colour of your choice, selected from the popup menu below. On iPhones and other devices that are available in several case colours, some have decided to set tinting to match the case, something you might like to try with an Apple silicon iMac, for example.

However, be careful in both Clear and Tinted styles, as it’s easy to end up making many icons unreadable and almost indistinguishable, here by setting the last of those to Graphite colour. This is one of the obvious drawbacks in Tahoe’s flexibility, in that many combinations of appearance mode, Accessibility settings and icon and widget style degrade its human interface rather than enhancing it. At least you now know what not to try, and how to return it to its defaults.

Summary of controls

• Appearance mode, light or dark, in Appearance settings;
• Display variations to Reduce transparency or Increase contrast, in Accessibility settings;
• Icon & widget styles, in Appearance settings, with Icon, widget & folder colour when appropriate.

Have fun!

For the last three months, since Apple released the first developer beta of macOS 26 Tahoe, I’ve been fairly busy updating my apps so they’re ready for its release. This quarter of the year is usually quite busy, but the changes brought by Tahoe have required more work than any version of macOS so far. This article provides checklists of every one of my apps and command tools that I believe should be compatible with macOS 26, and in most cases I have tweaked and rebuilt to ensure that.

The first problem posed by Tahoe was its rough handling of app icons that it didn’t like, because they deviated from its standard square with rounded corners. This isn’t something to be ignored, as if you can’t recognise apps in the Dock, how can you use them?

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 for Tahoe. So every supported app has required a new icon to be designed for it, and incorporated into a new build. Here’s part of my beauty parade.

Unfortunately, the moment you rebuild an app with its new icon, its whole interface is also rebuilt to Tahoe’s new standards. Those not only include all those infernal rectangles with rounded corners, but many controls and elements are larger than in Sequoia. While this is implemented intelligently so as not to upset layouts when running in older versions of macOS, Tahoe’s new look can wreak havoc with windows and dialogs.

This demo, Mallyshag, looks the same in Sequoia above, but has become a mess in Tahoe (below) 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.

Here are the 31 updated apps that I have equipped with a new icon and adjusted their interface for Tahoe:

• Alifix version 1.4
• Apfelstrudel version 1.6
• Cirrus version 1.16
• Cormorant version 1.6
• DelightEd version 2.4
• Dintch version 1.8
• DropSum version 1.2
• Dystextia version 1.9
• Fintch version 1.4
• LogUI version 1 build 70
• Metamer version 1.6
• Mints version 1.21
• Nalaprop version 1.4
• Podofyllin version 1.4
• Precize version 1.16
• Revisionist version 1.10
• SilentKnight version 2.12
• Skint and SkintM version 1.09
• Sparsity version 1.4
• Spotcord version 1.0
• SpotTest version 1.1
• Spundle version 1.9
• Stibium version 1.2
• SystHist version 1.21
• The Time Machine Mechanic (T2M2) version 2.03
• Ulbow version 1.11
• UTIutility version 1.4
• Versatility version 1.1
• xattred version 1.6
• XProCheck version 1.7

There are also my three macOS virtualisers for Apple silicon Macs, which require more than an overhaul. However, I regularly use these in Tahoe and believe they’re fully compatible, even if their icons will disappoint:

• Viable version 1.0.12 (b12)
• ViableS version 1.0.12 (b12)
• Vimy version 0.7 (fourth beta)

I intend working on those in the coming months, to update them and cast them into fresh interfaces.

I have also tested five of my command tools, and believe they too are fully compatible with Tahoe:

• alisma version 4
• blowhole version 11
• cintch version 3
• cmpxat version 4
• unorml version 5

At least they don’t have custom icons.

So that was the summer of 2025, in more nutshells that I had expected. I hope you still find these useful, and will report any problems you encounter.

With macOS 26 Tahoe due to be released on Monday 15 September, I’m delighted to provide version 1.09 of my simple security checker Skint and its menu bar sibling SkintM.

These new versions should recognise Tahoe correctly, and check its version against an updated database.

Skint and SkintM versions 1.09 are now available from here: skint109
from Downloads above, from their Product Page, and via their auto-update mechanism.

Note that, because of the way it (mis)handles Dock icons, Skint might prove to be one of the few apps you run in Tahoe that doesn’t conform to its standard icon format. I also resisted the temptation to make these version 26.

Apple has announced that macOS 26 Tahoe will be released on Monday 15 September, slightly earlier than had been speculated. Even if you’re not intending to upgrade to that, you might instead be looking at moving from Sonoma to Sequoia, or perhaps dragging your feet and considering Sonoma as it enters its final year of support. This article considers what you should do when preparing to upgrade macOS.

One of the surgeons I worked for in my first internship in hospital taught me an important lesson in life: when considering the outcome of anything that could go wrong, assume that it will go wrong, and prepare for that. When it actually works out better than you planned for, you can enjoy your success.

Emergencies

The worst case is that your Mac dies during the upgrade. Although that’s also the least likely, you need to think through your disaster plan. I ensure that all my most essential files and data are shared or copied up to iCloud so that I could get by for a day or three without that Mac. A recent full backup is also essential: if your Mac needs to go away to be resuscitated, one way or another that’s what you’ll be restoring from.

Upgrades do bring a tiny but significant risk of bricking your Mac in a way that only a full Restore will recover it. Although this can apply to Intel Macs with T2 chips if a T2 firmware update goes wrong, this is more the preserve of Apple silicon Macs. I’ve recently stepped through your options with full details here. Your first DFU Restore is daunting, but once you’ve done one, you’ll realise that they’re not that challenging if you have the right cable and DFU port. When you’ve restored firmware and macOS, you’ll then be restoring from that last backup, emphasising its importance.

In the days before the SSV, when there was only one boot volume and that could so readily be corrupted during upgrades, you also needed to have an emergency toolkit handy to repair an upgrade that went wrong. These days, the whole of the System in the SSV is either perfect, or macOS has to be reinstalled. Minor glitches are almost invariably corrected by restarting after the upgrade has completed, or starting up in Safe mode (remember on Apple silicon Macs that’s performed from Recovery).

Reverting macOS

The other possibility that you should plan for is beating a hasty retreat and reverting to an older version of macOS. Provided that you’re fully aware of the changes to the macOS interface brought in Tahoe, I think this is less likely for those upgrading from Sequoia, but if you’re skipping a version or two you could still find yourself unable to use a vital peripheral or one of your key apps, leaving you with reversion as your only option.

I’m sometimes asked by eternal optimists whether you can revert to your previous macOS simply by using its SSV snapshot. Sadly, snapshots are of no help: the only way back is to wipe and reinstall that macOS.

On Intel Macs, you’ll need to do this when booted from an external bootable installer, which doesn’t have to be on a USB ‘thumb’ drive, but does still require its own HFS+ volume to work. Apple explains this here, and Mr. Macintosh has links to all available installer apps.

Although you can do that with an Apple silicon Mac, if you have a second Mac and the right USB-C cable, it’s usually quicker and simpler to do this by restoring from the appropriate IPSW file in DFU mode, then restoring your files from your latest backup, as explained here. This is particularly valuable, as it also restores the original firmware, which may be the root of your problems. Unfortunately, that doesn’t seem possible with Intel Macs. Once their firmware has been upgraded, the user isn’t able to downgrade it.

Checklist

• Check you’re prepared to use your disaster plan if needed.
• Consider sharing and copying to iCloud to help you use another Mac or device temporarily.
• Make a full backup immediately before starting the upgrade.
• Restart, or start up in Safe mode, if the upgrade leaves your Mac with problems.
• Reverting to an older macOS isn’t trivial, and will require you to restore from your backup.
• Revert an Intel Mac using a bootable external installer.
• Consider reverting an Apple silicon Mac by restoring it in DFU mode, using an older IPSW.

Whatever you choose to do, I wish you success, and hope that your preparations prove completely unnecessary.

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.