I also develop on iOS and I agree with your comment. Example of this is iOS built in URLSession compared to Android’s deprecation of Volley so we have to rely on a third party Retrofit. The thought of that is just insane to me.
For whatever historical reasons, there has been a flow of Android programmers from Google to Square (and from Square to Google). Square libraries are often written by people who came from the Google Android team. Dagger was written at Square but maintenance was handed over to Google. So technically Square's libraries are third party and Square gets some credit for it all, but it's not totally independent.
Because bundling APIs in the SDK has traditionally led to more fragmentation, not less. Hence the androidx libraries and now Compose, which creates an API surface that mostly works without having to think about OS versions.
I talk with iOS devs often, and most of them do not use SwiftUI because the feature disparity is massive across iOS releases. Bundling features into the Android SDK would be about 1000 times worse because Android OEMs don't update their devices like Apple does.
> I talk with iOS devs often, and most of them do not use SwiftUI because the feature disparity is massive across iOS releases. Bundling features into the Android SDK would be about 1000 times worse because Android OEMs don't update their devices like Apple does.
That's largely due to SwiftUI's newness and immaturity, though. Although UIKit gets major new additions each year it doesn't have that problem because all of the essentials have been in place for ages, which means when supporting older releases you can either just use the older APIs or use a combination of old and new with conditionals.
