4 ms·

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 Androi

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 24d ago
> 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 24d ago
  All of FAANG is, if we're being cynically reductive.
  - dbmnt 24d ago
    Apple has a very different business model than Google (Alphabet). It's not even close to the same in terms of how they make most of their money.
    - bigyabai 24d ago
      I don't disagree. They're still a spy company, if we're being cynically reductive.
      - devsda 24d ago
        Is there a way to ELI5 Google's primary business model without it coming across as spying on people? Very few have the same problem among FAANG and others.
        theshrike79 24d ago
        Ads, Google is the world's largest ad company. Internally they can do anything EXCEPT fuck with the ad revenue. If you get more ways to get data off users and ad views, good.
    - dns_snek 24d ago
      As if hardware companies don't quite famously include spyware in their products. Everything from phones, cars, fridges, TVs, monitors, speakers, light bulbs, laptops and everything else that supports inclusion of spyware.
    - fsflover 24d ago
      You're not wrong today, but they are expanding their ads department to the detriment of users: https://news.ycombinator.com/item?id=46911901 https://news.ycombinator.com/item?id=46911901, https://news.ycombinator.com/item?id=46322556 https://news.ycombinator.com/item?id=46322556, https://news.ycombinator.com/item?id=22501511 https://news.ycombinator.com/item?id=22501511
    - wooger 24d ago
      It did do, but now it's putting ads in everything it will rapidly converge to the same practices to optimise shareholder value.
    - delfinom 24d ago
      Apple's own TOS allows them to datamine your data to sell you ads the same as anyone else.
well_ackshually 24d ago
??? 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 24d ago
  > 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)…
dbmnt 24d ago
Another reason is hardware fragmentation. An Android developer has to account for over 20,000 unique devices, compared to an Apple developer targeting around 40 supported models at most.
- cosmic_cheese 24d ago
  It’s a factor, but the bulk of those devices can be generalized into a handful of categories. Google could also throw around its weight a bit more to get manufacturers to form a consensus on things like how various components are addressed so it doesn’t need to spin its wheels as much on papering over those differences.
  - Danox 24d ago
    Not going to happen Google is satisfied with its position because they are basically at the end of the day a ad company that is their priority.
    - bigyabai 24d ago
      That's not the problem whatsoever. Android is ultimately a FOSS project, so Google can't force anyone to do anything.
      - simonh 24d ago
        Better support for variable form factors wouldn’t force anyone to do anything. It would incentivise them to use that support. Danox is just saying (IMHO) that Google can’t be bothered because they don’t need Android to be good, they just need it to be good enough to continue existing.
        bigyabai 24d ago
        It might, but if you look at other AOSP features in that vein (split-screen multitasking, popout volume sliders, standard dialer app) they're all largely ignored by downstream OEM Android ROMs. I wish that wasn't the case, but it's also clear why this happens. Google has led many horses to this spring, only to watch Samsung ship some godawful monstrosity and refuse to drink. It's part of Android's identity, not Google's.
grishka 24d ago
Android actually has one real way to build UIs — it's the views and the resource system. Everything else is just Google's abstractions over that, which are either beta or deprecated. I'm not sure what kinds of tools do you expect. You do have to make layouts for different screen sizes, no real way around that. You'd usually want two breakpoints, so you have phones, small tablets (and foldable inner screens), and large tablets.
- cosmic_cheese 24d ago
  I'd like to see equivalents of UIKit/SwiftUI components that do most of the layout/navigation heavy lifting for you. For most apps, either the iOS 18+ UITabController or UISplitViewController comfortably covers every platform, orientation, and screen an iOS app can possibly run on with a tiny fraction as much boilerplate and manual ratcheting as is required in Compose.
  - jshier 24d ago
    There are, watch the "Strike a pose with adaptive layouts" video they posed yesterday (https://developer.apple.com/iphone-duo/ https://developer.apple.com/iphone-duo/). High level components like split views will adapt automatically, while things like scroll views won't, so there are new adaptive views (AdaptiveView, UIArrangementViewController) to help you move things around.
nonninz 23d ago
> 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. I was an Android developer 15+ years ago, and this is exactly what made me move away into backend. Interesting that it's still like that after so much time!
- cosmic_cheese 23d ago
  To be clear, it’s definitely improved some in that time, but there still yet remains plenty of room for further improvement. Google seems extremely reticent to have anything resembling strong opinions in Android’s API design and so there are still many corners in which well-supported, fully fleshed out “correct” options are absent.

fchicken 24d ago

> 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 24d ago
All of FAANG is, if we're being cynically reductive.
- dbmnt 24d ago
  Apple has a very different business model than Google (Alphabet). It's not even close to the same in terms of how they make most of their money.
  - bigyabai 24d ago
    I don't disagree. They're still a spy company, if we're being cynically reductive.
    - devsda 24d ago
      Is there a way to ELI5 Google's primary business model without it coming across as spying on people? Very few have the same problem among FAANG and others.
      - theshrike79 24d ago
        Ads, Google is the world's largest ad company. Internally they can do anything EXCEPT fuck with the ad revenue. If you get more ways to get data off users and ad views, good.
  - dns_snek 24d ago
    As if hardware companies don't quite famously include spyware in their products. Everything from phones, cars, fridges, TVs, monitors, speakers, light bulbs, laptops and everything else that supports inclusion of spyware.
  - fsflover 24d ago
    You're not wrong today, but they are expanding their ads department to the detriment of users: https://news.ycombinator.com/item?id=46911901 https://news.ycombinator.com/item?id=46911901, https://news.ycombinator.com/item?id=46322556 https://news.ycombinator.com/item?id=46322556, https://news.ycombinator.com/item?id=22501511 https://news.ycombinator.com/item?id=22501511
  - wooger 24d ago
    It did do, but now it's putting ads in everything it will rapidly converge to the same practices to optimise shareholder value.
  - delfinom 24d ago
    Apple's own TOS allows them to datamine your data to sell you ads the same as anyone else.

well_ackshually 24d ago

??? 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 24d ago
> 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)…

dbmnt 24d ago

Another reason is hardware fragmentation. An Android developer has to account for over 20,000 unique devices, compared to an Apple developer targeting around 40 supported models at most.

cosmic_cheese 24d ago
It’s a factor, but the bulk of those devices can be generalized into a handful of categories. Google could also throw around its weight a bit more to get manufacturers to form a consensus on things like how various components are addressed so it doesn’t need to spin its wheels as much on papering over those differences.
- Danox 24d ago
  Not going to happen Google is satisfied with its position because they are basically at the end of the day a ad company that is their priority.
  - bigyabai 24d ago
    That's not the problem whatsoever. Android is ultimately a FOSS project, so Google can't force anyone to do anything.
    - simonh 24d ago
      Better support for variable form factors wouldn’t force anyone to do anything. It would incentivise them to use that support. Danox is just saying (IMHO) that Google can’t be bothered because they don’t need Android to be good, they just need it to be good enough to continue existing.
      - bigyabai 24d ago
        It might, but if you look at other AOSP features in that vein (split-screen multitasking, popout volume sliders, standard dialer app) they're all largely ignored by downstream OEM Android ROMs. I wish that wasn't the case, but it's also clear why this happens. Google has led many horses to this spring, only to watch Samsung ship some godawful monstrosity and refuse to drink. It's part of Android's identity, not Google's.

grishka 24d ago

Android actually has one real way to build UIs — it's the views and the resource system. Everything else is just Google's abstractions over that, which are either beta or deprecated. I'm not sure what kinds of tools do you expect. You do have to make layouts for different screen sizes, no real way around that. You'd usually want two breakpoints, so you have phones, small tablets (and foldable inner screens), and large tablets.

cosmic_cheese 24d ago
I'd like to see equivalents of UIKit/SwiftUI components that do most of the layout/navigation heavy lifting for you. For most apps, either the iOS 18+ UITabController or UISplitViewController comfortably covers every platform, orientation, and screen an iOS app can possibly run on with a tiny fraction as much boilerplate and manual ratcheting as is required in Compose.
- jshier 24d ago
  There are, watch the "Strike a pose with adaptive layouts" video they posed yesterday (https://developer.apple.com/iphone-duo/ https://developer.apple.com/iphone-duo/). High level components like split views will adapt automatically, while things like scroll views won't, so there are new adaptive views (AdaptiveView, UIArrangementViewController) to help you move things around.

nonninz 23d ago

> 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. I was an Android developer 15+ years ago, and this is exactly what made me move away into backend. Interesting that it's still like that after so much time!

cosmic_cheese 23d ago
To be clear, it’s definitely improved some in that time, but there still yet remains plenty of room for further improvement. Google seems extremely reticent to have anything resembling strong opinions in Android’s API design and so there are still many corners in which well-supported, fully fleshed out “correct” options are absent.