Minimizing shipped defects is qualitatively simpler in physical engineering because the set of possible defects you have to account for is astronomically smaller.

I am a physical engineer by background but have also spent much of my career in high-reliability software systems. The problems of reliability in software systems make physical systems look like child’s play. The levels of effort are on different scales.

An important difference is that software correctness is mostly binary. In physical engineering you can usually spend a bit more money to over-engineer a component if you have any doubts or are lazy, and that works. Effort does not scale nearly as well when it comes to reliable software.

There is also a much closer defined "completion" state in hardware, with responsibility also more distributed across suppliers.

You have a committed spec of one component, connected to the committed spec of another component, with committed maximum deviations.

All that is fixed, so you engineer for possible permutations and mass-production. (it's still a massive feat, I'm not downplaying it. But it has a defined completed controlled state)

In software this is much more fluent. You may have a spec of a library and the APIs you use, and your app might otherwise be static.

But you're handing alot of what you do to an OS, which juggles everything and continues to change over time. That API you're calling may not even have full control over the modules its interacting with.

And there’s an enormous amount of good engineering effort Apple does put into both quality and crazy cool shit that gets done. People just don’t appreciate it because it’s invisible when it works and it’s not as cool as “ran a graphite heat pipe through the fold” which is probably one of the easier things they did for the fold.