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.

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.

I don’t always hit the right keyboard shortcuts. Of those that I commonly get wrong, by far the most serious are Command-W and Command-Q in Safari. While the former just closes the frontmost window, the latter quits the whole app, and can lose the contents of online forms. Why can’t Safari show a confirmation alert before quitting, so I can cancel those unintentional quits?

No alert is going to stop you from using the wrong keyboard shortcut. All it will do is annoy you every time you want to quit Safari and press the correct keys. At worst, when you press Command-Q but intended Command-W, you’ll accidentally click on the wrong button in the alert and go ahead with quitting Safari. The error isn’t quitting the app, it’s pressing the wrong keys, and you’ll continue to do that unless you train yourself out of it, or change your practice to make it more robust.

Historically, keyboard shortcuts for quitting apps and closing windows have long been set as Command-Q and Command-W, as Q stands for Quit and W for Window. It’s unfortunate that the two keys are immediately adjacent, so making it easy to press the wrong one, particularly if you hunt and peck for keys rather than being a touch typist.

If you’re having this problem in Safari, then you’re most likely doing the same in other apps, although its impact there may not be as apparent. That’s because most other apps track changes made in open documents for this purpose, but that’s not something that Safari can do with web pages, as entering your own text within them is tracked by the remote web server, not the browser. This should be mitigated by any website that you’re entering text into: the server should either record those entries as you make them, or at least give you the option of saving them. That’s a basic expectation of accessible website design.

Solution

You may find it helpful to enable Ask to keep changes when closing documents in Desktop & Dock settings. Coupled with disabling the control below, to Close windows when quitting an application, that should bring more protective app behaviour.

It might seem tempting to try changing the shortcut for Quit, but as far as I can see, you can’t do that for all apps. Changing it for just one or a few introduces a major inconsistency, and only increases the risk of error.

The best way you’re going to address this is to remove its root cause, by not pressing Command-Q when you don’t want to quit Safari, and that requires you to close windows a different way. Readily available in macOS is the choice of:

• closing windows by clicking on their red Close button at the top left;
• using the Close command in the File menu;
• assigning a different key combination, and using that to close windows in all apps.

Although you don’t appear able to change the shortcut for Quit in all apps, you can for Close. Open Keyboard settings, click on Keyboard Shortcuts…, then on App Shortcuts at the left. Click on the + tool to add a new shortcut, and set that for All Applications, with a Menu title of Close, and a shortcut of something like Command-Shift-M. You may find Apple’s list of keyboard shortcuts helpful to ensure there are no conflicts. Whichever you choose, you should apply it consistently across all your apps. This keeps it standard and simple and makes it automatic.

Of those three options, my preference is invariably for the first, using the window’s Close button. That’s because it works independently of whichever window is at the front and ‘in focus’. With a little care checking which window you apply it to, it should be completely free of error. The disadvantage of both the Close menu command and its shortcut Command-W is that you might have a different window in focus, so sometimes you will end up closing the wrong one by mistake.

Training

Once you have chosen which to use, train yourself rigorously to use that, and that alone. When working with single-window apps you have the choice of using either, and you should consciously go through the process of thinking that through before deciding which control to use, to remind yourself of what you are doing and why.

The goal is to make closing windows and quitting apps, including Safari, thoroughly reliable processes, so you never make a mistake. That makes any warning alert superfluous, and you’ll then agree that it would only serve to irritate. That’s why better interface guidelines caution against displaying an alert unless there’s a compelling reason to do so, and not routinely whenever quitting an app.

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.

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.