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.
Google is fundamentally a spy company, not a product company
Very few have the same problem among FAANG and others.
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.
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.
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)…
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.
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.
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.
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.
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 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!
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.
I think they need to aggressively court developers, just give a buttload of advertising credit to nice apps that predate AI slop if they add compatibility, what does it cost Apple to "give" you $10k or $20k credit in their own ad system...
But the rumours also say they are going to squeeze the App Store for higher margins so maybe it is too late.
Maybe the folding phone form factor will inspire some better UI/UX for apps.
This is a quote from John Carmack and should sit over every developers monitor. At the same time, OS designers should be doing everything in their power to reduce the number of states a developer has to think about.
'You may only play audio if such and such conditions are met. However these are different based on browser and platform. Good luck making a solution fitting all these.'
'The browser might lie about what's the available screen estate is, but only sometimes'
'There is a perfect API for what you wanna do, however it's not in Safari'
And a testament on how obscure and arcane knowledge is on doing things right is that I thought there would be some npm packages that do these things for me, but no - you have to hunt around for solutions and fix things yourself.
And LLMs are completely useless and confidently wrong mostly about everything involving this.
In theory the client can do literally anything (for example, someone could be using an ancient version or have some features voluntarily disabled) and you have to decide which things you're going to handle
If anyting, Apple stands to gain from what was already developed for Android.
Like https://developer.android.com/phones-tablets-foldables
Which targets iOS also: https://kotlinlang.org/compose-multiplatform
This is ignoring the fact that developers who choose these cross-platform frameworks don't seem to care much about quality and general polish.
For Apple foldables yes. Not Android.
I see what you did there :)
:)
"There are dozens of us!" (not me though, I wouldn't buy a Pixel foldable)