My opinion: With iOS 26 and Liquid Glass :droplet: , Apple has helped KMP a lot. Why? How i see it, ...

# multiplatform

[Max]

My opinion:
With iOS 26 and Liquid Glass 💧 , Apple has helped KMP a lot. Why?
How i see it, Compose Multiplatform is good for many use cases, B2B, etc.
But if you want a truly native UI, you need SwiftUI from now on, since no custom shader, Flutter effect or Compose modifier can bring Liquid Glass UX as Apple native has it. It’s just too good.
So for Consumer apps KMP + Swift UI will be the way to go (consume VM from Swift).
Flutter is not setup for this.
React Native has the bridge inefficiencies
Only KMP offers native performance and the ability to use Swift Ui easily.
Future looking bright here 💪🏽

[Simone]

Maybe it helped in KMP, but the situation in CMP doesn’t look good to me.
Since SwiftUI components are rendered under the CMP canvas, the Liquid Glass native components don’t really make sense. I also haven’t seen any planned features addressing this.

At least with React Native, developers already have access to the basic Liquid Glass components.
https://expo.dev/blog/liquid-glass-app-with-expo-ui-and-swiftui

[Anonymike]

This is one I think everyone could easily go a different direction on. Personally I think both Google and Apple making sweeping UI changes, often to the detriment of users and making development very hard independently forced things like React/Native to a point where many apps on both App stores already break from the device's UI intentionally or use out of date libraries intended to match the UI.

The changes with Liquid will be yet another example of this as from the user perspective change is rarely a good thing on day one. Most users don't care about usability the way we think about it once they are used to something. If you change it, even for the better, there well be turbulence. Many of the changes Apple has made I and many others think will greatly hurt accessibility, particularly for older users and those requiring any contrast.

All this is to say they are just going to further splinter an already splintered system. You can download any 10 apps at random from either app store and see varying levels of native vs non-native looking UIs. I'm not too worried about it, rather I'm more worried that this will simply encourage the average quality of apps to go down with slow UIs from generated apps because Apple used Objective-C and Swift to prevent a common development platform, only to end up with React flooding the App Store.

[Max]

@Simone i think for the use cases where CMP excels, one UI across many platforms, it doesn’t matter - since we should not use native components here. So below or above the canvas, it’s not too big of a deal

Personally, being able to have the domain data layer shared in one language is most important

[Simone]

@Max i understand your point but i’m gonna tell you my personal need.
I’m launching a multiplatform app with a paid-only pricing model. Because our prices aren’t the lowest, we need to deliver a fully premium experience, with special attention to details.

For example, iOS users are now accustomed to Apple’s new buttons, which might be the only good UI elements they’ve released lately. Those buttons look premium with their subtle reflections and don’t suffer from the accessibility issues seen in other parts of the design system. Our users will come in expecting the same standard they see in other premium apps—so if they encounter a flat, boring button in mine, it will feel underwhelming. So this is a good example where i could implement custom component just for iOS platforms.

That’s for what I chose CMP for a year ago. Back then, before Apple introduced this unexpected new design system—which, for the first time, exposed a real limitation of CMP—everything felt possible. The whole point of CMP is to provide the best interoperability across platforms, and up until now, they’ve delivered on that promise. A solution seems totally possible but i think it would get more attention

[Simone]

I found actually now a fresh research ticket the jetbrains team did 😄
https://youtrack.jetbrains.com/issue/CMP-8920/Research-usage-of-Liquid-Glass-components-in-Compose

[Anonymike]

@Simone totally agree with you. Native functionality should always be an option. Any multi-platform systems is unusable to us without that. We developed for years fully in iOS Native UI with KMP for everything other than the UI and that is a fantastic option to have even now that we use CMP often. There are some complex components or specific components that will always need this.

[Anonymike]

Just reviewed the ticket @Simone linked and it looks like this may be a non-issue in the end.

[Simone]

@Anonymike I think the only problem will be time, if the way is mimic all the native components with skia and skia shaders it will not be easy.
Dealing with this Apple’s overengineering isn’t just about recreating the shapes and shader, but also replicating all the odd movements and HDR flashes that the components trigger during interactions and navigation

[Simone]

21 Tim Cook on X Expressive Delightful But still instantly famil.mp4,1_6n78UVaJE96CRPiLTu-tQA.gif

21 Tim Cook on X Expressive Delightful But still instantly famil.mp4

[Simone]

Honestly the swiftUI embedding seems the only sustainable way to me, considering also that Apple will make changes over time

[Anonymike]

Yes @Simone that's the method I was referring to. If you truly want their native UI through 90% of your app embedding compose is the better choice.

[Anonymike]

Every time I look at that slider I'm convinced they didn't do usability testing on anyone over 25 lol.