Archive for March 23, 2026

Monday, March 23, 2026

Liquid Glass Is Permanent

Danny Bolella (Reddit):

If you read the comments on my articles or browse the iOS subreddits, there is a vocal contingent of developers betting that Apple is going to roll back Liquid Glass. […] I shared this exact sentiment with the Apple team.

Their reaction? Genuine shock. They were actually concerned that developers were holding onto this position. They made it emphatically clear that Liquid Glass is absolutely moving forward, evolving, and expanding across the ecosystem.

Their exact warning to me was that those who don’t adopt it now “are gonna find themselves in a tough position later.”

[…]

We had them confirm the hard truth: Xcode 27 will absolutely not have the deferral flag, and it will not respect it if you leave it there, anyway. When Q1 2027 rolls around and Xcode 27 becomes the mandatory minimum for compiling to the App Store, glass will be enabled globally, period.

Jeff Johnson:

What’s truly astonishing about the macOS Tahoe UI is that it’s now been SIX MONTHS since Tahoe was released to the public, yet it’s still full of glaring bugs. […] So many little things are off, out of alignment. It’s like Apple rushed out an alpha version.

Bolella:

The Apple engineers explained that a massive part of the initial Liquid Glass rollout was simply ensuring the foundation was solid. It had to be functional, it had to meet incredibly strict styling guidelines across every single Apple platform, and most importantly, it just had to work.

[…]

The team was visibly enthusiastic about what is in store for WWDC26 and Xcode 27. While they wouldn’t drop any specific spoilers, they gave the very strong impression that this upcoming cycle is where Liquid Glass takes its first massive step into maturity.

Jeff Johnson:

This is the Safari search field on Tahoe. Notice the position of the clear button.

John Gruber:

Perfect MacOS 26 Tahoe screenshot from the Journal app. Apple shipped this.

Simon B. Støvring:

Liquid Glass is a catastrophe.

Dave Mark:

I have SO many examples of this. Text fields that are cut off, text color choices that render text completely unreadable. In this regard, Apple design has lost the thread.

Leon:

the thing about modern Apple UI is they go for some deeply flawed vision that seems developed in a vacuum away from third parties, accessibility experts and engineers, and then when that fails they water it all the way down until people say “huh okay this isn’t that bad any more”

it just lurches from catastrophe to milquetoast and back again, with most of the time firmly in milquetoast territory

what i’d love, love to see is them - or anyone - come up with is a system vision that bakes in accessibility and pro / studio app design first.

Previously:

Disk Image Performance With macOS 26.3.1

Howard Oakley:

This table summarises read and write performance of the most popular types of disk image prior to macOS Tahoe, and demonstrates how sparse bundles have consistently performed best and most consistently, and sparse images (now dropped from Disk Utility’s options) fare worst, particularly when encrypted.

Howard Oakley:

Although most of the test results in macOS 26.3.1 are very similar to those from 26.0, performance when using 256-bit AES encryption has fallen for all three disk image types, and most significantly in write performance for RAW and ASIF images, which have reduced from 4.3 to 1.58 GB/s (RAW) and from 3.9 to 1.72 GB/s (ASIF). The magnitude of those reductions is sufficient to have obvious impact on their use. Compared to native write performance using FileVault of 7.66 GB/s, those two types of disk image are pedestrian in the extreme, turning that blisteringly fast SSD into the equivalent of 20 Gbps over USB 3.2 Gen 2×2.

[…]

When their folder-based structure is acceptable, UDSB sparse images remain the disk image type of choice, for their consistent high performance even when encrypted.

[…]

As [ASIF] sparseness isn’t dependent on APFS trimming habits, they are now an alternative that can be used on network storage and NAS. However, those able to use sparse bundles should continue to do so, particularly if using encryption.

Previously:

Provisioning Profiles in Mac VMs

Quinn:

There may be other outstanding issues, but you can now:

  • On a macOS 15 or later host, install macOS 15 or later in a VM.
  • On the guest, log in using an Apple Account in System Settings.
  • And install Xcode.
  • And add your Apple Account to Xcode.
  • And then build and run a Mac app.
  • Even if it uses a restricted entitlement.

Via Craig Hockenberry:

It’s a momentous day for Mac developers: you can now provision a device running in a VM. Whether you use VirtualBuddy, UTM, or another app, Xcode can now build, run, and debug apps on multiple versions of macOS without having to reboot.

This includes apps that have entitlements for iCloud and other Apple services.

[…]

Essentially, we now have a setup like the iOS simulator where you can work on two versions of the OS simultaneously. That’s a huge boost for developer productivity!

[…]

One thing you cannot do in a VM: use your Apple ID to login to the Mac App Store. So no testing your shipping app version.

This also means you can’t run TestFlight builds, because you can’t download the app from the store.

Previously: