As a dev who regularly works on apps for both platforms, I think one of the main causes for poor support for form factors beyond a standard smartphone on Android boils down to Google refusing to give developers fully fleshed out APIs to support said form factors.

Instead, they just hand you some poorly documented loose parts in a box and tell you, “good luck” and you’re on your own to fill the gaps. Compose is a little better about giving the tools you need than the preceding Android Framework, but it’s still much more “assembly required” and “batteries not included” than the UIKit+SwiftUI world is.

Many iOS apps built using system components will behave 90%+ correctly on the Duo by just compiling against the iOS 27.1 SDK because there are well supported methods of doing things that Apple can leverage to reduce dev work. In contrast, on Android there's 10 ways of doing anything none of which get full-throated support (on top of all the other ways devs invent), and so any time it gains support for a new form factor almost nothing is automatic and it all falls on the devs’ shoulders.

▲

fchicken 3 hours ago | parent | next [-]

> Instead, they just hand you some poorly documented loose parts in a box and tell you, “good luck” and you’re on your own to fill the gaps.

Google is fundamentally a spy company, not a product company

	▲	bigyabai 2 hours ago \| parent [-]
		All of FAANG is, if we're being cynically reductive.

▲

well_ackshually 2 hours ago | parent | prev [-]

???

WindowSizeClasses, Postures, Navigation3, ListDetailScaffolds, the list goes on. Android & Compose is pretty much flawless when it comes to develop for it, it's thoroughly documented and works well.

Layouts will not magically be not dog shit on iOS because Apple put out another version of SwiftUI that you can't use in prod because nobody has the update. 90% of the apps will be stretched. Horizontally. The reality of it is, it's pretty much never worth it to make layouts that are specialised for foldables/tablets.

Also, it's pretty fucking funny to be worshipping Apple like that when they have a single device to support, 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. 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.

	▲	cosmic_cheese an hour ago \| parent [-]
		> 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). 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)…