https://kotlinlang.org logo
Join Slack
Powered by
Hi everybody, in our company we are evaluating KMP...
# multiplatform
m
Hi everybody, in our company we are evaluating KMP for sharing business code between our supported platforms: Windows, Mac, Android, iOS (potentially also JS since desktop UI is using it) - in this order of importance. We are deciding between sharing code in C++ library vs. KMP. Have someone already done a comparison? What is the biggest advantage to KMP when compared with C++ solution. Thank you for help.
b
To me personally biggest advantage of KMP vs C++ is that it has GC and looks the same, no matter the platform. The ugly part is when you have to integrate with platform APIs, which is usually a mountain of pain on Native and to a much lesser degree on JS.
Also KMP library ecosystem is much smaller and a bit more fragmented when compared to C++. You can have a look at it yourself here.
So on native at least you're often left relying on C libraries instead.
m
Thank you, (as devil's advocate)
it has GC
no expert - but isn't solution for KMP GC on each platform different?
looks the same, no matter the platform
in theory you can have C++ code same as well, but there are platform specific differences that might be comparable to the 
expect/actual
code needed in KMP, right?
b
You're right on both counts. To clarify, by saying it looks and feels the same I made an assumption that you'd write your non-shared jvm and android stuff in kotlin too. So to better rephrase it - it looks and feels the same as your platform specific modules for jvm and android.
m
KMP library ecosystem is much smaller
you mean smaller that you don't have a lot of solutions yet? I assume you don't talk about size of framework 🙂 (which is also one of the features we are researching)
b
Smaller in terms of libraries available. I cannot comment on size of produced binaries.
And even smaller yet for your particular combination of target platforms.
Filter out by your set of targets on that website I've linked and see for yourself. It indexes all kotlin libraries on maven central.
👀 1
m
does look very bleak for KMP indeed 🙂 but I might find the same when I would like to do cross platform with C++
currently the biggest issues we were discussing were: • support for MacOS Silicon M1 (so any new mac book), • MinGW vs. MSVC (latter is currently used in company) - I read that for best interoperability (symbols) it is best to use C headers instead of C++, • then size - but I have no comparisons yet
b
Kevin Galligan talks about binary sizes for ios in this

talk▾

at one point
🙏 1
m
That was actually the platform we are most concerned about.
BTW, regarding size - how does reusing of transitive dependencies work in KMP native? is it possible to have e.g. protobuf library used in KMP library A and KMP library B only once?
b
I think so, but don't quote me on that.
m
np, I will try to post in channel as well - can't find any reference yet
b
I mainly work around jvm/js kmp and only dabble in native, so not too sure how things work there.
m
My impression so far is that JVM/JS + iOS is the main focus for KMP/KMM right now 😄
b
I know for sure that jvm/js manages transitive deps properly. You might get duplicates in js sometimes if you end up with dep tree that has multiple different versions for the same package resolved
k
There are a lot of statements here. Quickly...
Smaller in terms of libraries available
Yes and no. Strictly speaking, in native mobile let's say, while you have access to a lot of C++, the world of things targeted at native mobile, and the community around them, is pretty different. I don't know the C++ community deeply, but with Dropbox throwing in the towel (https://github.com/dropbox/djinni), I would guess it's not a huge growth situation. Now, in this situation, you're looking at several other platforms, so that changes things a bit.
BTW, regarding size - how does reusing of transitive dependencies work in KMP native?
is it possible to have e.g. protobuf library used in KMP library A and KMP library B only once?
Yes and no. You cannot create multiple Xcode frameworks, each from a different KMP library, and have them talk to each other. You'll need to wrap library A and B in a terminal Xcode framework that is imported, but then that will have a single copy of everything. It's a long story and a much asked for feature, but for now you need to create a single framework (and probably ongoing. The Kotlin compiler is very conservative in what it includes for size reasons, so when compiling lib A it'll only include the parts of protobuf that lib A needs, and it won't know what part of protobuf lib B needs, and vice versa. Multiply that significantly for Kotlin stdlib)
Back on libraries, it depends on what you want/need. Some things are well covered (db, networking), some things less so (mocking, arguably DI, depending on how you view it)
The "why Kotlin" is a long discussion, but I try to boil it down. This talk is ancient now (2019), but I start with my condensed pitch early on:

https://www.youtube.com/watch?v=oulHKSUAuCk▾

🙏 1
✅ 1
m
Thank you very much, went through the talk just now 🙂 As previously stated, we are focused currently on 2 options of sharing code between platforms: • KMP, • and C++ library, I am an Android developer, so I am biased towards KMP 🙂 We also have a good Android community in the company, so I believe that it is certainly an option. That said, company's main product is on Windows and that will be our primary target. Other option is to say that we do not share with Windows 😄 Since I was leading both Android and iOS teams, I strongly agree that we share quite a lot of logic (architecture, viewmodels, etc.). Currently Apple platforms are sharing Obj-C code, so if we want to replace it we need to think of MacOS as well. I already have experience with sharing C++ code between platforms (it was a library for cloud file sharing). And I know it works, so I wanted to compare these 2 solutions more closely (since I cannot find anything similar on net - might have to write something myself 😄). If I go by your pitch (being a devil's advocate 😈): • optional - I would argue this is true also for C++, as you can switch business logic gradually as well, • natively integrated - I think it is close to native with C++ as well right? JNI? interoperability is good (even fast enough), • open source - I don't know if this matters with C++ as we are not using any multiplatform platform there, • code sharing platform - same as with open source - C/C++ is share-able by default, • popular language - from experience it is easier to find Kotlin than C++ developer, but since we already have a large base of C++ developers - this might not stand 🙂 • non-ui focus - again seems like C++ solution has the same advantage, My arguments so far for Kotlin are: • high level language development (instead of lower level C++), • native code (JVM) instead of JNI for Android (even though possible, it gets complicated with more advance usage), What do you think? Am I forgetting something or I am understanding something wrong?
k
I think we need to talk about these things in degrees. Is integrating with C++ "optional" and "native"? Arguably yes, but the interop between Kotlin and JVM is seamless. Kotlin is the default Android language. JNI is definitely not. It "works", but it's not fun. Also, there are performance considerations doing JNI. The Kotlin interface to iOS, while not as seamless as JVM, is quite good (relatively speaking). Also, Kotlin native is designed to mount existing Objc code through cinterop, and uses platform-specific source sets to allow you to easily mesh "native" and "Kotlin" code. It is designed for this use case, where I'd argue C++ is not so.
While certainly there are more C++ devs, you'll generally find mobile "product" devs who are happy with C++ and fluent in app-level code (vs hard core system code) are going to be more difficult to find and recruit. Kotlin is popular, and a more dev-friendly language (highly subjective, of course)
The JVM-side is a huge deal, in my opinion. C++ is an entirely separate ecosystem.
For Windows, check out the autodesk stuff (blog posts, etc). They've been doing Windows KMP for a while: https://github.com/Autodesk/
👀 1
🙏 1
m
True, this one is good. If we talk only about integrating full C++ library - you are good - but integrating it in the middle ( C++ depending on native, e.g. obj-c ) will be an issue.
b
I like how this had barely anything of interest to me, but evolved into quite in-depth analysis of kotlin ecosystem. Somebody put it in a blog form for the future (as I'm sure this question will keep coming up) :)
👍 3
k
In summary, though, comparing in a checklist is tough because the people evaluating will put more weight on different things. If somebody really prefers C++, they'll view the mobile C++ community as more active than it really is, for example, or be more willing to put up with various negatives of the language/ecosystem. I can't say "who", but we worked with a team where the whole team wanted KMP, but the head of mobile is an "old school" C++ dev, so he just decided they'd do C++. That was it.
Now, I haven't chatted with them in a while, but I'd be interested to hear if anybody's quitting now that the pandemic is slowing down. Picking an ecosystem that your devs aren't interested in is a risk.
❤️ 1
but evolved into
I write a lot of half blog posts in the Kotlin slack, but get too busy to follow through. I mention this in the 10 questions video 🙂
b
Yeah, If only slack would be google-able
Gitter can do it, why not slack? 😕
k
That's a big topic, btw. There's a lot of lost info here
b
I know, there's also been many big discussions about this here too. No easy way around it, unfortunatelly.
While slack is great for getting quick help for your own questions, I think it's also shooting Kotlin in the leg a bit, because people ignore more "persistent" help channels like stack overflow or kotlin discussions
k
Well, SO has been less of a go-to for the last few years, and was just sold. Nothing has really replaced it, so there's a problem, and room for some kind of fix. I check out SO every day in the morning and try to answer stuff, but I definitely feel like most people come here and just chat.
m
I agree that internal politics/culture will have enormous weight ( which doesn't have to be a bad thing, in a sense, this just isn't for us / our team ). That said, it is a risk either way and talking it through should help discover at least the big deal breakers for the company ( might differ by the company / team ). One more note, I have just heard a company moved to ReactNative because they have a lot of web devs ( primary product ). That reminded about a switch of Amazon to AWS "because they had a lot of backend/infra devs laying around". Often the best decision might be based on the type of people/software you currently posses.
k
Often the best decision might be based on the type of people/software you currently posses.
True. The "on the other" hand danger is if you have a hammer, everything is a nail (or at least looks "nail like"). ReactNative, for example, carries with it a whole bunch of tradeoffs on a purely technical level that are unrelated to the skills of the devs (and in some cases can't be worked around). Were it super solid and the obvious choice, everything else would be getting crushed at this point I think, but they're not. However, if you talk to a React web dev, they'll have the tendency to discount those issues.
I was at Google I/O, I think 2019? I talked with somebody from the Android team (well, several, I know them), the Flutter team, and the Chrome team. The Android people think native is sticking around, the Flutter team really believes it's just a matter of time, and the Chrome team person honestly thinks native apps are still around because of legacy code and it'll all be PWAs in a few years. It is very difficult to see past your context (same for me 🙂
😄 1
b
But same can be said about Kotlin enthusiast as well. Granted to a lesser degree, since Kotlin is a lot less opinionated.
k
Oh, I'd say same can be said for Kotlin, and not necessarily less. It's important to assume that some part of you is actively trying to fool itself into affirming the things you already believe.
b
This is getting philosophical now 😄 One could make the same argument(s) for most of the things in life
k
Oh, for sure
m
Only time will tell, which one will persevere :) Best thing is to make a decision and act ( unless you are Google and you make bets on multiple multiplatform options :D )
b
You can't loose if you bet on all the horses...
true story 1
m
Looking at why djinni was discontinued and this is pure gold. https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android Some of the overhead mentioned applies to KMP, IMHO. But others are great arguments why not to go with C++.
k
I'd say that some of it does, but the way it's written, it kind of tries to apply those problems way too broadly. I'd have to dig on twitter, but I summarized it as, "Great post on why you shouldn't share code with C++". I was at this talk at Droidcon SF, which was all about the post. Note the end, after explaining why shared code is not great, he adds how Dropbox is using Rust to share code and why it's great. Lots of cognitive dissonance. https://www.droidcon.com/media-detail?video=380845836
I think the value here is it's all about the details and nuance. It's not "cross platform sucks". Different use cases, different tech, it all matters, and you can't paint everything with the same brush and make informed decisions.
m
didn't watch it fully but checked the part you mention they use the rust solution for desktop platforms: Windows/Mac/Linux something I am observing myself (but not certain yet) is that desktop and mobile worlds are quite different - and trying to make something for everybody will just end up having something for nobody 🙂 I still wonder if Dropbox is experimenting with / evaluating KMP on mobile or they just burned themselves with C++ effort and are not going to try again
Also interesting argument about Android and iOS diverging - maybe it is just old - but my experience is complete opposite - I find more and more similarities between the two platforms. The moment Apple announces something, we can be sure that next IO it will be on Android 🙂 Swift ~= Kotlin SwiftUI ~= ComposeUI etc.
b
You should approach code sharing in layers for such a diverse set of platforms
Common layer that's very thin and is shared accross all platforms (business logic, converters, other utils). Then you branch out into more specific layers for subsets of platforms like mobile, desktop (web can also be thought of as desktop for the most part) and shove more specific code in those (view models, middlewares, client services)
Which is one of the strengths of KMP, it doesn't force you into a particular way of doing things. You're free to manage code sharing however you like.
39 Views
Open in Slack
PreviousNext
Powered by