Earlier quoted context omitted.
It's really hard to put any single root cause on it. Firstly, mobile OSes are massive beasts with lots of different teams working on it. Co-ordinating this becomes very difficult. Additionally, you typically get about 1 build a day which means there's a long lead time to find a bug that's managed to propagate out and then a long lead time for it to get fixed (at least 1 day). I think this decrease in quality has been…
It sounds like they need to issue smaller releases, more frequently.
However, the contradiction is that single giant releases help in three ways. The first is it enables you to make 1 big splash of a years worth of work to customers rather than it being dribbled out of the course of a year across different components, which is super important because it dove-tails into the release of the next flagship phone. It also makes the messaging because you can build themes for your releases that are co-ordinated across many apps/services.
The second is that it co-ordinates large-scale changes across the company (e.g. major UI redesign, some major UX improvement, etc) which would be more difficult to co-ordinate with smaller releases or if apps were split out.
The third is that leaks/previews can be better controlled as managing a bunch of different releases that contain functional differences is harder than just maintaining bug fixes (i.e. prepping UI changes for 50 different apps that are released throughout the year in preparation for the next OS that makes it possible for those apps to run).
Finally, it simplifies development in a sense because you don't have to worry about 1P backwards compatibility. 1P apps don't have to worry about supporting more than 1 OS and OS changes can confidently break 1P apps (within reason) with new APIs without worrying about apps that haven't been updated. The latter part about breaking apps doesn't matter as much if the apps are bundled with the OS unless those apps can also deliver updates via the App Store as now you have to launch vehicles that can be tricky to co-ordinate.
Yes, a lot of this is pure business reasons for why the SW is co-ordinated but that doesn't mean that it's not valid. Business practices & SW are symbiotic aspects of a tech company as neither can exist without the other. Everything is a list of tradeoffs and priorities. Apple is apparently first experimenting to see if they can keep all the business pros of their current approach by altering their program management practices which they've already done - iOS & OSX today have far more dot releases in 3 months than they used to between major versions. Reducing scope is the approach they're taking in the interim to make the major releases more stable - will be interesting to see if this is a long-term shift or just an interim one until their QA infrastructure investments catch up to be able to keep up with development. If those approaches fail & the brand becomes at risk that may outweigh the other business reasons & result in independent app & OS releases (seems unlikely IMO).