Hey :wave: This question comes from an iOS backgr...

# multiplatform

[Emre Havan]

Hey 👋

This question comes from an iOS background, and my Kotlin/Multiplatform knowledge is still fairly limited.

One thing we are struggling with is modularisation on the iOS side. Since the shared KMP code is exposed to iOS as a single framework, it feels hard to build a scalable/lightweight modular structure in the iOS codebase. Even if we improve our feature packaging internally (core modules, interface/implementation separation, etc.), most of our feature packages still end up depending on one large shared framework that keeps growing over time. Preventing our feature packages from being lightweight.

So I’m wondering: has anyone found a good way to work around this? More specifically, is there any practical way to reduce or better control the impact of the single generated framework on the iOS side?

A couple of ideas I’ve thought about, but haven’t validated yet:
• Generating a mock for every entity coming from the shared multiplatform code and having them all in a separate package where feature packages can depend on
◦ We would have another “god” package consisting only of mocks, which should still be better than the actual shared code package.
◦ Would require additional effort to register/resolve dependencies.
◦ Feels like too much overhead.
• Somehow dividing the generated framework into smaller chunks so feature packages only depend on what they need (But as far as I understood this is not really possible from Kotlin side)
Has anyone dealt with this before, or found a pattern that works well in practice? Thanks! 🙏

[François]

The umbrella is currently the only way to integrate kmp into an application.
The swift-export will/should remove this limitation.

The modularity should be done into your Gradles files, it’s more flexible than Xcode.

[François]

Kmp for iOS is not light, and more module equal more build time and size.

[Emre Havan]

So I guess there isn't much we can do at the moment to improve this.

Yeah, our shared module is highly modularised and we already see its benefits. However, although this is generally important, it doesn't really help much on the iOS side once everything is built, since the packages will inevitably depend on a heavy framework.

It makes it difficult/pointless to open a package directly and iterate on previews, run unit tests directly and etc.

[Vladimír Púpava]

If you add umbrella (that is app specific module) as dependency into individual swift modules you made them app specific and then they can’t be reused in different apps.

Would suggest adding umbrella only as dependency on top level in app module of swift side. And using DI to wire dependencies.

Bud practicality of this approach depends on what is your approach to kmp-swift split. Works for us with CMP and majority of code in KMP.

[Emre Havan]

Thanks Vladimír. Considering we still manage UI and navigation natively on the iOS side, wiring dependencies into other modules could work, but would result in too much overhead to create an interface for every view model and wrappers for every simple data models on app level to inject them into modules.

I understand that there is no painless way of doing this right, and we might just want to live with its current limitations to avoid overhead.