> 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

All of FAANG is, if we're being cynically reductive.

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.

I don't disagree. They're still a spy company, if we're being cynically reductive.

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.

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.

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.

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=46322556, https://news.ycombinator.com/item?id=22501511

It did do, but now it's putting ads in everything it will rapidly converge to the same practices to optimise shareholder value.

Apple's own TOS allows them to datamine your data to sell you ads the same as anyone else.

???

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.

> 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 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)…

You say it's pretty much never worth it to make layouts for foldables/tablets. To be worth it, could mean multiple things. But for the love of perfection, the craft of coding, and of UI design, I think it's totally worth it.

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.

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.

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.

That's not the problem whatsoever. Android is ultimately a FOSS project, so Google can't force anyone to do anything.

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.

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.

"Throw unlimited resources at a development target" has been an established F/OSS embrace/extend tactic for at least 20 years.

Red Hat, systemd, Chrome, Webkit, Android, and a few others come to mind. Others might include Kubernetes, OpenJDK, Clang, React, Docker, Git/Github.

Forks are possible but sustained forks are expensive, and <https://xkcd.com/927/> is always relevant.

It's helpful to note that the guy who literally wrote the textbook on lock-in went on to have a career as Google's chief economist: Hal Varian, Information Rules.

<https://en.wikipedia.org/wiki/Hal_Varian>

<https://en.wikipedia.org/wiki/Information_Rules>

My other comment still applies to this response: https://news.ycombinator.com/item?id=49649583

Google lacks the authority to unify folding phone software any better than they can unify homescreen launchers or dialer applications. It's a lost cause. They can spend billions on building the best one ever, and then Motorola or LG will ship a worse proprietary version and never update it. This pattern does not arise from a lack of charity on Google's part.

Not really. The vast majority of devices are so similar that you only really have a couple of categories to cater for

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.

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.

There are, watch the "Strike a pose with adaptive layouts" video they posed yesterday (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.

> 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!

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.