If you have a mature system, and it has a problem, and you decide to rewrite it from scratch, you now have two* problems.
To quote
Joel Spolsky from 25 years ago:
(Replace the Windows-oriented tech specifics with modern Mac/iPhone examples, if it helps)
Do they? What makes that clear? Replacing a codebase that’s nigh on 30 years old is a huge coding effort with undefined benefits. The code has to be
irredeemable to make it worthwhile, or somehow fundamentally architecturally unsuitable - hence the iTunes to Apple Music transition (and even then, I’ll bet you a pint there’s an absolute ton of iTunes logic in Music).
And you need your developers are hyper-good, or they'll just replace all the old bugs with brand-new shiny-but-different bugs.
Narrator: They did, in fact, replace all the old bugs with new bugs.
Put yourself in Apple’s position, and ask: “
Must it be fixed, though?”
The cost/benefit analysis of a commercial bug fix is different to a hobby project. I think the thing that’s clear is that the current bug count in iOS is not hurting Apple at all - the software is
good enough to keep iPhones, iPads, and MacBooks flying out the door as fast as they can make them, which is what Apple wants; they’re a hardware and services business, not a software company.
I would be
delighted were Apple to embark on a Great Crusade against bugs, fixing all this stupid stuff. But they ain’t gonna, until it makes sense to do financially.
*Many, many more than two. But definitely at least two.