Earlier quoted context omitted.
You realize I work on Android devices all day long right? I have 5 of them sitting in this room! You might not notice, but I assure you, they clear the screen then fade back in. The exceptions are apps that have to handle configuration changes anyways like games or full screen video. It's not always a janky thing, phones have gotten fast enough that the screen redraw is easily hidden behind a half rotate followed by…
I haven't written Android code in a few years, but IIRC, there's an attribute you can add to your manifest that lets you handle the rotation without getting your UI getting destroyed and recreated. This is relatively easy to do and seems to be commonly done, at least for bigger apps. Having worked in both Android and iOS development, I can assure you that they both have some ridiculous quirks and confusing APIs, but…
> To do that tiny little thing I described above you'd have to design your app to disable all built in configuration handling (so now it's on you to handle swapping out every resource when a language change happens, or dark mode is turned on) then hand animate every element to its new position on every screen.
That's not done in "bigger apps", it's done in apps that have large areas not rendered with normal UI elements, like games, or camera apps
I've done some iOS work too, and while iOS has its issues it "defaults" to making better apps, hands down.
It's not unlike the user side of these platforms, iOS has a more opinionated "default" than Android
Jetpack is trying to fix that but it's "not that much, extremely late"
-
But again, this is all missing the forest for the tree here, configuration changes are just a tiny part of the general "backend" choices that add up to a more powerful platform in developing for Android... but a less useable platform as a user