Apple Used to Exterminate Bugs. Now It Gives Them a Home.

Its fixes used to delight developers, the way its hardware still does. Now bugs get tenure, and a lifetime position.

Apple now declines to fix some bugs even when they break published standards, because the bug has shipped and become an informal standard. That turns arbitrary errors into rules, forces developers into workarounds, and leaves the job of writing correct code to open source.

Apple has started resisting bug fixes.

Not hiding its bugs: knowingly keeping them. I showed Apple that its software violates a published standard. Nobody disputed it. And I was told the mistake will probably stay. The reason: it has been wrong for long enough that changing it might surprise someone.

That is a new attitude, and it should worry anyone who depends on Apple’s software, which today is most of us.

It Used to Be Different

Years ago I told Apple that the Mac’s Finder crashed whenever it tried to preview a certain microscopy file, an exotic scientific format that looked enough like a TIFF image to mislead the Finder. Apple fixed the crash. Then it went further and taught the Finder to show a proper thumbnail of the file, something I hadn’t even asked for.

That was the deal, and it felt like the rest of Apple: you pointed out where the platform was wrong, and someone made it right, sometimes better than right. The fix delighted the way a new Mac does.

Now the Bug Gets Tenure

This summer I found that a basic piece of Apple’s software, the part Apple gives app developers for reading one of the most common data formats on the internet, silently deletes a character. Not a damaged one, not an illegal one: a character the published standard explicitly allows. In my case it quietly corrupted the vocabulary of an AI model. No error message. No visible trace. Just wrong results. I told the story of finding it in A Study in Invisible Betrayal.

I filed the bug and asked on Apple’s developer forums. The answer: a fix is unlikely, because of “compatibility risk”. Some existing app might depend on the wrong behavior.

Think about what that means. The standard, the shared rulebook that lets software from different companies understand each other, no longer decides what is correct. Whatever Apple happened to ship decides. Stay wrong long enough, and wrong becomes the rule.

The Excuse Doesn’t Hold

Compatibility is a real concern. It is also a solved one, and Apple solved it.

For decades, Apple has fixed behavior without breaking older apps by checking when an app was built. Apps built before the fix keep the old behavior. Apps built after it get the correct one. Apple’s own release notes describe it routinely.

So “compatibility” doesn’t explain why the mistake can’t be fixed. It only explains why fixing it takes some effort. The difference between my two bug reports isn’t that one was harder. It’s that one of them was someone’s job.

Open Source Is Doing Apple’s Job

Here is the uncomfortable part for Apple: the bug is already fixed. Just not by Apple.

A small, free, open-source program reads the same data correctly. A widely used open-source AI library switched to it. And, most telling of all, Apple’s own newer, open-source code gets it right. The correct version already runs on every Mac. Apple simply won’t fix the old one.

Sometimes there isn’t even a door. This year I fixed a problem in Apple’s own published AI code and found no way to send the fix back.

So developers do what developers do: they route around Apple. Each workaround moves a little more of what runs on Apple’s devices into code Apple doesn’t write, doesn’t control, and can’t vouch for. For a company that sells trust, that is an expensive habit.

I Have Seen This Before

I’ve seen this before. From a company called Microsoft.

In the early 2000s, Microsoft owned the web browser. Internet Explorer broke the web’s published standards, and then, having won, it barely changed for years. Web developers spent half a decade writing every page twice: once for the standards, once for Internet Explorer’s mistakes. Microsoft’s mistakes had become the rules of the web.

Open source ended it. Firefox, built in the open by people who simply followed the standards, took a large share of users away from it. Microsoft eventually gave up its own browser engine altogether, and today its Edge browser is built on open-source code it didn’t write.

Apple knows this story better than anyone. It was part of the answer: the engine inside Microsoft’s Edge today descends from WebKit, the open-source engine Apple built Safari on. That makes it harder to watch Apple start down the same road.

No Lab Would Accept This

I spent most of my career with microscopes. If an instrument quietly altered measurements, and the manufacturer explained that fixing it might confuse customers who had grown used to the wrong numbers, no lab would accept that. You would recalibrate, or you would replace the instrument.

Developers are doing both.

The fix Apple needs isn’t technical. Treat a violation of a published standard as a defect that “compatibility” cannot veto. Use the tool Apple already has to protect older apps. And when a developer reports one, answer with a person, not a forecast.


The technical details, with code and workarounds: NSJSONSerialization silently deletes U+FEFF from JSON strings on FossilCoder. The bug is FB23271905. If it has bitten you too, file a duplicate.

Written with Claude in dialogue with Kolja Wawrowsky, from his bug report, his forum thread, and his letter to Apple.