What Apple’s “Crackgate” Teaches Software Teams About Rare Failures published: false

Shirley — Tue, 27 Oct 2026 19:59:35 +0000

Apple’s first foldable iPhone, the iPhone Duo, has barely hit the market, and users are already posting photos of screens with the same horizontal crack. The internet named it “Crackgate” within days, echoing “Antennagate” from 2010. Apple has acknowledged that a small number of units have inner display problems and is routing affected users to AppleCare for replacements.

I don’t build phones. But reading about it, I kept thinking that this is a story about shipping software too. The failure modes are the same, and so are the lessons.

Your test suite can’t see what only happens one time in a thousand

A former Apple screen engineer quoted in the coverage made a point every developer should tattoo somewhere visible. When a defect is rare enough, you can run a thousand units through testing and never see it. You need at least one failure to show up before you can start chasing it.

That’s the flaky-test problem and the race-condition problem, scaled up. A bug that appears in 0.1% of runs will pass your CI pipeline nearly every time. It will also fail for someone in production within hours, because production is where the volume is.

Some practical takeaways:

Treat “it passed” as evidence, not proof. A green build means you didn’t observe a failure, not that none exists.

Invest in observability before you need it. If a rare failure appears, you want the logs, traces, and device or environment data already waiting.

Take rare reports seriously. One user’s weird screenshot can be the first visible tip of a systemic problem.

Pattern recognition is a superpower

One analyst noted that the consistency of the reports, the same crack in roughly the same place, suggests something systematic, perhaps tolerances in the hinge or how the display is supported during folding. Random damage looks random. A repeated pattern points to a cause.

This is exactly how good debugging works. When dozens of bug reports look alike, resist the urge to treat them as dozens of separate problems. Look for the common factor: the same OS version, the same region, the same batch of dependencies, the same deploy window. The article also raises the possibility of a defective batch of components from a supplier, which is the hardware version of a bad dependency release.

Rollbacks are easy in software, which is exactly why we skip the discipline

Hardware teams live with a brutal constraint: you can’t push a patch to a cracked screen. That’s why Apple’s options here are replacements, service programs, and possibly something bigger. A recall would be unusual for the company, but it’s on the spectrum.

Software teams have the opposite problem. We can fix almost anything after the fact, so we get sloppy about before the fact. Feature flags, canary deploys, and staged rollouts exist because the ability to fix things quickly is not a substitute for limiting blast radius. The article mentions that earlier this year Apple shipped a software fix for a cellular connectivity problem affecting some customers on one carrier. Fast fixes are great, but the people who hit the bug first still had the bad experience.

If you can roll out to 1% before 100%, do it. The 1% will find your thousand-to-one bug for you.

The communication lesson is older than the bug

The 2010 episode is remembered less for the antenna than for the response. Steve Jobs initially brushed off complaints by implying users were holding the phone the wrong way, and Apple eventually offered free protective bumpers.

Compare that with the current statement, which acknowledges the issue plainly and tells people what to do. Whatever you think of the company, the second approach is the one engineering teams should copy in an incident:

Acknowledge quickly. Silence reads as denial.

Say what you know and don’t know. Apple admitted a problem without claiming to know its scale.

Give users a clear next step. “Contact support for a replacement” beats “we’re looking into it.”

Never blame the user for using the product as designed. If folding a foldable breaks it, that’s a design problem.

I’d add one for status pages and postmortems: don’t let a competitor tell your story first. Samsung ran an ad within days of the news. Your equivalent might be a rival’s blog post about your outage.

High expectations make small failures loud

The Duo costs upwards of two thousand dollars, and the company had publicly emphasized waiting until the engineering was right instead of shipping something half-baked. That’s a strong promise, and a strong promise raises the stakes on every defect.

Software has its own version of this. The more you market reliability, polish, or “it just works,” the less forgiveness you get for a visible failure. A scrappy side project can have bugs and be charming. A payments platform that has built its brand on trust cannot.

That doesn’t mean promise less. It means match your testing, monitoring, and incident readiness to the promises you make.

The takeaway

Even a company with enormous engineering resources and tightly controlled supply chains can ship a rare, hard-to-catch defect. If it can happen to them, it can happen to your team. The question isn’t whether a one-in-a-thousand bug will reach users. It’s whether you’ll find out fast, understand the pattern, limit the damage, and tell people the truth.

Build for that moment before it arrives.

Have you ever shipped a bug that your tests had no realistic way to catch? How did you find it, and what changed afterward? Share it in the comments.

Sources:

Michael Acton, “Apple hit by ‘Crackgate’ outcry over iPhone Duo screen problems,” Financial Times, San Francisco. https://www.ft.com/content/324875fb-8631-4339-8516-6057de9ac085 (add the publication date from the article page; FT content may require a subscription)

DEV Community: Shirley

What Apple’s “Crackgate” Teaches Software Teams About Rare Failures published: false