> the answer to Apple's quality problem is to begin baking QA back into the process in a meaningful way after letting it atrophy for the last decade or so.
As a former Apple employee of 13 years: Apple knows about the bugs. QA isn’t the problem.
A lot of people complain that their radar for some obvious bug isn’t getting noticed, and conclude that Apple must not be QA’ing, or not dogfooding their own product. This isn’t the case at all. I guarantee the bugs you care about are well known, and QA has already spotted them.
The reality is, they just don’t care. The train leaves the station in September. You’re either on it or you’re not. If you spent the year rewriting some subsystem, and it’s July and you have this huge list of bugs, there’s a go/no-go decision, and the answer is nearly always “go” (because no-go would mean reverting a ton of other stuff too, and that carries its own regression risk, etc.)
So instead there’s just an amount of bugginess that’s deemed acceptable. And so the software is released, everybody slaps high-fives, and the remaining bugs are punted to next year, where they will sit forever, because once we do one release with a known bug, it couldn’t be that important, right? After all, we shipped with it! Future/P2, never to be seen again.
An attempt was made to remedy this by pushing deadlines earlier in the cycle, to make room for more QA time, but that just introduced more perverse incentives: people started landing big features in later dot-releases where there’s less scrutiny, and even more tolerance for bugs.
The honest answer is that Apple needs to start giving a damn about the quality of what they’re pushing. As Steve once said at a pretty famous internal meeting, “you should be mad at your teammates for letting each other down like this”. And heads need to roll. I can only hope that they’re realizing this now, but I don’t feel like the culture under Tim works this way. People’s feelings are way too important, and necessary changes don't get made.