Juli Clover (Mr. Macintosh, 9to5Mac):
Right now, there is a bit of a bug with the beta that is preventing Apple silicon Macs from being able to download it. Intel Macs can be updated with no issue, but Apple will need to address the server side bug before it will be available to everyone.
I can confirm that, once again, Software Update isn’t working. But you can download the full installer manually.
Again, the release notes don’t seem to say what’s new.
Howard Oakley:
Apple’s operating systems provide support for encryption and related techniques in CryptoKit, making quantum-secure methods available to third-party apps as well. For OS 26, CryptoKit gains Module-Lattice based key encapsulation or ML-KEM, part of the FIPS 203 primary standard for general encryption. Signatures gain the Module-Lattice based digital signature algorithm or ML-DSA, part of FIPS 204.
Steve Troughton-Smith:
I’m very ready for a beta 3 of the new OSes; beta 2 has been mostly usable, but has lots of little blockers getting in the way of progressing my apps
Previously:
Update (2025-07-07): The full installer didn’t work for me, either. After a long time, it reported an error failing to prepare the update.
Update (2025-07-08): The same installer worked this morning.
Mr. Macintosh:
This is the new macOS Tahoe Installer
Mario Guzmán:
After installing #macOSTahoe b3, I got a new wallpaper! :)
[…]
I think these icons are also new/updated in #macOSTahoe b3…
Mr. Macintosh:
Apple has added the new Tahoe wallpaper via image and active video .heic for both the blue background and beach background wallpaper images.
Marcus Mendes:
Much like on tvOS, Apple recently introduced native video screen savers on macOS that transition smoothly into the wallpaper upon unlocking.
With today’s beta seed, Apple included a new “Tahoe Day” screen saver that glides across the surface of Lake Tahoe’s rocky shoreline, with snow-capped mountains in the background.
This is pretty nice, but I had to turn it off on my Tahoe Mac because I mostly control it via Screen Sharing, and this makes it really slow.
Marcus Mendes:
One of the most common complaints in macOS Tahoe 26 betas 1 and 2 was the new tab UI in apps like Safari and Terminal, which added a black bar to the bottom of inactive tabs.
[…]
Now, Apple has increased contrast and eliminated the black bar, making it much easier to spot the active tab at a glance.
Mario Guzmán:
Native Tabs in #macOSTahoe still suck but at least they have fixed a lot of the visual issues from beta 1 and 2.
Thomas Brand:
Since the earliest rumors of transparent UI, I thought Tahoe would adopt the “frosted” look of visionOS.
With the release of Tahoe beta 3 I could be convinced frosted was Apple’s plan all along, and the initial renders of liquid glass were merely a faint to get an extreme reaction.
Craig Grannell:
Someone – probably multiple people – at Apple signed this off. The ‘glass’. The lack of clarity. The absurd floating back/forward buttons that become the most visually prominent thing in the window. All of it.
Reduce Transparency makes things slightly less awful but it still weird and ugly. Best bet appears to be Reduce Transparency + a solid colour (ideally grey) for wallpaper.
(This is dev beta 3.)
We’re, what, about eight weeks and counting now?
Jonathan Wight:
So i guess now that we’re at b3 the blurry icons are here to stay…
Now we can all experience what it is to have old person eyes.
Steve Troughton-Smith:
It’s beta 3 of macOS and Apple still seems to be really struggling to deal with the floating sidebar in AppKit. It still has hard cut offs in various apps, and now it renders under a toolbar in fullscreen mode.
Stephan Michels:
I noticed a similar cut-off in my app. The glass effect have a very wide shadow, which doesn’t not spread across containers, in my case a scroll view without background. Ugly 🧐
Steve Troughton-Smith:
🤔 [System Settings]
Riccardo Mori:
Glass and transparency can be fun when used meaningfully. Look at the battery indicator in Mac OS X 10.0.3. It wasn’t a menu extra, but a live indicator in the Dock (called ‘dockling’).
Sindre Sorhus:
Menu item icons in macOS 26 reduce usability – should be optional
Liquid Glass Mac macOS Beta macOS Tahoe 26 Safari Screensaver Software Update System Preferences Terminal Wallpaper
Craig Grannell:
In beta 2, Apple added an option to restore the menu bar background. Which is good. Except it also makes me question Apple’s confidence in its design work. When Apple starts hedging its bets, it signals that it knows something is wrong, but lacks the conviction to course-correct. Or perhaps such settings are a means to temporarily shut people up, while default choices reveal the true intent and direction of travel.
On iPad, things are even worse. I’m a fan of the new windowing system, but the menu bar implementation is dreadful. The problem isn’t its auto-hide behaviour – the Mac has had something similar (although off by default) since 2015. Again, the issue is that Apple is so enamoured with transparency that it’s sacrificing visual clarity.
Unfortunately, the ‘fix’ on iPad isn’t yet anywhere near as full as the Mac one. In beta 1, a two-up window view could see menu bar text vanish entirely. In beta 2, Apple added a subtle gradient, which barely helps. Honestly, this is embarrassing – the sort of thing a design student wouldn’t hand in as part of a project. A menu bar coming to iPad is great, but not if you can’t read its text.
Pierre Igot:
You do wonder what the internal processes are[…]
They’ve been trying to get rid of the Mac menu bar’s bar for about 18 years now. I don’t understand why.
Matt Birchler:
In this case, the Mac actually has notably larger touch targets than the iPad version. This one is particularly notable for me because the menu has long been the go-to example for why touch on the Mac would not work, and yet the iPad has an even smaller one.
Previously:
Design iPadOS iPadOS 26 Liquid Glass Mac Mac OS X 10.5 Leopard macOS 11.0 Big Sur macOS Tahoe 26 Menu Bar
Tor Arne Vestbø:
As it turns out, permissions are inherited by child processes. And when a process is about to access some protected resource, the TCC subsystem figure’s out which process is the responsible one, and uses that as basis for requesting and persisting the result.
[…]
In the case of an application embedding and launching helper executables this behavior of course makes sense, but it can be a bit surprising in cases such as launching apps from the terminal.
[…]
As it turned out, since Qt Creator was launching user applications when running and debugging, it was effectively becoming the responsible process for all these user applications. And if one of them required a permission that needed a corresponding usage description, then the only way to make the application work was to add the description to the responsible process; Qt Creator.
[…]
Somehow lldb
was circumventing the logic that was deciding which process was the responsible one.
Luckily LLDB is part of the open source LLVM project, so I was able to track it down to this change, with the magic formula:
int responsibility_spawnattrs_setdisclaim(posix_spawnattr_t attrs, int disclaim);
He says it “just works” with Xcode, though he isn’t sure why, but my experience is that often neither Xcode nor the app prompts for Automation or Contacts access when running an app or testing and so the APIs just fail.
Via Peter Steinberger (tweet):
If you’re building a macOS CLI that uses AppleScript, you need to embed an Info.plist into your binary, sign it with proper entitlements, and optionally use the undocumented responsibility_spawnattrs_setdisclaim
API to avoid permission dialogs that blames the hosting app.
[…]
Getting AppleScript to work in a CLI tool turned out to be a maze of undocumented APIs, security permissions, and macOS quirks that nobody warns you about.
Previously:
AppleScript Code Signing Cursor Entitlements LLDB Mac macOS 10.14 Mojave macOS 10.15 Catalina macOS 15 Sequoia Programming Qt Transparency Consent and Control (TCC) Xcode
OSXDaily:
If you have discovered your Mac disk space has reduced since installing or updating to MacOS Sequoia, the inordinately large com.apple.mediaanalysisd cache file issue could be to blame. A variety of Mac users have reported the directory being filled with 15GB+ of data, with some users noting 50 GB, 80 GB, even 140GB of cache files, filling users entire disk drives with the cache bundle files.
Let’s review what the directory is, and how to recover your disk storage space.
[…]
With one user on Apple discussions reporting up to 140 GB of medianalysisd cache files on their Mac, and another on Rumors Forums reporting 80GB of caches, there are also multiple other mentions of this on everywhere from stackexcahgne, reddit, MacRumors Forums, and the official Apple support forums. How widespread the issue is is not clear, and if any particular feature or combination of settings triggers the huge medianalysisd cache folder, or if it’s just a bug, is currently unknown.
Via Full Report Below:
On my machine, com.apple.mediaanalysisd is using no less than 143GB. For a 27 GB photo library.
Paul Hudson:
mediaanalysisd has regularly been sitting on ~100% CPU for over a week now. My laptop is hot to the touch, and I have no idea why. Rebooting didn’t help. Suggestions?
Daniel Berezhnoy:
I think I be had the same problem the last 2 weeks. Can’t figure out why!
See also: Apple’s forums.
Previously:
Mac macOS 15 Sequoia Photos.app Storage