2025 feels like a cardinal year for top-down decisions we all just have to endure for the present. The best we can do is bitch loudly and often, and hope the people at the top still feel threatened by consumers/constituents.
This Liquid Glass decision is particularly challenging for my tiny startup. We have multiple platforms including iOS and Android. I was hoping to share much of our design language across iOS and Android, but now Apple has essentially decided that this Liquid Glass will be mandatory after a year of support for "compatibility mode" that disables it for your app.
We'll now have to spend expensive engineering time to cater to Apple's design whims rather than actually working on PMF and profitability.
And what about online tutorials, marketing, user manuals, customer support? You probably want your app to look consistent with that too, right? Do you really expect or even want to sift through multiple different versions of tutorials and guides?
As long as an app is easy to use, people prefer a single look. No one cares about "looking like the OS", except maybe 0.1% of users.
> As long as an app is easy to use, people prefer a single look
No, people are used to an UI language, which in the case of iOS is quite consistent across applications. You expect certain things to work (e.g. flicking in from the left edge means "go back"). There are platform-specific patterns and I'd rather have the app behave accordingly rather than being consistent with other OS' version. The real 0.1% here are probably the users of your app with active devices in both Android and iOS!
This just isn't supported by data. Breaking users into two categories: users who develop a universal mental model of software, and users who develop application specific mental models. The latter group is the overwhelming majority. People don't learn iOS, they learn Spotify.
Designing with this in mind annoys the hell out of people in the former group, no doubt. Those people are likely love customizable software so they can make it the same everywhere. It's super common in Linux setups.
Most people only have one mobile device, a smartphone. Those that have more than one usually still have those with matched OSes. No-one cares about "looking like the OS", but people do care about looking (and, more importantly, behaving) like all the other apps they use.
And as far as manuals and customer support, what you're saying is that you can't afford to do cross-platform properly, and so you're cutting corners. Which is fine if it's stated explicitly upfront, and having an app that behaves weirdly (for a given platform) is better than no app, but please don't insult your users' intelligence by presenting that as some kind of feature.
> And as far as manuals and customer support, what you're saying is that you can't afford to do cross-platform properly
No. What I'm saying is, when people search "Blender lighting tutorial" or "Capcut editing tutorial" on youtube, they want to watch the most popular tutorial and they want it to behave exactly like their phone. If there are any differences whatsoever, like an OS specific swipe back gesture, they're going to leave negative reviews that their app is not working.
You want a good unified app experience, with as minimal deviation as possible only where necessary.
If the app is Blender, or some other extremely complex software then sure. If it’s the bank app or social media, it would take me no time to understand the difference between the iOS and Android native UI.
You were wrong to even attempt to share design language across platforms. You should make your applications good native citizens if you have any respect for your users, because yours isn’t the only software they use.
That’s a pretty bold statement. Look at the most popular apps, and you will see across Android and iOS that the designs across platforms are more similar than they are different. We only have 2 engineers right now, but we still maintain clean native implementations for navigation, interactions, and areas where native UI excels. Neither our Android or iOS apps appear as if we just copy-pasted from one platform to the other. Both Android and iOS had been leaning into flat design for years, so it was easy to adapt the same design language for our brand across both. Not so with this return of skeuomorphic design.
I think this idealism reveals a naive viewpoint about what users really care about. They care that apps work - that they do what they're supposed to and do it fast or efficiently. Not even Microsoft makes apps for their own platform that are native apps (example Teams, the new Outlook), and they service millions of users. Indeed, if you look at Microsoft's UI over the years, they are inconsistent as hell (all of the Office apps throughout the years is a good example), but so long as performance, functionality and usability hasn't suffered too much, users are OK with non-native apps that do not appear native. Another example is iTunes on Windows - looks nothing like a native Windows app.
There's also the fact that having control over your own apps UI/design language is better over the long term. What if Apple decides to ditch this liquid glass for something else years in the future? They ditched their own design language in iOS7, and now with iOS26 they've done it again.
And the basis for UI redesigns as wide ranging as this are almost entirely nonsensical. Does liquid glass suddenly improve usability by whatever percent? Nope - I guarantee Apple does NOT interrogate or benchmark their UI designs in the same way as NN Group does. Usability is actually hurt by the fact users need to re-learn basic interactions, and existing ones are now slower. Is overall performance improved over the previous version? Absolutely not - performance metrics such as battery life and UI responsiveness have regressed with the over use of visual effects like translucency and minute pixel manipulations. Why bother following changes to a design language when they are not based on real reasoning backed up by actual data or solid logic, and they end up regressing performance to an even worse state? Why should any app vendor be obligated to follow what are ultimately arbitrary and whimsical changes?
Redesigns such as this result in literally more work for the sake of it, zero net improvements and whole lot of wasted effort, all for what? Just to look different for a while, until the next redesign?
On desktop that ship has sailed. Maybe 2 of my regularly used apps have a native design.
UIs have converged enough that the experience is acceptable I guess. And as a devolper, why in the world would I want to write my app for a locked-in ecosystem with a now shitty design-system.
It hasn't fully done so on the desktop when you consider macOS. E.g. if you ship a macOS app which has the main menu bar inside the window (or missing entirely) instead of using the system menu bar, it will look very jarring and users will rightly complain.
If the only way I interact with a service is a single app then I want that app to blend into my phone. I don't care if the Uber app on Android and iOS are the same, I only see one of them. If I have to use a service on many different platforms, I sometimes prefer having a consistent design language, e.g. I like that Slack has a consistent sidebar interface everywhere. I want to go from the browser to tablet to phone and not have anything in a different spot.
The trend over the past decade has been towards multiplatform frameworks, mostly with React Native, but more recently Flutter, KMP, and even Swift multiplatform.
And here's the thing: The Apple users who actually care about this are in the minority. You just get an outsized sampling of them on HN because they tend to be techies as well.
Our large commercial apps were certified to pass the WCAG accessibility requirements, which we need to comply with for legal reasons. If we did’t enable the compatibility flag and opt out of the glass altogether, this would have meant massive breakages and regressions, which would require the designer and developer time to fix, and the financial burden of having to go through the certification process again. And all because of Apple’s whims and zero benefits for our customers or our developers. Why would we blindly choose to follow Apple’s missteps instead of having our own design system and standards?
> You should make your applications good native citizens
It's time to retire this dead meme. The most successful SAASes in the world are just websites that people pay for hand-over-fist regardless of what OS they use. Netflix doesn't use Liquid Glass, Spotify doesn't bother. Google Docs isn't going to inherit it and probably neither will Office 365. Websites online by-and-large won't adopt this design either.
The ideal of everyone taking the time to make a sexy native UI is appealing. But it's never going to fully be realized, especially when OEMs resist basic A11Y obligations and insist on battery-draining eye candy.
If you're starting from the perspective of a native app developer, you're absolutely correct. However, most startups are going to be websites/Electron/CEF apps. It's much easier and cheaper to write-once-ship-everywhere with an ugly React UI than it is to jump through the hoops of writing special-snowflake versions for every OS under the sun.
It's basically negligent to insist on native apps, if profitability is your goal. I love native interfaces too, but the staunch belief in businesses being a "good native citizen" is a dead meme. It's cart-before-horse logic, we don't ever see anyone commit to the idea and reap real rewards. Native platforms punish you for playing by the rules.
It depends who your application is for. You obviously think building an application is about maximizing your profit, and your users are just a means to achieve that. If you were approaching your application from a “what’s best for my users” angle you might make different choices.
If you are running a business with limited funding (which is most businesses), then your primary need is to seek profit in a world where profit is often never achieved at all. Otherwise, your business ceases to exist, along with your app. Sometimes that does mean emphasis on strong design, which I’d argue means delivering a great experience to your users rather than a native or non-native design choice. Other times, you’re serving a demographic that doesn’t care so much about that, and your focus is on functionality above all.
As a developer, I don't care what Apple or Google's "design language" whims are today. If someone can't figure out how to use a well designed app, no matter the "design language", a fancy skin isn't going to fix that.
I don't think that's true. First line of respect is good UI/UX, second line of respect is being fast/not being slow, third might be being coherent with the rest of the apps on that platform.
Almost nobody uses both an iPhone and Android for their day to day use. It doesn’t matter if your iOS and Android apps don’t look share the same design language, no one is going to see both of them.
And most apps that eschew the base design system while using the same kinds of GUI elements it provides, are usually terrible. Only when the app does something way out of the lane of what the OS provides does it usually work well.
> but now Apple has essentially decided that this Liquid Glass will be mandatory after a year of support for "compatibility mode" that disables it for your app.
What exactly does this mean? Are there references in Apples design guide lines that explain this in more details? (Or wherever this would be documented)
Not really, the point versions have betas as well. I'm on 26.1 beta 2 on iOS.
You should not expect any change in design at that stage normally I guess, but I'm still seeing aesthetic differences, for example the shine around icons is reduced.
This Liquid Glass decision is particularly challenging for my tiny startup. We have multiple platforms including iOS and Android. I was hoping to share much of our design language across iOS and Android, but now Apple has essentially decided that this Liquid Glass will be mandatory after a year of support for "compatibility mode" that disables it for your app.
We'll now have to spend expensive engineering time to cater to Apple's design whims rather than actually working on PMF and profitability.