Archive for December 19, 2025

Friday, December 19, 2025

Tahoe Display Flicker

Juli Clover:

Mac users with the Studio Display have been complaining about intermittent flickering since the update launched in September. There are also complaints from users who have other kinds of displays, so it might be a bug that is affecting more than one type of external monitor.

We have experienced this issue with a MacBook Pro running macOS Tahoe connected to a Studio Display, and the macOS Tahoe 26.1 and macOS Tahoe 26.2 updates haven’t improved the situation at all. In fact, the flickering seems to be getting worse in recent days.

Dan Moren:

I’m glad this is finally gaining some attention because I have been seeing this since the earliest betas of Tahoe back in June (I complained about it again more recently). And that’s been on multiple Macs, including my Mac mini attached to a Studio Display, my old M1 MacBook Air, and my current M4 MacBook Air.

Oliver Haslam:

It’s thought that this dithering causes a flickering effect which, in some cases, can even cause headaches. Thankfully, a third-party utility called Stillcolor can override the display controller’s behavior.

Disabling dithering via Stillcolor is reported to have fixed the issue for some. Unfortunately, others say it hasn’t worked for them, so your mileage may vary.

Previously:

Update (2025-12-22): eric:

wow I thought I was losing my mind of my m4 Mac mini was going south. I don’t see it in my work MBP without Tahoe.. didn’t think it was the OS but I guess it is! It’s not bad and infrequent but unnerving either way.

Update (2026-01-09): Max Seelemann:

Today my Studio Display started to flicker.

Passwords.app and Magic Links

John Gruber:

There are many sites — and the trend seems to be accelerating — that do not use passwords (or passkeys) for signing in. Instead, they only support signing in via expiring “magic links” sent by email (or, sometimes, via text messages). To sign in with such a site, you enter your email address, hit a button, and the site emails you a fresh link that you need to follow to sign in. I despise this design pattern, because it’s inherently slower than signing in using an email/password combination that was saved to my passwords app and autofilled by my web browser.

[…]

To make matters worse, when you create a new account using a “magic link”, nothing gets saved to Apple Passwords. I don’t have many email addresses in active use, but I do have several. Sometimes I don’t remember which one I used for my account on a certain site.

[…]

One workaround I’ve used for a few sites with which I keep running into this situation (Status, I’m looking in your direction) is to manually create an entry in Apple Passwords for the site with the email address I used to subscribe, and a made-up single-character password. Apple Passwords won’t let you save an entry without something in the password field, and a single-character password is a visual clue to my future self why I did this.

I have also run into this friction where the Passwords app insists I not leave the field blank but there’s nothing that really makes sense to put there.

I’d always assumed that sites used magic links because people don’t remember their passwords, and it’s easier to click a link than to go through the password reset process each time. But Gruber notes that magic links are also an effective way to combat account sharing.

Previously:

You actually can create password entries without passwords because there’s a bug in the app where the (command)+S keyboard shortcut works even when the UI button to save is disabled

Hudlum 1.0

Peter Maurer:

The volume indicator, on the other hand, is most important to me when there’s currently no sound playing, e.g., because I want to confirm my system is muted (or at least not in “yell loud enough to wake everyone in the house” mode) before I start playing a video. And I’d rather do that without having to squint at a tiny slider on a fuzzy-glassy background in an inconvenient spot way outside of my center of attention. A tiny slider on a fuzzy-glassy background in an inconvenient spot way outside of my center of attention, I might add, that doesn’t always update properly when I hit the mute/unmute key.

[…]

Enter Hudlum, the nostalgic retro HUD-style system volume indicator for dinosaurs[…] As silly as it may seem, this helped me make peace with macOS 26.

Previously:

Backblaze No Longer Backs Up Dropbox

Rob Halliday:

It appeared that Backblaze was now just not backing up Dropbox AT ALL, and was discarding (without warning) existing backups of Dropbox folders.

I contacted Backlbaze tech support. Janet their ‘AI Agent’ who is “well-trained to answer your questions” (!!), responded an hour or so later saying that Backblaze now basically do not back up Dropbox as of a recent update to the Mac Backup software.

[…]

Working back through the Backblaze release notes, this change happened in 9.2.2.878. The release notes page does not include release dates for software versions, so there is no way of telling when this change happened.

[…]

If I hadn’t discovered this by accident today, I might not have found out until too late. I suspect this is why I haven’t managed to find more outcry about it on the web today - I suspect this applies to a lot of people, who know this has been working fine and haven’t yet noticed that it’s now broken. Yes, it’s in the release notes, but a change like this should, I feel, be displayed VERY PROMINENTLY as part of an update, or an update causing a change this dramatic should not be forced on users automatically.

I’ve had concerns about Backblaze for a long time, but this is a new low.

Previously:

Update (2025-12-22): It seems like Backblaze now also excludes iCloud Drive and OneDrive but not Dropbox via Maestral. This seems to not be due to Dropbox using the File Provider Extension framework, and it’s not overridable at the user level, so I guess there’s some sort of built-in exclusion. CrashPlan also no longer backs up Dropbox. Arq can still back up all this stuff.

Update (2026-04-08): Backblaze:

Recent updates to macOS and iCloud prevent us from backing up files that remain iCloud-managed, even if they appear “downloaded” in Finder.

This change affects files stored in iCloud Drive folders that macOS controls via cloud sync, including the ~/Library/Mobile Documents directory. Simply disabling “Optimize Mac Storage” alone is not sufficient anymore - files that remain inside iCloud-managed folders cannot be backed up due to Apple’s iCloud architecture restrictions.

[…]

This limitation is caused by Apple’s recent iCloud updates that restrict third-party backup access to cloud-managed locations. We can only back up local data and cannot override Apple’s iCloud controls.

I don’t understand why they are saying that the change is due to Apple and that it affects even files that are locally cached. Other apps are able to read the files, and other backup apps such as Arq are even able to temporarily materialize files that are not locally cached.

Update (2026-04-09): This claim is now in the Backblaze documentation:

iCloud’s most recent update prevents Backblaze from backing up files that iCloud synced.

To back up these files, download them to another local location where Backblaze can read them.

Update (2026-04-14): Robert Reese (via Hacker News):

No problem I thought, I’ll just restore this from Backblaze. Sadly it was not to be. At some point Backblaze had started to ignore .git folders.

This annoyed me. Firstly I needed that folder and Backblaze had let me down. Secondly within the Backblaze preferences I could find no way to re-enable this. In fact looking at the list of exclusions I could find no mention of .git whatsoever.

[…]

Well lesson learned I guess, but then a week ago I came across this thread on reddit: “Doesn’t back up Dropbox folder??”. A user was surprised to find their Dropbox folder no longer being backed up. Alarmed I logged into Backblaze, and lo and behold, my OneDrive folder was missing.

He’s a Windows user—so the change can’t be blamed on Apple—and quotes the Backblaze release notes as saying that cloud files are excluded to prevent “performance issues” and “excessive data usage.”

Update (2026-04-21): natasha_backblaze:

To give a bit more context on the “why”: these cloud storage providers now rely heavily on OS-level frameworks to manage sync state. On Windows, for example, files are often represented as reparse points via the Cloud Files API. While they can appear local, they are still system-managed placeholders, which makes it difficult to reliably back them up as standard on-disk files.

Moreover, we built our product in a way to not backup reparse points for two reasons:

  1. We wanted the backup client to be light on the system and only back up needed user-generated files.

  2. We wanted the service to be unlimited, so following reparse points would lead to us backing up tons of data in the cloud

We’ve made targeted investments where we can, for example, adding support for iCloud Drive by working within Apple’s model and supporting Google Drive, but extending that same level of support to third-party providers like Dropbox or OneDrive is more complex and not included in the current version. 

Jim-From-Backblaze:

First and foremost, Backblaze Computer Backup was built with one overarching goal in mind: to back up all of your data on Mac and Windows computers. To do it simply, easily, and without much user interaction needed.

This backup covers unlimited data on the computer itself as well as internal drives and external drives that are physically connected to the computer.

That part has not changed.

What has changed is how some third-party cloud-sync tools store files on your computer.

Modern tools like OneDrive and Dropbox don’t always keep full files locally anymore. A lot of the time, what you’re seeing in Explorer/Finder is a placeholder, basically a pointer back to the cloud, not the actual file sitting on disk.

This seems completely at odds with Backblaze excluding even files in cloud folders that are not pointers back to the cloud.

Update (2026-05-01): Natasha Rabinov:

We’ve successfully added support for iCloud Drive and Google Drive by working within those platforms’ models. Extending the same support to every sync provider is more complex, but it’s something we’re actively exploring.

Christian Selig:

Dang Backblaze is memory hungry on Tahoe, what are we using 33 GB of RAM for?

See also: Accidental Tech Podcast.

Update (2026-05-04): zkarj:

I and others have checked and confirmed that stuff in Documents (and Desktop) is being backed up, but stuff in all other parts of iCloud Drive (e.g. the default folders for Pages, Numbers, etc) is not being backed up.

David Carlton:

As per an interaction I had with Backblaze support, they’re intentionally not backing up files that are in directories under com~apple~CloudDocs, which is where standalone iCloud Drive directories live.

Ivan Drucker:

I just discovered ~/Library/CloudDocs and ~/Library/Mobile Documents missing from a BackBlaze backup. Not happy. Using client 9.2.2.898.

[…]

Also, on their “Back Up iCloud Drive” support page, they now have a banner at the top which says “iCloud’s most recent update prevents Backblaze from backing up files that iCloud synced. To back up these files, download them to another local location where Backblaze can read them.” That seems to suggest no iCloud Drive support at all, and the whole thing reeks of nonsense, and it contradicts the rest of the page and the blog post saying they have iCloud Drive working. “iCloud’s most recent update?” What does that even mean?