Hey folks, I have got some questions and would lov...

# multiplatform

[shahroz]

Hey folks, I have got some questions and would love to hear your thoughts on this.

We have developed two native SDKs (android and iOS) in our company.

And since there is alot of same business logic, I was thinking of creating a library(maybe multiplatform?) with ability to publish maven and cocopods artifacts.

That way we will still have two native SDKs but code will be the shared.

Wanted to clarify few things.
1- Does this sound like a good approach?
2- Can multiplatform library has separate aritifacts for native SDKS?
3- Would it significantly increase the size of SDKs?
4- Would our host app be required to add external dependencies of any sort? e.g Multiplatform etc?
5- Anything else, I should worry about?


Any kind of help would be highly appreciate. I have tried looking for similar use cases if anyone else is doing but couldn't find any.

[Jeff Lockhart]

1- Without knowing more about the SDK APIs, it likely would be a good approach, especially if the SDK logic is mostly platform-agnostic or there are existing KMP libraries to utilize.
2- Yes, you can create different binary outputs for each platform target, e.g. jar or aar for Android and XCFramework for iOS.
3- It shouldn't affect the size of the Android SDK at all. The iOS SDK's size would largely be dependent on the size of the SDK's public API, but will likely be at least slightly larger by 100s of KB, to account for the embedded Kotlin standard library. Be sure to mark functions that are not part of the public API as internal, to avoid exporting them in the Objective-C headers.
4- Again, depending on the SDK API, likely no other dependencies would be necessary. KMP libraries are generally self-contained. It's possible you might want to add some additional helper functions to massage the Kotlin/Native Objective-C API to work nicer in Swift. Or potentially some helper functions for working with coroutines or flows.
5- Often the biggest hurdle is convincing developers, especially iOS devs. If you already have isolated SDKs, this may help with the KMP deployment process and potentially team dynamics as well.

[shahroz]

Thanks so much @Jeff Lockhart for the detailed response, much appreciated.

I wanted confirmation about the viability of it, that you provided.

Will start of with migrating one of the SDK module/artifact first, make it via KMP and try to replace it and see how it goes from there.

[kpgalligan]

If it helps, we released this last week. https://github.com/touchlab/KMMBridge. It's for publishing iOS binaries for spm and cocoapods. On Monday we'll be releasing support for hosting everything through maven repos, so you can use GitHub packages, artifactory, JetBrains Space, etc.

[kpgalligan]

Publish to either private or public repos

[shahroz]

Would definitely make my life much easier. Thanks for all the great work, Touchlab is doing in KMM space.

[Vitor Hugo Schwaab]

One tip I have, as someone that has been going through this for the past year, is:
If you can, try starting small.

For example, if the SDKs have multiple capabilities, like networking, persistence (be it Database or not), serialization, etc. try to pick one of these and start there.

For instance, take the networking + serialization.
Create an API Client that has defined methods that meaningful to the SDKs. It will take parameters, serialize, make requests, handle responses, deserialize, and return to the SDKs.
Now the SDKs can drop their own networking and start using the shared one.

This way you don't have to replace the whole SDK at once, but gradually integrate the shared code into the existing SDKs.
Once you cover more ground, you can start replacing the SDK as a whole.

This way you can validate, identify issues, and make your code useful from early on.

[Vitor Hugo Schwaab]

It also helps to sell KMP to others in the company if they didn't buy it yet 🙂

We started with networking, then a rudimentary business logic on top of it, which we added persistence as we needed, and so on.
We also supported JVM since the beginning, as some of our QA and other tooling teams inside the company had some tools in Java, and the cost of doing it — considering we already had Android — was neglectable.

By the time we had a very raw "top-level SDK" these teams were interested and starting building their own tools on top of it.

Our app should hit the market in the near future, but internally a couple of teams are already using parts of the shared SDK to create end-to-end tests and debug other features still in development.

[shahroz]

I went on with the migration but this size thing is such a blocker :/

https://kotlinlang.slack.com/archives/C3PQML5NU/p1666391747511359

[kpgalligan]

That's size on disk or on device? Estimating actual binary size impact is not easy just looking at size on your dev machine. Lots of info is ultimately removed before shipping to devices. We did a bunch of size tests, and summary, ktor and SQL with a bit of logic was about 1.5m, then increases proportionally with additional logic. Non-public class binary size is roughly proportional to swift.

[shahroz]

@kpgalligan yup its a size on the disk.
Thats really comforting to know if its going to be around ~1.5m.

If you could share any sample or anything to back this, it would be very much helpful since i am currently pitching the KMM based library (SDK) instead of our native SDKs to the team and this is one of the concern really hindering our progress.