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.

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

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

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

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

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

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

Happy virtual Tahoeing!

In computing, the term Quality of Service is widely used to refer to communication and network performance, but for Macs it has another more significant meaning, as the property that determines the performance of each thread run on your Mac, most importantly in Apple silicon chips.

Processes and threads

Each process running on your Mac consists of at least one thread. Threads are single flows of code execution run on one CPU core at a time, sharing virtual memory allocated to that process, but with their own stack. In addition to the process’s main thread, it can create additional threads as it requires, which can then be scheduled to run in parallel on different cores. As all recent Macs have more than one core, processes with more than one thread can make good use of more than one core, and so run faster.

Take the example of a file compressor. If it’s coded so that it can perform its compression in four threads that can be run simultaneously, then it will compress files in roughly a quarter of the time when it runs on four CPU cores, compared with running on a single core (ignoring input and output to disk).

That only works when those four cores are all free. If your Mac is also trying to build its Spotlight indexes at the same time, the threads doing that will compete with those of your compression app. That’s where the thread’s Quality of Service (QoS) settings come in, as they assign priority. On Apple silicon Macs, a thread’s QoS will also help determine whether it’s run on its Performance or Efficiency cores.

Standard QoS settings

QoS is set by the process, and is normally chosen from the standard list:

• QoS 9 (binary 001001), named background and intended for threads performing maintenance, which don’t need to be run with any higher priority.
• QoS 17 (binary 010001), utility, for tasks the user doesn’t track actively.
• QoS 25 (binary 011001), userInitiated, for tasks that the user needs to complete to be able to use the app.
• QoS 33 (binary 100001), userInteractive, for user-interactive tasks, such as handling events and the app’s interface.

There’s also a ‘default’ value of QoS between 17 and 25, an unspecified value, and in some circumstances you might come across others used by macOS.

These are the QoS values exposed to the programmer. Internally, macOS uses a more complex scheme with different values.

CPU core type

When running apps on Intel Macs, because all their CPU cores are identical, QoS has more limited effect, and is largely used to determine priority when there are threads queued for execution on a limited number of cores.

Apple silicon Macs are completely different, as they have two types of CPU core, Efficiency (E) cores designed to use less energy and normally run at lower frequencies, and Performance (P) cores that can run at higher frequencies and deliver maximum performance, but using more energy.

QoS is therefore used to determine which type of core a thread should be run on. Threads with a QoS of 9 (background) are run on E cores, and can’t be promoted to run on P cores, even when there are inactive P cores and the E cores are heavily loaded. Threads with a QoS of 17 and above will be preferentially run on P cores when they’re available, but when they’re all fully occupied, macOS will run them on E cores instead. In that case, the E cores will be run at higher frequencies for better performance with less economy.

If your Apple silicon Mac has a base variant chip with 4 E and 4 P cores, this results in the following:

• apps with a total of up to 4 threads at high QoS will be scheduled and run at full speed on the P cores;
• when those P cores are all busy with high QoS threads, running another thread will then result in that being run on the E cores, and slightly slower than it would on a P core;
• a total of 8 high QoS threads can thus be run on P and E cores together;
• when running low QoS background threads on E cores, a maximum of 4 can be run at any time when the E cores are available, but those threads can’t spill over and run on the P cores, even if those are idle.

Controls

As QoS is normally either set by the process for its threads, or for services in their LaunchDaemon or LaunchAgent property list, the user has little direct control. A few apps now provide settings to adjust the QoS of their worker threads. Among those in the compression utility Keka, together with a couple of my own utilities such as the Dintch integrity checker.

In Keka’s settings, you can give its tasks a maximum number of threads, and even run them at custom Quality of Service (QoS) if you want them to be run in the background on E cores, and not interrupt your work on P cores.

Dintch has a simple slider, with the green tortoise to run it on E cores alone, and the red racing car at full speed on the P cores.

App Tamer and taskpolicy

The great majority of threads run at low QoS on the E cores are those of macOS and its services like Spotlight indexing. When a thread has already been assigned a low QoS, there’s currently no utility or tool that can promote it so it’s run at a higher QoS. In practice this means that you can’t accelerate those tasks.

What you can do, though, is demote threads with higher QoS to run at low QoS, more slowly and in the background. The best way to do this is using St. Clair Software’s excellent utility App Tamer. If you prefer, you can use the taskpolicy command tool instead. For instance, the command
taskpolicy -b -p 567
will confine all threads of the process with PID 567 to the E cluster, and can be reversed using the -B option for threads with higher QoS (but not those set to low QoS by the process).

That can be seen in this CPU History window from Activity Monitor. An app has run four threads, two at low QoS and two at high QoS. In the left side of each core trace they are run on their respective cores, as set by their QoS. The app’s process was then changed using taskpolicy -b and the threads run again, as seen in the right. The two threads with high QoS are then run together with the two with low QoS in the four E cores alone.

Virtualisation

Although Game Mode does alter the effects of QoS and core allocation, its impact is limited. The one significant exception to the way that QoS works is in virtualisation.

macOS Virtual Machines running on Apple silicon chips are automatically assigned a high QoS, and run preferentially on P cores. Thus, even when running threads at low QoS, those are run within threads on the host’s P cores. This remains the only known method of electively running low QoS threads on P cores.

Key points

• Threads are single flows of code execution run on one CPU core at a time, sharing virtual memory allocated to that process, but with their own stack.
• Apps and processes set the Quality of Service (QoS) for each of the threads they run.
• On Apple silicon chips, low QoS of background results in that thread being run on E cores alone.
• Higher QoS threads are preferentially allocated to P cores, but when they aren’t available, that thread will be run on E cores at high frequency.
• Some apps now provide controls over the QoS of their worker threads.
• App Tamer and taskpolicy let you demote high QoS threads to be run with low QoS on the E cores, but can’t promote low QoS threads to run faster on P cores.
• Virtual machines run all threads at high QoS as far as the host Mac is concerned.

Further reading

Apple’s Energy Efficiency Guide for Mac Apps, last revised 13 September 2016, so without any mention of Apple silicon.
Apple silicon: 1 Cores, clusters and performance
Apple silicon: 2 Power and thermal glory
Apple silicon: 3 But does it save energy?

Until last November, lightweight virtualisation of macOS on Apple silicon Macs had behaved uniformly across M-series families. Although I have heard of one report of problems moving VMs between Macs, those were built with custom kernels. In ordinary experience, VMs running on M1, M2 and M3 chips seemed not to care about the host’s hardware, and most of the time just worked, and updated correctly. There was one unfortunate glitch with shared folders that were lost in macOS 14.2 and 14.2.1, but otherwise VMs largely worked as expected.

Then last November disaster struck those of us who had just started using our new M4 Macs: they couldn’t virtualise any version of macOS before Ventura 13.4. Running a macOS VM for any version before that on an M4 Mac resulted in a black screen, and the VM failed to boot. That was fixed swiftly in macOS 15.2, and we no longer had to keep an older Apple silicon Mac around to be able to run those older versions of macOS in VMs.

Like many who virtualise macOS on Apple silicon, I keep a library of VMs with different versions so I can readily run tests on my apps and other issues. This is one of the great advantages of virtualisation, provided that you don’t rely on being able to run most apps from the App Store. When Apple releases new versions of macOS, once I’ve updated my Mac hosts, I turn to updating VMs. I’m normally cautious when doing this, to avoid trashing the original version. I duplicate the most recent, open it and run Software Update. When I’m happy that has worked correctly, I trash the original and rename the updated VM with its new version number.

That worked fine with Ventura 13.7.4 updating to 13.7.5, and Sonoma going to 14.7.5, but Sequoia 15.3.2 failed with a kernel panic, as I’ve detailed. When several of you kindly pointed out that M1, M2 and M3 Macs had no such problem, I confirmed on my M3 Pro that this is confined to hosts with an M4 family chip.

I have since tried updating my 15.3.2 VM to 15.4.1 on the M4 Pro, a surprisingly large update of over 6 GB, and that continues to result in a kernel panic and failure. I have also tried updating from 15.1 to 15.4.1 with an extraordinarily large download of more than 15 GB, only to see a repeat of the same kernel panic, with an almost identical panic log.

The macOS 15.4 update was particularly large, and some Apple silicon Macs were unable to install it successfully, most commonly on external bootable disks. From your reports, the 15.4.1 update seems to have fixed those problems with real rather than virtualised macOS. However, it hasn’t done anything to solve problems with VMs.

If you have an existing VM running any version of Sequoia prior to 15.4, then you’re unlikely to be successful updating that to 15.4 or later using an M4 host.

In contrast, upgrading a VM currently running Sonoma 14.7.5 completed briskly and without error. To my great surprise, that only requires a download of 8.7 GB, a little over half the size of the update from 15.1 to 15.4.1, which seems to be the wrong way round. The snag with upgrading from a previous major version of macOS to 15.x is that VM will never be able to use one of the most attractive features of Sequoia, iCloud Drive. If you want support for that, you’ll have to build a fresh VM using a Sequoia IPSW image file.

So for the time being, M4 hosts have a barrier between 15.3.2 and 15.4 that they can’t cross with an update. If you want a VM running 15.4 or later, then you’ll have to build a new one, or update 15.4 or later.

I don’t know and probably wouldn’t understand what changed in the 15.4 update, but it has certainly upset a lot of apple carts and VMs. And if you’d like a little homework, can you please explain:

• Update 15.1 to 15.4.1, download 15 GB, failure.
• Upgrade 14.7.5 to 15.4.1, download 8.7 GB, success.