I wrote my last post about a month before I left Autodesk (what may be my last iOS development role). After 10 years of doing iOS development in some form, I got an opportunity to switch to web at another company, and I took it.
If you're starting a new Kotlin multiplatform mobile project, I think starting with ktor for your networking layer is a reasonable choice. If you're planning to add Kotlin multiplatform to an existing project, this may not be desirable for a couple of reasons:
When getting Kotlin integrated into your iOS and Android teams' workflows, something you will need to tackle is figuring out how to debug your iOS-ready Kotlin from Xcode. This quest may lead you to some of the following resources:
At Autodesk, my colleagues and I are more than a year and a half into our Kotlin multiplatform (KMP) shared library journey. That's one Kotlin shared library, shared among our three mobile platforms that we support for the PlanGrid app (iOS, Android, and Windows).
Once you get your Kotlin multiplatform proof-of-concept in a working state, you'll want to get your build ready for integration into your team's workflow. This means CI that builds your library and runs the tests on every platform you support. This also means a build setup that allows playing with changes to your multiplatform library in a local debug build of your app. And finally, you'll want to distribute the library for consumption in your application. Now, each of those pieces could be its own article. My goal here is to help you understand the basics that, when put together, can be used to accomplish each of those goals.
Co-authored by Phill Farrugia
After you get a feel for the language and do some Koans, the next step in your journey to writing Kotlin for iOS is understanding what that Kotlin is going to look like from the Swift in your iOS app. The way Kotlin reverse interop (Swift talking to Kotlin) works is via Objective-C. For some, discovering that they get an Obj-C header from their Kotlin library, instead of a Swift one, is disappointing. That’s an understandable reaction. In a all (or majority) Swift code base, you and your team may have spent a lot of time building out your project using all that Swift has to offer — even the stuff that’s not compatible with Obj-C.
Hello! I'm Ben. I'm an iOS engineer at Autodesk where I work on the PlanGrid app. PlanGrid is a construction productivity tool that works on iOS, Android, and even Windows 😱. The iOS version is written in Swift (some Obj-C too because it's older), but now most of the code I write day-to-day for the iOS app is in Kotlin.