I'm not an ios dev, but I'm using cmp with materia...

# compose-ios

[Colton Idle]

I'm not an ios dev, but I'm using cmp with material3 and navigation3. I'm using a pretty standard bottom bar, but id love to swap out the bottom bar/navigation in material3 with ios liquid glass tabs (for ios only). according to claude and codex i can't do this easily. what i put there easily is some glass-ish looking tabs, but the default glass tab navigation requires a big rewrite. off the cuff is anyone familiar with this? shouldn't this be something straighforward since compose multipplatform allows you to adopt views ala cart

[Ciaran Sloan]

Sadly, no. Because CMP uses skia which is effectively drawn over the native ui engine on swift. There's no interop with the native liquid glass (yet) but there are alternatives such as shaders which produce a similar effect:

https://kotlinlang.slack.com/archives/C0346LWVBJ4/p1760410923648509?thread_ts=1760085010.727129&cid=C0346LWVBJ4

[Ciaran Sloan]

There's decent chat and explorations shared in that thread, so it's worth a bit of a read

[Mark Murphy]

A few posts and libraries on Compose and Liquid Glass can also be found here.

In particular, this Medium post may be relevant.

[Hristijan]

You have to use expect actual and provide iOS direct implementation otherwise impossible

[Colton Idle]

ooh. some conflicting responses here but I'll have to read up on it after work. Appreciate for the two cents everyone!

[Pablichjenkov]

For the expect/actual solution. You can try this tool: https://github.com/touchlab/compose-swift-bridge

[Colton Idle]

OOOOOH!

[Colton Idle]

might have to implement this by hand lol. every attempt with claude and codex just fails miserably. lol


"No. If the goal is real native iOS tabs, the boundary cannot stop at the navigation bar composable. A native tab bar is not just a view."

AI seems headstrong on completely butchering my app. I was going to try the touchlab tool, but its 2 years old. not sure if thats really something i wanna use lol

[Pablichjenkov]

Yeah it seems a bit outdated. Just check if there is something similar around. Although you can do all the generated code manually.
I think the Library "Calf" does a lot of this boilerplate work, maybe worth checking out

[Colton Idle]

thanks. pointing codex at the library allowed it to integrate it at the moment. cool! it works. woot

[brandonmcansh]

Calf just added liquid glass to adaptive components too iirc

[Christopher Mederos]

personally i prefer this approach instead of using compose-swift-bridge. Mainly because you don't need to add ksp and touchlab dependency baggage to your project

https://medium.com/pink-room-club/bridging-compose-multiplatform-with-swiftui-4c3f19e13f55

You can also combine it with some of the concepts from compose-swift-bridge like using a ViewModel to remember the controller. If it's just a few components in your app, its not bad doing it manually for each

[Colton Idle]

yeah. the liquid glass navigation instead of m3 navigation is a game changer and instantly makes it feel more at home on an iphone

[andrew]

Keep your eyes out for the next major version of haze which looks to be experimenting with a liquid glass shader, too 😉

[Ernestas]

I have experimented with the Calf library, and the bottom navigation component worked pretty much out of the box, although it's still missing some customization options

[wwalkingg]

If you’re okay with writing Swift for the navigation bar, it’s actually trivial—I knocked it out in a couple of minutes. Abstracting it into a reusable, “common” semantic layer is the tricky part.
https://x.com/i/status/2031557179749314781

[Colton Idle]

yeah. i guess my point was that i thought it was supposed to be easy to write an expect/actual for ios specific components. like for gmaps on android and apple maps on ios. in this case i thought it would be a simple swap for bottom nav in md3 and liquid glass bar in ios

[Colton Idle]

@wwalkingg any chance you can put up just a github gist of your example above? lol

[Pablichjenkov]

Is not so easy because kotlin can't see swift code, only objective-c. That's what makes the iOS side rely on some form of SwiftUi-ViewFactory.
This is one of the KMP aspects that has a lot of room for improvement. A lot