The macOS 15.2 update includes the second phase of AI support for Apple silicon Macs, introducing the Image Playground app, and integrated ChatGPT support in both Siri and Writing Tools. AI now extends support to several of the non-US variants of English, including English (UK), although non-English languages won’t gain support until next year.

Apple’s release notes are a real joy to read and contain more detailed information at last, including the following:

• Photos enhancements,
• Safari supports background images for its Start Page, tries to use HTTPS on all sites, and more,
• Sharing item locations in Find My,
• Sudoku for News+,
• Presenter preview for AirPlay,
• Pre-market quotes in Stocks.

Among the more significant bugs fixed is that Apple silicon virtualisation on M4 Macs can now open all VMs, including macOS guests before 13.4. For those running Ruby with YJIT enabled, this update should fix kernel panics with M4 chips. Further fixes are detailed in the developer release notes, and enterprise release notes are here.

Security release notes are available here, and list 42 entries including 4 in the kernel, none of which Apple reports may already have been exploited.

iBoot firmware on Apple silicon Macs is updated to version 11881.61.3, and T2 firmware to 2069.40.2.0.0 (iBridge: 22.16.12093.0.0,0). The macOS build number is 24C101, with kernel version 24.2.0.

Version changes in bundled apps include:

• Books, version 7.2
• Freeform, version 3.2
• iPhone Mirroring, version 1.2
• Music, version 1.5.2
• News, version 10.2
• Passwords, version 1.2
• Safari, version 18.2 (20620.1.16.11.8)
• Screen Sharing, version 5.2
• Stocks, version 7.1
• TV, version 1..5.2
• Tips, version 15.2
• VoiceMemos, version 3.1.

Inevitably, there are many build increments in components related to Apple Intelligence, and a great many across private frameworks. Other significant changes to /System/Library include:

• Screen Time, build increment
• Siri, version increment
• VoiceOver, build increment
• Kernel extensions including AGX… kexts, AOP Audio kexts, AppleEmbeddedAudio, AppleUSBAudio, and several virtualisation kexts
• One new kernel extension, AppleDisplayManager
• APFS to version 2317.61.2
• Most of the Core frameworks have build increments
• FileProvider framework, build increment
• Virtualisation framework, build increment
• PrivateCloudCompute framework, new version
• Spotlight frameworks, build increments
• New private frameworks include Anvil, AppSystemSettings (and its UI relative), AskToDaemon, many Generative… frameworks involved with AI, OSEligibility, TrustKit, WalletBlastDoorSupport
• Several qlgenerators have build increments.

After that lot, the next scheduled update to macOS Sequoia is in the New Year.

Among those things that never change in the Finder is a prominent bug that has affected its column view for at least the last 11 years, back to OS X Mavericks if not before. During beta-testing macOS Sequoia last summer, I thought for a while that Apple had fixed it, but when I looked for the bug in the release version of macOS 15.0 it hadn’t even gone into hiding, and it’s still there today in 15.1.1.

I must have written about it here for the first time back in 2015, and for a while checking for it became an annual event, but over the last few years there seemed little point in whingeing about it any more. No one seemed bothered that the Finder couldn’t handle its column views properly, as Apple silicon Macs are so much more exciting. Every so often it comes back to bite me, and I’m reminded how annoying it is, so please bear with my catharsis.

Like many of the most persistent and annoying bugs, the Finder column width bug might seem tricky to reproduce, but when you normally work in column views it will return to haunt you.

It’s straightforward to demonstrate. Open a new window in the Finder, and ensure it’s set to Column View. Select your Documents folder in the sidebar, then select another folder containing more files and folders in the first column, within Documents. It helps if some of those have long names, so they’re truncated using an ellipsis … in the name.

Now click on your Applications folder in the sidebar to switch to that. Select an app, ideally one with a long name that has also been truncated with an ellipsis.

Then click on the Back button to switch back to your previous view of the folder within Documents. More often than not, you’ll now see the second column fill the remaining width of the window, and browsing any deeper into those folders is almost impossible, as the column width settings have gone haywire.

The simple way to recover is to select a different folder in the first column, which should restore orderly column widths.

While this might appear to be obscure, and unlikely to trouble anyone in normal use, there’s one situation that causes it to occur frequently, when you like to park your Finder windows in column view, with two columns shown in the view, as in the first screenshot above. Because of this I have changed my behaviour over the last few years, and now leave Finder windows with just the first column filled, a solution I worked out over four years ago. But any lapse in concentration allowing me to park a window in the wrong configuration makes it likely the bug will return and bite back.

Over those 11 years, governments have come and gone, my grandchildren have grown up and one is now at university, we survived Covid, lost QuickTime and 32-bit code, and now use Apple silicon Macs. But one thing has remained unchanged through all of that, the Finder column width bug.

If you’ve already got a new M4 Mac and tried to run a macOS virtual machine on it, then you might have been disappointed. It seems that M4 chips can’t virtualise any version of macOS before 13.4 Ventura. So before you trade in or pass on your M1, M2 or M3 Mac, if you need access to older VMs, you might like to check whether this affects you.

I’m indebted to Csaba Fitzl for drawing my attention to this problem, and for reporting it to Apple in Feedback FB15774587. It has also been reported as affecting UTM, and I believe affects all other macOS virtualisation software for Apple silicon.

The bug

Running a macOS VM for any version before 13.4 Ventura on an M4 Mac results in a black screen, and the VM fails to boot. This is true whatever settings are used in the virtualiser, even if it’s set to boot the VM in Recovery mode. It’s also true when that VM has been built on that Mac: although that appears to complete successfully, when first run that VM opens as a black screen and never proceeds with personalisation and setup.

Currently the only way to run a VM with macOS prior to 13.4 Ventura is to do so on a host with an M1, M2 or M3 chip.

Can this be fixed?

Unfortunately, as this bug prevents the VM from booting, there’s no reliable way to access its log to discover what’s going wrong there. There’s no sign of the failure in the host’s log either: the host appears to initialise its Virtio and other support normally, without errors or faults. After those, virtualisation processes on the host fall silent as they wait for the VM to start, which never happens.

There is a useful clue in Activity Monitor, though: in its CPU pane, despite being allocated multiple virtual cores, only one is seen to be active on the host. That implies the failure is occurring before the VM kernel boots the other cores, an event that occurs early during the kernel boot phase. Until that point, pre-boot phases and the kernel run on just a single CPU core.

macOS 13.4 updated iBoot to version 8422.121.1, so at first sight the VM could be failing when running older firmware. That doesn’t appear likely, as version 8422.121.1 was also installed in the 12.6.6 security update, so 12.7.x shouldn’t suffer this problem, but it does.

It thus appears most likely that this bug strikes in the early part of kernel boot, in which case the most feasible solution would be to fix the bug in macOS kernels prior to 13.4, and promulgate new IPSW image files for those. I suspect that’s very unlikely to happen, and as far as I’m aware it would be the first time that Apple has issued revised IPSWs.

Which macOS can you virtualise?

Support for lightweight virtualisation of macOS on Apple silicon Macs was still in progress in the first version of macOS to run on M1 chips, Big Sur. You therefore cannot create or run Big Sur VMs.

The first versions that can run in VMs are macOS 12 Monterey, although prior to 12.4 they can sometimes be a bit fractious. They also have major limitations, such as not supporting shared folders with the host.

This is 12.1 with its old System Preferences, running happily on an M3 Pro.

macOS Ventura should run well on M1, M2 and M3 hosts, and 13.4 and later on M4 hosts too.

macOS Sonoma should run even better on all current Apple silicon Macs, and delivers a much improved display with autoscaling. However, 14.2 and 14.2.1 don’t automatically support shared folders because of a bug that was fixed in 14.3.

macOS Sequoia is fully compatible, and adds support for iCloud Drive and some other Apple Account features, although still won’t run App Store apps. It may also fail to install the required extras to support Apple Intelligence.

Summary

• Currently, M4 Macs can only run VMs of macOS Ventura 13.4 and later, 14 Sonoma, and 15 Sequoia.
• M1, M2 and M3 Macs can run VMs of macOS Monterey 12.0.1 and later.
• macOS Big Sur 11 can’t be virtualised on Apple silicon.

Further information

Viable and virtualisation
Why macOS 14.2 & 14.2.1 VMs lose shared folders, and how to work around it

Postscript

I’m grateful for the suggestion that it might be possible to work around this problem by running the older VM on a single core. Although I did manage to do that on an M3 (the first time I have seen recent macOS running on just one core!), that fails just the same on an M4, I’m afraid.

The most distinguishing feature of Doctor Who’s TARDIS is that it’s much smaller on the outside, only capable of accommodating a couple of people at a squeeze, but huge on the inside. Allow me to introduce you to a sparse bundle that’s similar, in that its bundle size is only 14 MB, but the size of its internal band files comes to a total of over 90 GB. Here’s how to make yourself one.

Method

To do this, you need an Intel or Apple silicon Mac running Sequoia 15.0 or 15.0.1, and an external SSD. A hard disk might do, but I haven’t tried it.

Connect and format the external SSD in APFS, using Disk Utility. Then create an empty sparse file with the following specifications:

• Size: 10 GB or more
• Format: APFS
• Encryption: none
• Partitions: Single partition – GUID Partition Map
• Image Format: sparse bundle disk image.

Save that to the external SSD at its top (root) level. As Disk Utility leaves your new sparse bundle mounted, unmount it, wait a few seconds, then double-click it to mount it again. Copy one or more large files to the mounted sparse bundle. With a bundle size of 10 GB, something around 5-6 GB should be ideal, but the sky’s the limit if you created a large sparse bundle to begin with.

Once that’s complete, unmount the sparse bundle, then select it on your external SSD and press Command-I to see the Get Info dialog.

Although the size will vary slightly, in my case, with a nearly full 125 GB sparse bundle, the Finder reports its size as 13.8 MB, or 14.8 MB on disk.

So where did all that file vanish to? Has APFS somehow made it into a sparse file? Sadly not: view the contents of the sparse bundle, select its band folder containing all the band files with your data, and its size will be much bigger than that of the bundle. In my case, that’s 92.7 GB in more than 10,000 band files.

There’s your TARDIS: a 13.8 MB sparse bundle containing over 90 GB of band files.

Breaking the illusion

Once you’ve created your TARDIS sparse bundle, you can see its magic still works when you connect that external SSD to another Mac. But there’s one thing that will break the magic spell: create a folder in the same volume, and move the sparse bundle inside that. If you then mount it and add a file, you’ll see it suddenly expand to its full bundle size. Similarly, if you repeat the whole trick, but this time save the sparse bundle inside a folder, then it won’t work. This is why you can only do this on an external SSD, as you can’t write anything to the top level of your boot disk.

I don’t know whether this works with other bundles, such as VMs for Apple silicon Mac virtualisation, but it might be interesting to try it.

Act now, don’t wait

While this remarkable bug is present in macOS Sequoia 15.0 and 15.0.1, I’m afraid its days are numbered. If you want to experience the TARDIS sparse bundle, you’ve only got another week or two, as it appears to be fixed in the current beta of 15.1. For once, I’ll be a little sad to see a bug fixed, although when I discovered it, it couldn’t have been more infuriating.

刚才有一两秒，我的耳朵出现了一些 bug：

右耳突然无声，类似开了降噪，同一时间，左耳突然听到了一些现场不存在的环境声，类似通透模式里叠加了街道的背景音。整个过程是在办公室里发生的，耳机就在面前充电，没有戴着，没有外界音源。现象持续了大概不到两秒，就自行消失了。

不知道这是我的 bug，还是这个世界的 bug。