Is there a possibility in the future of compose out of the box composable having two looks on differ...

# compose

[Emmanuel Mtera]

Is there a possibility in the future of compose out of the box composable having two looks on different platforms. Ie in ios to get a true ios feel and in android e.t

[jw]

That's not really possible with Compose UI's design today

[jw]

Each composable tends to be built by composing (heh) others and that continues fractally for quite some depth

[jw]

In order to change the entire look and feel you need to switch at a very coarse level of granularity

[Emmanuel Mtera]

Thanks for the info.

[Joel Denke]

I think it would be possible if doing a very granular and smart thoughtful design system, depending what the iOS vs Android actually means.

In most cases its very similar surface structure, and more about gestures and touch interaction differs the most imo. But given that many companies having custom design system and in some cases want same design on both Android and iOS, I think it would be benefitial if going away from Material vs UiKit and make it more foundational frameworks to inject your own shapes, branding stuff etc.

[Casey Brooks]

I recall seeing a discussion on this a while ago, with the comparison made to the Swing LAF. Basically, this idea of themable high-level components sounds good in theory, but in practice is not able to provide the level of fidelity needed to make a UI actually look like the platform’s native UI.

While it seems like one could just adapt the button, text field, and other component styles, it’s worth remembering that the layout and design thinking is quite different across platforms too. For example, on Android one might use a checkbox where iOS uses a switch. Or iOS using a back button in the header where Android might omit it and rely on the hardware back button/gesture.

[Casey Brooks]

That said, there is a library out there for Cupertino styled components. While it’s difficult to make a good-looking and all-encompassing design library for all use-cases (which is why it’s not provided by default), you can absolutely create your own. Setting up expect/actual components which delegate to the Material or Cupertino widgets shouldn’t be too difficult. And in fact, it looks like this library already does provide cupertino-adaptive for common use-cases