I'm about to embark on creating a multiplatform li...

# multiplatform

[Carl Hickman]

I'm about to embark on creating a multiplatform library for ios and Android. I don't want to spin my wheels getting started. I'm worried about running into outdated documentation. Where is the most up-to-date information about getting started?

[kpgalligan]

What part of getting started? What kind of library? Internal? Publishing concerns? Just iOS/Android?

[Carl Hickman]

I have an iOS app and an Android app already in production. I'm looking to use Kotlin multiplatform to create libraries that deal mostly with logical issues... think data parsers and workflow management. Maybe even data storage at some point. What I am trying to determine now is if creating a library that can be commonly used for both apps is going to fit into the build process.

[Carl Hickman]

I could see using that library later for web concerns but that is not the goal

[kpgalligan]

In general, the iOS side has more issues to consider. How big is the team, and if larger than 1, are the iOS devs expecting to not know anything about Kotlin or the build (as in, are you giving them a binary or do they need to build source?)

[Carl Hickman]

The plan (or hope really) is to have the library built as a framework they could pull in with Carthage and SwiftPM if possible

[kpgalligan]

I’m far more experienced with Cocoapods. I know some folks are using Carthage. Not sure about Swift PM.

[kpgalligan]

The issue with pulling in a built framework, from my perspective, is you can’t really debug anything at that point, and from a team dynamics perspective, the “iOS devs” never really get on board with Kotlin. We’ve done configs where it works that way by default, but you can flip a switch and build Kotlin locally. Not sure how you’d configure that outside of cocoapods, but you could I’m sure.

[kpgalligan]

I had a long thought piece that I was typing, but I’ll skip it. I think to get started it would be better to describe your source organization and desired build process, and see if anybody’s used that. You might luck out and find a detailed, “Here’s how we did this with monorepo and Carthage…“, but I don’t think theres’s a ton of production build config content out there yet, although there’s some. You’ll almost certainly have more luck finding somebody who’s done Carthage (or whatever) in the slack.

[Carl Hickman]

Getting the iOS devs to buy-in to Kotlin is already going to be hard. I'll have to see about doing what you are suggesting... building Kotlin locally.

[Carl Hickman]

Yes, I need to narrow down the use case like you are saying... envision how the org and build process is going to play out. Thanks!

[kpgalligan]

That’s why we had a dual config, so an iOS dev could just run the build without knowing anything about Kotlin. However, that puts an extra burden on whoever’s building the shared code. It needs to be extra well tested, etc, because if anything isn’t perfect, you’ll hear about it.

[Carl Hickman]

Yeah, I bet. This proof of concept is going to have to be air tight if I want it to succeed

[kpgalligan]

I’ve talked to teams that were just making common Kotlin code and assuming the generated iOS library would work fine, but somebody really needs to understand the implications in a native context. Everybody doesn’t need to understand that, but you know.

[kpgalligan]

I don’t know your particular situation, but I’d try to find somebody on the iOS side who’s at least curious. Get some collaboration.

[Carl Hickman]

Will do. Thanks again for the advice

[kpgalligan]

Good luck!

[louiscad]

Is there a sample with that dual config you're mentioning @kpgalligan?

[edenman]

i would also be interested in this ^