Hey! :wave: I have an app for Android purely in Compose and I’m in the middle of migrating it to Com...

# multiplatform

[Nacho Ruiz Martin]

Hey! 👋
I have an app for Android purely in Compose and I’m in the middle of migrating it to Compose Multiplatform.

The migration to iOS is quite simple since the mapping is 1:1 in terms of screens and components.
But I want to make also the web app. There will be some major design changes, as it is expected since the web will include several mobile screens in the same screen. For the sake of naming, I’m calling them `Component`s.

The question is, how do approach this kind of project in terms of architecture? Some small components may be identical in the mobile and the web version but others will be different. Also, is it OK for a single web screen to aggregate several components with their “ViewModels”? And, finally, there are some really small differences like the usage of imePadding that make sense in some platform but not in others.

I’d like to get your opinion on the matter!
Many thanks

[Pablichjenkov]

You can talk about this subject for a full month but in short the name tells you all, "Compose". You decide where, when, how and what to compose. Your approach is the one I would do. Small components that you compose to form bigger ones.
The Composable WebApp() doesn't necessarily have to be the same as Composable IosApp() or AndroidApp(). They reuse components but may have differences especially in root layouts

[Nacho Ruiz Martin]

Thanks for your answer!
Honestly, I was hoping for a more concrete answer but I get that it depends so much.
The more I give thought to this, the more I think the web should be implemented standalone and just share the minimal components.

[Pablichjenkov]

Especially when you start integratiing 3rd party libraries, you will notice that web APIs are always a bit off in comparison to Android and iOS. And that makes it difficult to wrap 🌯
So I agree on web standalone as of right now.