Hello :spock-hand: It's been a while since I've ...

# multiplatform

[galex]

Hello 🖖

It's been a while since I've tried Multiplatform and I have a question about it for the iOS side 😊
I'm mainly trying to cut dev costs by using KMP but I'm scared it won't scale well.

Let's say we have many (30+) SPMs in the iOS project, is it scalable if that SPM would transform into a KMP project instead of an iOS project like today?

I am mainly scared of the size of the LLVM that will be packaged with each SPM, so
• Does it actually work to have multiple times the same LLVM packaged inside many SPMs?
• How big of an overhead it is? Last time I checked it was around 14Mb per library, which seemed insane at the time
I'd love to hear your thoughts/experience in the matter 😊
Thanks in advance!

[Jan Holešovský]

What exactly do you mean by "SPM" and "LLVM"? 😉

[galex]

By SPM I mean Swift Package Manager, their new way of having dependencies in iOS
By LLVM I mean everything that is package inside a .framework from Kotlin that isn't the code you want to share, like the kotlin stdlib if I remember correctly)

[hfhbd]

You „can’t“ depend on multiple binary frameworks generated by Kotlin due its closed world model which makes casting and comparing extremely complicated. Instead you should rely on one big framework.

[galex]

That's not going to go well with the iOS Tech Lead and the architects of my company 😭

[galex]

It makes sense but sounds like we shouldn't go that path then

[Jan Holešovský]

But you can have this one shared.framework consisting from multiple Kotlin projects; they are then linked statically into this one big framework, and the linker cuts loose ends that are not exported...

[galex]

I'll do a POC to check that, thanks

[Pablichjenkov]

It depends on the App architecture of course, but I don't see a reason why you would need to re-write or re-do the swift packages in kotlin and package them into the big umbrella framework/xcframework/podframework, whatever you decide to use.
I would rather keep those imported on the swift side as SPM packages then create a kotlin thin layer to just bridge to them from kotlin.
Is more work and a bit tedious because you need to map the same swift API in kotlin manually but size wise is more efficient. Hopefully this year direct kotlin to swift library binders are generated automatically by the kotlin compiler. So we would avoid this manual work.

[Jan Holešovský]

@Pablichjenkov: I was answering under the assumption that they have their own SPMs they want to rewrite for code reuse to Kotlin and share between Android & iOS; but yeah, there might be many scenarios out there... Either way, a lot is possible with KMP, combining code back & forth, so hope @galex finds something that works for him.

[Pablichjenkov]

Ah right, got it.
I don't see any inconvenience in using a big unifying framework. Not sure what overhead it may cause. But if the iOS team doesn't like that approach they still have other options.
There are many ways with KMP you are right.

[galex]

@Pablichjenkov I'm thinking about new developments which could be developed once in Kotlin and then reused in the iOS project but if we need to make a big one framework because the same code is packed in each .framework each time, yeah that doesn't bode well...

Is there an option to make an SPM with the stdlib and all the necessary stuff and make any KMP output for iOS an SPM that depends on that one?
I'll definitely look for more info about direct output to Swift, but is that going to change the fact that some extra code will be packed with the generated Swift code?

[Pablichjenkov]

You really made me think 🤔 about a subject that I would ever assume works the same way as traditional java compilation. Not sure if kotlin native changes anything but in general kotlin compilation is dynamic not static. The fact of importing a dependency doesn't mean it will be included in the package. It just tells the build tool(Maven/Gradle) that the specific library depends on it, eg: stdlib, but it doesn't include the stdlib in your library, it just compiles and links against it. In the final build, when the application is built. Then the build-tool pulls the stdlib and resolves the bindings/links to it and bundles the final binary with only one binary copy of stdlib.
As long as all your packages are .klibs it will do these, somebody correct me if I am wrong.
Now in your case, I think you want to generate a .framework file for each of your modules/`spm-packages`. In that case I am not sure but I think you are right, kotlin bundles everything repeatedly for each package. But I am not 100 percent sure, hopefully someone share more details.
But in such a case I would stay in the klib zone.

[galex]

I really appreciate your look on this, thank you @Pablichjenkov 💙