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:

• “If You Can’t Stand By a Feature, You Shouldn’t Launch It.”
• Glow Leopard
• Snow Leopard at 15
• The Myth and Reality of Mac OS X Snow Leopard
• A Retrospective Look at Mac OS X Snow Leopard

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

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:

• Glow Leopard
• Child Safety Features in appleOS 27
• Will Disk Utility Ever Work Properly?
• Remaining Issues in Big Sur
• Disk Utility in El Capitan

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.

Tim Hardwick:

Apple at WWDC 2026 today said it has made several responsiveness improvements across its software ecosystem, speeding up system animations, app launching, and much more.

Zac Hall:

Overall, iOS 27 so far is a major collection of performance improvements and refinements.

Ryan Christoffel:

As had been rumored leading up to today, Apple has spent extra time this year working on bug fixes and performance improvements for iOS 27.

Adam Engst:

Although there’s no obvious connection between the Tahoe and Golden Gate names to indicate a “tock” release, Apple devoted the first chunk of the WWDC keynote to how OS 27 will address user and developer complaints about OS 26.

[…]

Apple also made a big deal about performance improvements, smoothing system animations, launching iPhone and iPad apps up to 30% faster, displaying new photos in the Photo Library up to 70% faster, transferring files via AirDrop up to 80% faster, and moving files from an iPad to an external drive is up to 5x faster, so it compares with macOS transfer speeds. A new CPU Scheduler promises to improve iPhone performance even on older models back to the iPhone 11, which may encourage more people with older iPhones to upgrade.

Kyle Howells:

There really aren’t many changes this year.

I’m way more interested in bug fixes, but optimizations and refinements are great, too. Simply limiting the number of new features creates space to improve the software quality, though, it’s not clear to me whether there are really fewer new features or if it’s just that they mostly fall under the single heading of AI.

Paul Hudson:

Animations run smoother, apps launch faster, and Liquid Glass is better? It’s Glow Leopard for sure!

Divya Ravi:

One underrated theme from this WWDC is Apple investing heavily in fundamentals.

Faster launches, scheduler improvements, search infrastructure, networking transitions, rendering performance…

Users notice responsiveness long before they notice most new features.

Clarko:

You gotta admire Apple’s ability to market “bug fixes and performance improvements” so effectively.

Please just do this every other year.

Previously:

• Golden Gate Menu Icons
• Golden Gate Sidebars and Toolbars
• Golden Gate Window Corners
• Liquid Glass 27 Slider
• Liquid Glass 27 Icons
• macOS Golden Gate 27 Announced
• iOS 27 Announced
• iPadOS 27 Announced
• WWDC 2026 Keynote
• WWDC 2026 Wish Lists
• 2025 Six Colors Apple Report Card
• iOS 27 “Rave” Update to Clean Up Code
• What Happened to Apple’s Legendary Attention to Detail?
• The Tim Cook Era
• Apple Needs a Snow Sequoia

Update (2026-06-12): David Smith:

Something I’ve noticed about performance work is that people really want there to be A Cause for improvements. A new technology, something old no longer holding things back, “removing the debug logging”, etc…

The truth of the matter is that 97% of the time the enabling thing for performance work is engineers having time in the schedule to sit down with the tools (usually a sampling profiler) and grind out small wins over and over.

There’s no magic bullet that replaces good engineering.

It sounds like the magic bullet is a reasonable release schedule. You’ve always had the power, my dear Craig. You just had to learn it for yourself.

Jason Snell:

The moment the keynote used the phrases “sweating the details” and “attention to detail,” it was clear that beyond AI and Siri features, this year is about small fixes and improvements. In more private settings, Apple folks specifically referenced Snow Leopard and iOS 12, two updates that saw Apple take a pause from huge feature roll-outs and prioritize speed and bug fixes a bit more.

But to be clear, referencing Snow Leopard does not mean “no new features.” Like Apple’s 27 releases, Snow Leopard was full of dozens, if not hundreds, of new features—they were just scattered small improvements throughout the system.

Patrick McConnell:

The older I get and the longer I do this development work I realize time is short and we may not get to all the things we want to do in life. So when we are forced to wait yet another year for some fixes to a framework we’ve been trying to use for several yearly cycles already it can be disappointing to say the least.

[…]

Unlike past years there is no clear Apple mandated work. Thank god. I can focus on what I want to build without having to adopt my code to an ill conceived UI update that will be semi-discarded the following year.

Update (2026-06-16): Marcin Wichary:

It’s an impressive list that garnered universally positive reactions, but I have one observation:

• “Fast” and variants thereof appear on this list 59 times.
• “Reliable” and similar words appear 22 times.

[…]

It’s not just me. 15 out of 17 bugs listed on the Bugs Apple Loves site are about reliability.

[…]

I just… I would be a lot more excited if the 3:1 ratio of fast-to-reliable on that slide went the other way.