In the early years of this blog, I used to keep track of some of the more serious bugs in macOS. As that developed into what would have occupied me full-time, I’ve cut back to try to cover some of the most significant. What has surprised me with macOS 26.1 is the sudden rush of new bugs in an update that’s normally expected to fix more than it creates. To consider what might have gone wrong, here’s an overview of those I’ve been investigating so far.

macOS virtualisation (new in 26.1)

A macOS 26.1 guest assigns itself a serial number of zero for the VM, whether the VM has been installed from the 26.1 IPSW image file, or updated from a previous version of macOS. This results in features that rely on the VM’s serial number to fail, the most important being access to iCloud.

Further details.

Virtualisation is exceedingly complicated, and has suffered some previous accidents, such as the inability of M4 hosts running macOS 15.1 to virtualise guests with macOS earlier than 13.4. Although it’s easy to claim that better testing should detect these problems, the number of combinations of host Mac and macOS, and guest macOS increases their risk. Perhaps Apple should actively encourage third-party beta-testing in VMs.

Accessibility (new in 26.1)

macOS 26.1 introduces a new Appearance setting for Liquid Glass, but Apple hasn’t mentioned any change to the existing Reduce Transparency setting in Accessibility. However, that setting in 26.1 no longer disables Liquid Glass effects in sidebars and toolbars as it does in 26.0. User documentation for 26.1 is identical to that in macOS 15:
Make transparent items solid
Some windows and areas of the desktop, such as the Dock and menu bar, appear transparent by default. You can turn these transparent areas a solid grey to make it easier to distinguish them from the background.

This can be seen in the following screenshots.

This is 26.0 without Reduce Transparency.

This is 26.0 with Reduce Transparency turned on. Both the navigation sidebar and the window toolbar are completely opaque, and their contents are fully readable as a result.

This is 26.1 with Reduce Transparency turned on. Although the tools themselves are on opaque backgrounds, other areas remain partially transparent, and the toolbar in particular is visually cluttered and impairs accessibility.

Although this could be claimed to be intentional on Apple’s part, one visual feature that now appears when Reduce Transparency is turned on is the unreadable mess at the top of the System Settings window, where its search box overlays scrolling content in that sidebar.

If that’s intentional on Apple’s part, then macOS 26.1 is unsuitable for users with most forms of visual impairment, and many without.

Finder (new in 26.1)

In some Finder views, such as Column View, selecting an item at the left displays that item’s thumbnail and associated metadata. Below those are a selection of tools offering Finder services, such as Rotate Left, Markup, and more. Those are non-functional in 26.1, and if you want to use any of those services, you’ll have to use an alternative method, such as the contextual menu.

Further details.

This is a strange bug, as it doesn’t occur in macOS VMs, suggesting there’s something more complicated going on. However, it’s also obvious, easy to test, and should never have survived into a release version of macOS.

Clock (macOS 15 and 26)

In macOS 15 and 26, including 26.1, the Clock app offers Timers that are implemented using the mobiletimerd service. The latter appears to hoard every past timer in its property list until that grows too large for the service to run, following which the feature fails to function.

Further details.

According to Apple Support, an earlier bug in the mobiletimerd property list was fixed in macOS Sequoia. However, Apple is apparently unaware of the current problem. The current behaviour of mobiletimerd appears to be the result of poor design: if a service keeps adding more items to its property list, that will grow unconstrained, and sooner or later will cause this problem. It’s possible that fixing the previous bug may have resulted in the introduction of a new bug. Either way, this should have been detected long before it was released to the public.

Spotlight indexing (macOS 10.14 and later)

Since macOS Mojave, plain text files starting with certain characters don’t have their content indexed. Those files are correctly assigned to have their contents indexed by the macOS RichText mdimporter, according to their UTI. However, at the start of content indexing the text is checked for its ‘magic’ content. Those files that aren’t indexed because their opening bytes are recognised as being those of other types, and indexing is abandoned because of an error in the mdimporter. Examples of opening UTF-8 characters that can trigger this include the uncommon LG and HPA, and more common Draw.

Further details.

This is the strangest bug among these, as the Rich Text mdimporter is supposed to index content according to the UTI of the file being indexed, which is being recognised correctly. There should be no need to perform another less reliable method of file type recognition using the ‘magic’ rules that is then causing content indexing to fail. That appears to have been introduced over seven years ago, but never tested adequately against a suitable search corpus.

The same mdimporter had suffered another bug that failed to index the content of any Rich Text file that was also undetected for over six months in 2020-21. Without thorough testing of mdimporters, further bugs are likely to occur in release code and remain undetected for long periods.

Conclusions

• Of these five serious bugs in macOS 26.1, three are new to 26.1, one inherited from macOS 15, and one dates back seven years to macOS 10.14.
• At least two of the five appear to have been introduced when trying to fix earlier bugs.
• All five should have become obvious during testing, and none should have remained in any public release of macOS.
• Both of the bugs that were inherited from macOS 15 appear to reflect flawed design.
• Only one of the bugs, that in virtualisation, is noted in Apple’s developer release notes for 26.1, and that wasn’t carried forward to its release notes for users.

Acknowledgements

I’m very grateful to Rich Trouton, Michele, Paul, Jürgen, Drew, aldous and others who have provided invaluable information about these bugs.

Here are two reports on bugs affecting macOS Tahoe 26.1 that might make you wait before updating.

macOS VMs can’t access iCloud

If you update a macOS virtual machine to 26.1, or create a new VM in 26.1, it loses its Serial number, which is apparently set as 0. Although most things you might do with a VM aren’t affected by that, it will prevent that VM from being able to access iCloud (if that has been enabled for the VM) and related features.

There’s no workaround for this, as serial numbers are created when the VM is first made, and the user can’t add or change them after that. If your VM needs access to iCloud, keep it running 26.0.1 instead.

I’m very grateful to Rich Trouton of Der Flounder for this information, which is also given in Apple’s developer release notes.

Finder Services

In some Finder views, such as Column View, selecting an item at the left displays the item’s thumbnail and associated metadata. Below those are a selection of tools offering Finder services, such as Rotate Left, Markup, and more. Those are non-functional in 26.1, and if you want to use any of those services, you’ll have to use an alternative method, such as the contextual menu.

I’m very grateful to Michele for letting me know of this.

If you know of any serious bug that is new to 26.1, please let me know and I’ll add it to this list after confirmation.

Virtual Machines running macOS on Apple silicon Macs are more versatile than the host they run on. When you want to create a new VM, or modify an existing one, there are some powerful options available.

One of the most useful is to duplicate an existing VM: as APFS will do that using clone files, and the virtual disk in a VM is stored as a sparse file, that will use much less disk space than making a completely new VM. If you’re likely to need a supply of VMs running the same version of macOS, why not create a base VM using the IPSW for that version, duplicate it, then set up each clone as you require?

For even more flexibility, you can increase the size of the VM as I have already explained. The only remaining problem is how you can migrate the contents of one VM to another. Although my previous attempts to do this had been unsuccessful, Michael was kind enough to provide the solution, and this article explains how to use Migration Assistant in two VMs running concurrently to copy the contents of one VM to another, on the same host Mac. This should also enable you to migrate between a VM and a Mac.

To perform a successful migration, Migration Assistant needs to connect to a mounted Data volume on local storage, or over a network. It can’t use a VM shared folder on the host as the source (server). If your virtualiser supports root level access to USB storage, enabling it to mount an external disk in the VM, then you should be able to migrate from a Time Machine or other backup on that disk. Migration can be performed during initial setup and customisation of macOS, or by running Migration Assistant later. In this walkthrough, I’ll use the former.

You need

To do this, the virtualiser has two fundamental requirements:

• it must be able to run two macOS VMs concurrently,
• you must be able to assign them different MAC addresses.

Apple enforces a limit of two macOS VMs running concurrently on the same Mac, a rule written into the macOS license. Although that might seem stingy, macOS isn’t like Linux and you can’t run Tahoe on a single core with a mere 3-4 GB of memory. However, if you can spare at least 3 P cores and around 12 GB of memory for each, there should be ample to perform a migration. In practice, that means the host Mac should have a total of eight or more P cores, and at least 32 GB of memory.

MAC addresses are supposed to be unique. As the connection between these two VMs is over your local network, your DHCP server must allocate them two different IP addresses, or they won’t be able to migrate. The way to ensure that works is to assign each VM its own and different MAC address.

My own free Viable satisfies both requirements. Here I’ll use that to set up a new VM as the migration client, using an existing VM as the server. For the sake of simplicity, I’ll assume the MAC address of the server is the default, and won’t change that.

Procedure

This uses two macOS VMs running at the same time:

• the destination for the migrated files is a new VM and is the migration client,
• the source of those files is an existing VM and is the migration server.

Start by installing the IPSW to create your new VM. Rather than going straight on to its first run, at this stage open the server VM with the default MAC set, log into it, and locate Migration Assistant in /Applications/Utilities ready to run.

Now change the MAC address in Viable’s window to something different. I used d6:a7:58:8e:79:d4 instead of d6:a7:58:8e:78:d4. Then open the new VM, the migration client, and take it through its configuration, opting to migrate to it from another Mac.

When you reach the screen that sets that up, open Migration Assistant on the server VM, and set it to transfer data To another Mac. Then switch back to the client VM, and you should see that server offered as the source for your migration. Select it and perform the PIN authorisation so they can connect.

On the client, select the items you want to migrate to that VM, and proceed.

After a few minutes, the migration should complete, allowing the client to finish setting up with its new user account. You can then shut down the server and reset the MAC address and other settings in Viable.

Summary

Viable’s narrative documents the sequence:

• Install the IPSW to create the new client VM.
• Start up the server VM with 3 cores and 12 GB memory, and the default MAC of d6:a7:58:8e:78:d4.
• Start up the client VM, with the same cores and memory, and a different MAC of d6:a7:58:8e:79:d4
• When the new (client) VM reaches the Transfer information to this Mac window, open Migration Assistant on the server (old) VM and set it to transfer To another Mac.
• Select the items to migrate on the new (client) Mac and proceed.

Apple’s instructions on migration are here.

Before macOS Tahoe, the biggest sticking point in virtualising macOS on Apple silicon Macs has been their lack of support for the App Store. From the outset this has been an ironic limitation. Here’s some of Apple’s most advanced technology running on its latest hardware, and it can’t even run the apps that Apple sells, only those supplied direct by their developers.

VMs can now have iCloud and iCloud Drive support, Messages, FaceTime, FileVault, and plentiful shared folders, but the one thing they have lacked that renders them useless for many users and many purposes is that can’t sign into Apple services, particularly the App Store. Some apps, including those in Apple’s iWork suite, will run in a VM despite it being unable to sign into your account, but you can only window-shop in the App Store, and most of its apps will simply refuse to run, even free ones.

I’ve long suspected that this is an example of Apple Commercial constraining Apple Engineering. To be useful, macOS VMs would have to be exempted limits on the number of Macs authorised to access services, and that could open up the possibility of third-parties bypassing FairPlay and the digital rights controls embedded in macOS. It must be deeply frustrating to those working on virtualisation, knowing that it could be done but won’t be.

So the only substantial new feature for macOS virtualisation in Tahoe is the introduction of ASIF disk images. For the time being, I’m not sure they’re going to change much for most of us who host our VMs on local APFS storage. As they still don’t enjoy proper API support, I don’t see any compelling reason to rush into their use, unless you want to host your VMs in the cloud.

Upgrading to Tahoe has, though, drawn attention to problems lurking for those who created VMs of 50 GB or smaller, who now want to enlarge them for this purpose.

Resizing VMs

Don’t skimp when creating a new VM. Give it a useful size, as its Disk.img is stored as a sparse file, so won’t take all that disk space unless you fill it to capacity. I now make my default VMs 100 GB to ensure there’s ample free for updates and anything else that might arise.

If you do have a treasured VM that’s too small, you may well be able to increase its size, either using Disk Utility or the hdiutil resize command tool if you prefer. To do this, start by duplicating your VM in the Finder. That creates a clone, and lets you fall back to the unaltered original if the resizing goes horribly wrong.

To resize the disk image using Disk Utility, you first have to move it out from inside its VM bundle, easily done in the Finder. Then in Disk Utility’s Images menu use the Resize… command, select that Disk.img and enter its new size. Add a little, around 8%, to allow for overheads, and let Disk Utility get on with the work.

Here’s Disk Utility inside this Tahoe VM, showing its 50 GB virtual disk.

I then resized it to just over 100 GB.

Here it is afterwards, now showing a full 100 GB.

I gather from others that resizing doesn’t always work. If you can’t get it to, then the only way forward is to create a new VM with the larger capacity and copy across the contents of your old VM. One obvious way to make that simpler and more thorough would be to use Migration, either during configuration of the new VM, or shortly afterwards.

I’m very grateful to Michael for telling us of his success in migrating from a small to a larger VM in Tahoe. I’m also more than a little jealous, as I’ve so far been unable to get it to work for me.

I’m also mystified as to how two macOS VMs running concurrently on the same Mac could establish a connection to support the file transfers required in migration. Neither can expose its virtual folders as shared folders for the other, and in any case shared folders are strictly circumscribed. Sharing them over AFP runs into a quirk of their bridged networking, that both of the VMs will default to using the same network IP address. In my failed tests, the destination Migration Assistant was able to recognise the source, but failed to connect to it successfully.

For the moment macOS virtualisation hasn’t made any substantial improvements in Tahoe. It still can’t sign into Apple services, and AI remains unavailable. Let’s hope the next year brings more and better, and realises more of its potential.