Hello, what’s the current state of the umbrella fr...

# swift-export

[François]

Hello, what’s the current state of the umbrella framework pattern with swift-export? Is it still the recommended way by JB?
Some people asked about it, but now, do people try new multi-module/framework patterns instead of the unique one?

[Artem Olkov]

Yes, umbrella framework is the way to go. While Swift Export supports export of multiple modules, this feature does not change the compilation model of Kotlin Native, and relates only to the contents and structure of generated Swift files.

We do not recommend using multiple kotlin worlds in a single application, as the setup is cumbersome.

[François]

Thanks for the confirmation, so the downside still remain (binary and built time on release).
The last one I need to check is code completion from Xcode, huge umbrella is really a pain-point/torture for SourceKit.

[Artem Olkov]

built time on release

There were a lot of work put into performance improvement, please try 2.4.0(-Beta2) - it should be faster and less RAM consuming 🙂

huge umbrella is really a pain-point/torture for SourceKit.

That is true, and we hope that Swift Export will solve that problem - we generate much smaller API surface and that APISurface is sliced onto different modules. If you have a good project to test this hypothesis on - we would love any kind of feedback on the topic

[François]

I will! I soon as possible, but big project (based on Skie) is difficult to migrate to Swift-export, but real study cases 🙂

[Mark Vadeika]

@Artem Olkov regarding swift export and umbrella frameworks: Are you saying that swift export could remove the need for an umbrella framework and allow for modularization? Or that it can mitigate the downsides?

[Artem Olkov]

Are you saying that swift export could remove the need for an umbrella framework and allow for modularization?

No, I'm saying that those problems are unrelated - kotlin compilation model is not changed by the swift export.

But with the Swift Export some problems(huge header file, to be exact) should be not as problematic.

Other known problems of Umbrella frameworks are being addressed - the performance of the compiler is improved and we continue to invest in that area.

@Mark Vadeika What exact problems of umbrella framework have you encountered?

[Mark Vadeika]

My use case was creating API types to be shared between the clients and the server. If each feature has its own module (as well as shared types in a different module), it'd be nice if each of those feature modules can be consumed separately on iOS. That way feature-a can't see the types from feature-b. An umbrella framework (I think) forces every feature to see all the types. In addition to being a bit annoying regarding the name space, I'd think that would also have negative effects at build time because if any feature's types changed it'd update a dependency for every feature module. I didn't actually try this at scale, but I don't think it'd be workable for a very large project.

[Mark Vadeika]

Right now, I can't just publish an XCFramework for each feature because it'd duplicate all the shared types between them, so if two features shared a type they wouldn't be compatible.

[Artem Olkov]

> In addition to being a bit annoying regarding the name space
the namespace mapping would be changed with Swift Export and this problem should go away

> that would also have negative effects at build time because if any feature's types changed it'd update a dependency for every feature module
Please give a try to the incremental build feature of kotlin native, it improves this scenario drastically (debug builds) 🙂
https://kotlinlang.org/docs/native-improving-compilation-time.html#try-incremental-compilation-of-klib-artifacts

> I don't think it'd be workable for a very large project
Well, there's always

a Google Workspace▾

that uses KMP 🙂 Feel free to consult the list of public case studies for more inspiration.

> can't just publish an XCFramework
Yes, and you don't need that.

For your scenario I would argue the best approach would be to move the umbrella module to the iOS application side. That umbrella module would be an empty module that depends on your feature modules. And that umbrella module should be connected to your xcproject through embedAndSign task. This will remove your pain points (each feature module would be published separately, as a klib)

As I said before - we do not expect the build hit for the ios in that mode to be that big - with incremental build enabled.

You can find an example of such integration here - https://github.com/zsmb13/ios-side-umbrella

Such move will decrease the build times of kotlin native, as
1. debug builds are faster
2. there is incremental compilation (needs to be enabled)
3. the compiler builds only active architecture