any caveats when modularising a MPP project?

# multiplatform

[kevin]

any caveats when modularising a MPP project?

[spierce7]

it might make you a better software engineer.

[kevin]

omg, hope not 😆

[Dominaezzz]

There might not be enough granularity (with regards to platform specific code) to allow for modularisation.

[Kurt Renzo Acosta]

Works well on me! But I had to create a "configuration" module for ios to merge all modules into one framework.

[zalewski.se]

@Kurt Renzo Acosta
There is no need for the bridge module anymore, you can create multiple kmp frameworks 🙂

[Kurt Renzo Acosta]

You will have duplicate classes like CoreClass and Module1Class if module1 depends on core

[Michal Harakal]

@zalewski.se I am also interested in more information how not to have “configuration”, “umbrella”, “compositing” how ever we call module for iOS ? I am a big proponent of modularization but having a need for “umbrella” brings me back to single module for a smaller projects …

[Kurt Renzo Acosta]

I filed an issue for this and they said it's only for multiple independent frameworks. If that's your use case, modularization would work!

[zalewski.se]

Well yeah, the key is to have independent frameworks, then there is no need for “umbrella”, “bridge” module . Although I still feel it’s worth to modularize the app. Let’s say we have modules that depends on each other like:

feature1 ---\
------> repository -----> network
feature2 ---/

In such case we can benefit for modular project for Android where in general we gain things like :
• build time of these modules improves a lot
• clear dependencies separation
• reusability
etc..
Then we create this kind of “bridge” module for iOS where it depend just on feature1 and feature2 (via api ) and we also export it to the framework. I don’t think it’s super horrible and if in the future frameworks won’t need to be independent, you just remove the “bridge” and include frameworks like modules for Android 🙂

[russhwolf]

Having an umbrella module to produce a single framework doesn't need to harm modularization. The iOS app is itself is already a sort of umbrella module one layer up. You can still modularize your shared Kotlin underneath it however you want. The limitations mostly come when you're moving between Kotlin and Swift.