❌

Normal view

Received — 9 August 2026 ⏭

Snow Leopard Lore

✇Michael Tsai
By: Michael Tsai
6 August 2026 at 20:31

Ruben Schade (Hacker News):

This idea is so powerful—and so longed for—that it’s escaped containment among the Apple crowd. I’ve seen everything from Linux distro to phone updates referred to as Snow Leopard releases, when their vendors cite stability and bug fixes over new features. Likewise, people plead with their vendors for a Snow Leopard release when they feel quality has slipped.

The reality was a bit different. As I wrote at the time[…]

People conflate a bunch of different ideas when talking about Snow Leopard:

  • Were there really zero no features? No, but there were fewer user-facing ones.
  • Was the initial release especially low in bugs? No, but it was better than Leopard’s.
  • Did it feel faster? Yes.
  • Was the final release especially low in bugs? Yes, it was fantastic.
  • Was it just because of the longer release cycle before Lion? No, they really did focus on quality for the initial release. And they didn’t add as much stuff mid-cycle as they did with Tiger and Leopard.

LegNeato:

Snow Leopard’s stated goal internally was reducing bugs and increasing quality. That is a fact, not marketing. I am not sure why people on the internet don’t believe that, but I was there. If you wanted to ship a feature you had to get explicit approval from leadership and the bar was high. In normal feature releases it operated bottom up “here is what we are planning to ship” and in Snow Leopard it was top down “can we ship this?”.

AFAIK Snow Leopard was the first release of this kind (the first release I worked on was Jaguar or Puma), and was a direct response to taking 8 software updates to stabilize 10.5 and the severity of the bugs found during that cycle and the resulting bad press. Leopard was a HUGE feature release and with it came tons of (bad) bugs.

[…]

Testing was basically engineers, internal QA, some strategic partners like Adobe and MS, and the Apple Seed program (which was tiny). There was very little automated testing. Apple employees are not representative of the population and QA coverage is never very complete. And we sometimes held back features from seed releases when we were worried about leaks, so it wasn’t even the complete OS that was being tested.

Software updates are always needed, though the issues they fix became less severe over time due to larger seeds (aka betas), recovery partitions, and better / more modern development practices. But I can tell you FOR A FACT that Snow Leopard had fewer major bugs over its lifetime, coalesced very quickly, and was extremely solid when Lion was released.

Ken Ferry:

I agree with you that Snow Leopard was billed as no USER VISIBLE features. But people did NOT just fix niggling bugs, it was an architecturally huge release. E.g., it introduced GCD. And unless I’m confusing the year, it rewrote the Mail backend to use it and mail hasn’t had reliable search since.

My memory is that quality was so low that we pushed back the release. With the extra time we did manage to fix enough bugs that it was well received. But internally it was more destabilizing than most releases due to the amount of architectural churn.

giantrobot:

Yeah as someone else that worked on Snow Leopard I found this article and ones like it a bit silly. They’re a lot like the old “debug code” posts on Mac forums back in the day trying to explain why Puma was slow (no, you’ve got a G3 and an unaccelerated video card).

Tiger and Leopard were sprawling releases. Tiger covered 32-bit and 64-bit PowerPC, then 32-bit x86, then 64-bit x86 Macs. Tiger was also what I guess I’d say is the first “modern” OSX release, with subsystems like launchd and a more mature OpenDirectory replacing older NeXT subsystems. Leopard in my experience was a train wreck. It shipped a lot of new features, both user facing and back end frameworks, but the development was seriously impacted from teams losing engineers to iOS. Leopard had features planned assuming 100% availability of SWE’s resources but ended up with 40-50% of SWE’s resources (made up numbers based on my feels at the time). Many new frameworks in Leopard did not land or get stable until very late in the development cycle which meant everything downstream had to scramble right before GM. It was 100% the case that Leopard was not really stable until 10.5.8 and still sucked IMHO.

There was a lot of clean-up needed in MacOS and that was Snow Leopard. It was not a perfect release but 10.6.3 (the second disc pressing IIRC) and onward were very stable. Dropping PowerPC support really helped focus QA since they didn’t need the massive array of test hardware Tiger and Leopard required. You also didn’t need to wrangle builds for four architectures, including multiple compilers as a few libraries (if not whole frameworks) were compiled with ICC on x86 for performance reasons. The “Snow Leopard wasn’t that great” meme is weird. I’m sure it had its problems like every OSX release did. Unfortunately most OSX releases broke someone’s workflow. Snow Leopard ware no different. But it was always billed internally as a “no new features” release and those features that it did ship faced a very high bar to get in the release. I definitely look back on Snow Leopard as a high water mark for macOS quality in terms of a release.

Previously:

Update (2026-08-10): Mooch:

If you weren’t there then you don’t know why I considered getting a “10.6.8” tattoo at one point. Boot Camp was no longer siloed, zero-drama Exchange support was baked in, Quicktime X hauled ass, and It was the definitive answer to the smoldering wreckage of Vista.

Mario Palomera:

Snow Leopard has always remained the best Apple OS in my memory. For me Mail search was perfect all the time, once spotlight finished indexing it was incredible, iTunes, finder, everything just worked. The consistency was felt everywhere…

macintog:

[But] there’s one other missing piece: time

everyone forgets the annual release cycle is a modern novelty. plot 10.x.0’s and 10.x.y final builds on a timeline and it becomes clear

Mail Attempting to Sync Previous Recipients Despite Setting

✇Michael Tsai
By: Michael Tsai
5 August 2026 at 22:11

Jeff Johnson (Hacker News):

Nonetheless, when I send an email in Mail app, from a non-iCloud account to an non-iCloud account, Mail immediately triggers an iCloud connection, as revealed by Little Snitch.

[…]

What could Mail be querying and saving in CloudKit when I’ve disabled Mail in iCloud?

[…]

As you can see in my screenshot at the beginning of this blog post, I have Contacts turned off in iCloud settings, so my Previous Recipients list should not be synced to iCloud. Nonetheless, I followed the commenter’s suggestion of logging in Terminal. I saw log messages that referred to com.apple.mail.recents, which might indicate Previous Recipients and would certainly explain why this happens when I send an email.

[…]

I do object to notifying Apple that I’ve just sent an email. That in itself seems like a violation of my privacy.

The settings are confusing, even more so than with System Preferences. If you go to System Settings ‣ Apple Account, it shows a round rect that says Mail and shows the Mail icon. If you click this, it lets you uncheck Sync this Mac for iCloud Mail. This mirrors the iCloud Mail checkbox that you get when you click See All to see the full list of apps. I don’t like how the top-level name and icon suggest that you’re going to a settings sheet for the Mail app, but then it actually gives you iCloud settings.

Importantly, there’s also another Mail checkbox in that list. It’s easy to miss because, first, why would you expect to see two Mail checkboxes?

And, second, it’s not obvious that there are actually three lists: a bunch of “favorite” system apps, in non-alphabetical order, for some reason including lesser ones like Freeform and Image Playground; followed by a second list of system apps in alphabetical order; and then a third list of alphabetical third-party apps.

Mail is in the second list, along with (to me) other top-tier apps like Books and Maps. Anyway, this second Mail checkbox controls the syncing of non-mail Mail data such as rules and smart mailboxes. But not, apparently, according to Apple, the previous recipients.

Previously:

Received — 25 July 2026 ⏭
Received — 22 July 2026 ⏭

Hide My Email Vulnerability Exposes Real Address

✇Michael Tsai
By: Michael Tsai
2 July 2026 at 20:44

Joseph Cox (MacRumors, Hacker News):

A vulnerability in Apple’s “Hide My Email” tool lets almost anyone discover a person’s real email address that is supposed to be hidden by the feature, and Apple has failed to fix it for more than a year, according to a security researcher and 404 Media’s own tests.

[…]

“Apple Hide My Email is leaking email addresses that are supposed to be hidden. We reported the issue and replication instructions to Apple over a year ago. We don’t know why it hasn’t been fixed, but we don’t feel comfortable waiting any longer. Hide My Email users deserve to know that it may be possible for attackers to discover their hidden email addresses,” Tyler Murphy, the co-founder of EasyOptOuts, which discovered and reported the issue to Apple, told 404 Media.

“Free, publicly accessible people-search sites make it easy to link an email address to other personal details, so people relying on Hide My Email for safety may be at risk,” Murphy added.

[…]

To test the issue I generated a new Hide My Email address and provided it to Murphy. Around five minutes later, he replied with my real email address linked to my Apple account which was supposed to be hidden.

Ben Lovejoy:

Murphy said that he reported the issue to Apple in June of last year, and the company told him it was looking into it. Apple said it had been fixed in March of this year, but Murphy found that wasn’t the case. He again contacted Apple, with the company saying that it would appreciate him not revealing the existence of the flaw until it had been resolved.

Apple then said it planned to address the issue in June, but since it still hasn’t been fixed[…]

Tyler Murphy:

March 19, 2026: Using the reproduction instructions from our initial report, we determined that the vulnerabilities hadn’t been fixed.

May 22, 2026: We realized that the vulnerabilities may have greater severity and scope than we thought initially and reported this to Apple. Apple never acknowledged the report of increased severity.

June 30, 2026: Apple again reported that the vulnerabilities were fixed and asked us to verify. We determined that the vulnerabilities hadn’t been fixed.

Jeff Johnson:

This is every fucking Feedback I file.

John Gruber:

Not good. Especially the “We reported the issue and replication instructions to Apple over a year ago” part.

This is becoming a pattern. At least Apple still allows third-party e-mail providers.

Nick Heer:

Very few details are available right now. I have seen speculation that the original email address is revealed when someone replies using their hidden email address, but the impression I get from Cox’s reporting is that no user interaction is necessary[…]

[…]

I am also unclear about how, as of May, the EasyOptOuts guys found the “vulnerability may have greater severity and scope” than initially reported. Ominous, though.

Previously:

Update (2026-07-13): Jeff Johnson:

I don’t know whether I’ve accidentally stumbled upon that vulnerability, or perhaps in this case the Hide My Email user just messed up in some way, but I’ve definitely discovered a bizarre and troubling Hide My Email bug in Mail app (on macOS Sequoia 15.7.7).

[…]

Bizarrely, however, Mail app displayed an alert that I’ve never seen before, “This message was forwarded to you by Hide My Email,” despite the fact that I have previously received many emails from people using Hide My Email.

[…]

  • Why I am seeing two different @icloud.com email addresses, one of which appears to be the sender’s unhidden address?
  • Why are the To: and From: fields in my reply disabled?
  • Why is my reply not from my @underpassapp.com email address but rather displayed falsely as from the sender’s @icloud.com address and really from my unrelated Apple Account address?

Update (2026-07-16): Joe Rossignol:

Apple this week was sued over a reported “Hide My Email” flaw that could expose a user’s real email address. The proposed class action lawsuit alleges that Apple violated California’s false advertising law and other consumer protection statutes by knowingly offering a feature that does not work as advertised.

This is interesting in that the June 2025 bug report is the evidence that Apple “knew” the feature didn’t work, while “Apple continued to represent to consumers that Hide My Email would actually hide users’ email.” How long are they supposed to get to fix a bug?

Update (2026-07-20): Jeff Johnson:

The misleading user interface elements in Mail app are a bug, but by themselves they’re not a vulnerability. The vulnerability is that when I send a reply to my maliciously crafted email, my Apple account email address is disclosed in the “From” field of the sent reply! In other words, the Mail app interface lies, fails to show the true sent value of the “From” field.

There are a couple of crazy aspects to this information disclosure vulnerability:

  1. It does not require that the victim actually use Hide My Email! I never use it. As I mentioned in my previous blog post, I don’t even have an icloud.com email account.
  2. It does not matter which of the victim’s email accounts receives the email from the attacker. If your Apple account email address is a@foo.com, but you receive a maliciously crafted email addressed to b@bar.com, Mail app will still send your reply from a@foo.com, thereby disclosing your Apple account address.

Update (2026-07-21): Juli Clover:

Apple addressed a vulnerability in Hide My Email that exposed a user's real email address, reports 404 Media. Apple told the site the issue was fully fixed in a patch released on July 3.

[…]

While the bug has now been addressed, email logs that pre-date the fix could still expose user email addresses.

Update (2026-07-22): See also: Hacker News.

Jeff Johnson:

It appears that the vulnerability I discovered, and which still occurs, is different from the vulnerability reported by others[…]

“If You Can’t Stand By a Feature, You Shouldn’t Launch It.”

✇Michael Tsai
By: Michael Tsai
26 June 2026 at 18:22

Jason Snell, on The Talk Show:

[… Apple] decides to do a big feature. The circus comes to town, they build the feature, they launch it, they leave town, and that feature sits there.

And the problem is, there’s bugs, things are broken, and in Year Two, you’re like, “You’re going to fix all the things that were broken in the thing you shipped last year, right?” And in the last decade, I would say, a lot of times what happens is they just don’t. And if you’re lucky, they’ll fix it Year Three or Year Four, […] give it a polish.

The thing that troubles me most about Apple software quality in general is the feeling like they don’t have the people to own the thing that they launch. They build the thing that they launch, and then those people go off and do something else, and nobody is maintaining and improving the thing that’s there.

Via Marcin Wichary:

I think this is spot on, and said really well. Are you honest with yourself about resourcing and focus for right after the launch and then later on? Have you really thought about worst case and best case scenarios vis-à-vis bug reports, latency, user feedback, and craft/​quality however you define it? Have you actually started to make room for those outcomes ahead of time?

For me, an ongoing tension with Apple is Finder, so central to my (and I imagine many people’s?) use of a Mac, but rewritten at some point eons ago in a new framework that caused all sorts of problems, and then pretty much abandoned like a proverbial American city’s downtown.

Revealing files in the Finder and Mail’s table view sort indicators have been broken for me since Big Sur. Disk Utility still doesn’t work as well as before its El Capitan rewrite. But these aren’t even big new features.

Jeff Johnson:

This is what happens when you release major OS updates every year: you have to keep launching new features.

Previously:

Update (2026-06-29): Jesper:

The issue really, that Jason pins down, is that it’s so easy to use incremental development, agile development, sprints, whatever, as a method to do the wrong thing. If you have a year-long schedule, it is easier to say “I will take care of the Finder”, and within the scope of that is a number of features that need be built, but there’s also room for ongoing maintenance. Within the confines of sprint planning, within a culture that sheepishly focuses on the wrong thing, or is obsessed by following the wrong number, or worries about the internal politics of appearing to not have it together, all of a sudden the same work, scheduled into 3 week long sprints, looks like poison.

I know of plenty of organizations that make this work. That have the maturity and discipline and culture to see bugs and defects for what they are, to allocate plenty of time to them and to focus extra time on them with regular intervals.

❌