> WindowSizeClasses, Postures, Navigation3, ListDetailScaffolds, the list goes on.

Yes, those are the loose parts. They still have to be assembled correctly for everything to work as expected and every app does it a bit differently (there is effectively no endorsed "correct" way to assemble them). This means that Google cannot extend them with new functionality later without breaking some if not most usages of those parts in the future.

Compare that to UITabController in UIKit, which has been present since very early on and got extended recently. If the dev adopts iOS 18 revisions, configuring that single view controller gets you more or less correct presentation and navigation across all sizes and orientations of normal iPhone, iPad, desktop, and now iPhone Duo and implementation is close to identical between apps.

> …and then complain about Android that literally had to pave the way and today works on phones that can unfold three times, phones like the galaxy Z Flip that have instead half screens, etc.

That's fair, but users can't reasonably expect any kind of meaningful adoption of new oddball form factors like that until the platform vendor (Google) rolls out standardized APIs to streamline the process (which Google has partially done, but won't commit to a unified solution for).

> Apple will tell you they can't back port dynamic islands on last year's release, while latest Compose is happily running on devices from 10 years ago.

That is an advantage, but iOS users tend to stay much more up to date so it's something of a moot point. The userbase of versions just three major releases behind is typically below 5% and anything older is fractional at best, so unless you're a Google-scale giant you're probably fine only supporting the newest 2-3 versions of iOS. That's pretty nice since I don't need to keep a drawer full of prehistoric phones running ancient versions of Android to test adequately (so I don't find out about some weird behavior that only occurs under Android 11 in prod)…