As a recent Android foldable phone owner (Google Pixel), I'm excited that the Duo will get developers to actually design apps for foldables. Right now, some apps don't work at all and others are just stretched. I feel a better use of the screen space is around the corner for both Android foldable and Duo users.
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.
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.
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.
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.
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.
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). 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)…
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.
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.
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.
It would depend on the sales volume. For a long time the iPad has been available and many developers simply are content to have a stretched version of their iPhone app on their iPad, because the sales volume isn’t sufficient. If foldable phones sell like iPads, this could very well happen to them too.
I still think that there are very few examples of apps that utilize tablets well even among the apps that aren't stretched phone apps. I don't know if it is the ergonomics of the large screen or what, but the experience of using a tablet has always been pretty bad in my opinion.
Maybe the folding phone form factor will inspire some better UI/UX for apps.
The rumours say 10 million iPhone Duo are being made, there are hundreds of millions of iPads so the numbers might not sway any opinions for a while.
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.
> "A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in."
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.
Like one of the things I hate about frontend development - and admire people who do this professionally - is the stupid and arbitrary rules browsers impose on you.
'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.
Yep fundamentally different from back end because you don't control the client.
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
It seems like apps by default fill one screen or the over in landscape mode, while by default they fill the whole screen in portrait, which is a nice setup that means that phone apps will mostly just work, which is nice. Some developers will customize how their interface works on the passport style ratio over the narrower design of current iPhone, like adding side controls, which will be nice, but not strictly necessary so smaller devs won’t need to do much. I do think the dominance of iPads really helps too compared to Android, as iOS users largely expect iOS apps to support phone, tablet, and laptop style use cases. So even when devs don’t do much to support the Duo, or take a long time to do so, work they’ve already done to support iPad screen sizes/ratios and the windowed multi-tasking setup on iPadOS will mean apps already handle some of the demands of the Duo, since even apps that generally prioritize phone use include the basics for iPad use.
Apple will gain more from their own existing ecosystems, all five of them most developers within the Apple ecosystems if they pretty much followed all the rules most of their software will work on day one with very minimum changes, in short, they will be 90% of the way there.
It is a thing to some extent, but there’s also a correlation of companies that do cross-platform for simple apps being cheap on development, and making it work very well on some specific platform isn’t their priority.
What would be REALLY vaulable would be a 141% enlarge mode. Ie since the screens are the same ratio there is no reason that when open it could just display exactly the same except larger. This is a piece of piss to program if they haven’t already put it in accessibility settings. This feature alone would drive certain demographics to this device.
I only hope that apps that were iOS16+ compatible will stay so. Updating my iPad because there is a new marketing trick from Apple is NOT something i would like.
Same here. I ditched the google pixel fold after a year because the hardware had some issues, also tbh I prefer the iOS ecosystem. I’m so glad this is coming out.
With AI that will be reduced, because the future is AI designed apps, just like sign companies slap Arial, Times New Roman on signs and others use wix/wordpress/squarespace for their company page
Unfortunately, "AI" speech to text loggers can run a long time before it ever runs out of memory. Every time you have to update the TV software, a few MiB of your data is sent.
The issue is a lot of the TV traffic is encrypted, and given the other issues reported it likely gets a lot worse for privacy advocates. Air-gaps don't necessarily guarantee anything either. =3
Technical solutions are insufficient for such disregard, the company needs to be sued out of existence, and laws made to prohibit and punish such behavior
so whats the best and most efficient coding harness and against which model? what are folks doing to keep costs low? I spent $1000 just this weekend on my personal projects for sota Claude but I feel like I can probably get much more juice if I start looking elsewhere.
Buy a card. Run your own. It'll be some time to optimize it, but an AMD R9700 is one of the cheapest by $/vram. Sadly, its been increasing in price slowly, and there seems to be some inventory issues, but I've switched to it exclusively. I hope to get a 2nd card to run other workloads simultaneously.
I've been running Qwen27B Q6 with 130k context at 30tps. It's not bad.
I think with an "autopilot" mode in pi, and sub agents to handle context window management better, I'd envision you could get close to unattended workflows. I haven't quite gotten that far though.
Negative is you have to do it all, and the temptation to tinker is real.
You need to feed it high quality data. Try Gemini Notebook, but this time load up a spreadsheet of fundamentals information for all US stocks or ETFs. The answer will differ and be much more nuanced.
I dont think you can rely on an out of book chat agent today to have all the necessary information at its disposal - even if you can pull a stock quote in ChatGPT, it doesn't mean it's going to look at PE multiples on 5000 stocks...
> With every update, our study shows, AI writing is becoming more similar to human prose.
Any possible vice-versa: There's a meta problem with AI writing detection. I have found my (non-AI-assisted) prose possibly enhanced or modified by my learnings and observations at how LLMs write. In some sense they have made me better at structuring my thoughts and how to communicate them.
Thank you for sharing. This type of stuff gets me pumped up. It just shows that tech improvements usually 10x - or in this case 1000x - some old metric. In this case its cost. I think the same sort of rule of thumb applies to things like speed, features, user experience, etc... Getting this type of cost advantage eventually translates to a better UX, as you've alluded to. Way to go.
reply