Building Signposts for C# Engineers Racing to Kotlin

A while back, leadership came to me with an unusual staffing proposal. They had a pool of experienced C# developers they wanted to place, and I had open Kotlin positions that required deeper experience than flashy UI and a server API — the kind of skillset that’s genuinely hard to find on the open market. Could we bring these developers up to speed on Kotlin and fold them into the mobile team?

The developers already knew the company. In this organization, most teams didn’t have any real trouble pulling in a developer from outside their vertical. They would need to learn new tooling, maybe a few new libraries, but not a new programming language and hardware stack. But Kotlin is not C#. We needed to bridge that gap efficiently to solve our staffing problem.


Lost in Too Much Familiar Territory

The easy answer? Tell these developers to go read a book, watch YouTube tutorials, or enroll in a Kotlin bootcamp. But the problem becomes obvious pretty quickly.

Most Kotlin learning material is written for a general audience. It starts at the beginning. Data types. Variable declarations. How to return a value. All perfectly reasonable if your reader has never programmed before. But a developer with years of C# experience doesn’t need that level of pedantry. They start skimming, and skipping, and somewhere around page 127, buried in a chapter they half-read, is the explanation of scope functions that would have saved them three hours of confusion next Tuesday.

And self-study has its own trap. Sure, they’ll eventually need to stop writing endless else if chains — but who’s going to tell them to look up when? Who will they trust to explain the difference between let, apply, also, and run? It’s not always obvious where to start, or even that there’s something worth looking for.

We needed something that would show them all the tripping hazards and shortcuts, not teach them how to walk all over again.


Planting the Signposts

Once we identified the current skillset of our audience, we could target the training to their experience level. The skill gap for an experienced C# developer learning Kotlin isn’t the basics. It’s the subtle differences and valuable tools that Kotlin uses to make a developer’s life easier.

I started with a one-page summary of data types — not the ints and Strings they knew by heart, but the core concept of mutability (consider a var List vs a val MutableList) and nullability (why the perfectly obvious !! can cause your app to crash). Once that was established, we could move on to the things that have no real C# equivalent: scope functions, when expressions, data classes, sealed classes. Each one got its own focused one-pager rather than a footnote buried in a chapter about something else.

I wrote a whole series of focused one-pagers, each covering one concept, each with exercises. I wanted our incoming developers, who already understood the basics of programming, to work through the whole thing in about a week. They would come out with a mental map of how Kotlin thinks, and enough confidence to navigate the unfamiliar territory on their own.


Learning to Run

Our first volunteer had spent years working in a low-level language and was genuinely excited to be working in something higher-level again. He went through the entire guide in a single day. Then he started building small apps to prove to himself — and to me — that he’d understood the principles well enough to keep going independently. The guide showed him the terrain. He did the running himself.

It’s easy to assume that training needs to be thorough — start from the beginning and walk forward methodically so nothing gets missed. But experienced developers don’t need a comprehensive guide to get themselves started. They need a few pages of guidance on what’s different, signposts for where to take the next steps, and trust that they can take it from there.

There are plenty of Kotlin textbooks out there if you really want one. But you might save yourself some time by minding the gap.

KMP is What Good Multiplatform Looks Like

When our mobile team started looking seriously at Kotlin Multiplatform, we had a people problem on our hands, not a technology one.

We had two native teams, iOS and Android, building the same business logic twice. The same data calls, the same validation rules, the same utilities, implemented separately, tested separately, and occasionally drifting apart in ways that were subtle enough to miss until a client noticed. Every time the requirements changed, we made the same update in two languages across two codebases just to keep parity.

KMP gave us a way out of that.


What we actually shared

Our first focus was two key areas where we could add consistency and predictability. The first was data processing: building shared logic to generate summary reports from repetitive data transformations. The second was network handling: a shared front-end on our APIs that kept retry logic and error handling consistent, regardless of which platform was making the call.

The trick is to keep the scope small. KMP works best when you’re sharing logic that is genuinely platform-agnostic. Threading strategies in particular deserve caution. Anyone who’s been there knows that getting clever with concurrency across platform boundaries is exactly the kind of thing that produces hard-to-diagnose bugs.

Our migration was partial and deliberate. We didn’t try to share everything at once. We identified the business logic that was most duplicated and most stable, extracted it into a shared KMP module, and let both teams integrate it incrementally.

It made the right problems easier to solve, even if it didn’t solve all of them.


The skepticism

Not everyone on the team was immediately on board. For the iOS developers in particular, the ask was a real one: learn Kotlin, a language they hadn’t been hired to write, in order to contribute to a shared codebase that was built around Android’s primary language. That’s a fair concern and we took it seriously.

In practice it went better than expected. Kotlin and Swift are remarkably similar in design. Both are modern, expressive, null-safe languages that share a lot of the same patterns and idioms. I’ve taught multiple Swift developers to work in Kotlin and not one had a real technical issue picking it up. There are even a few places where Kotlin pulled ahead of Swift — the flexibility of when compared to switch being a favorite example — but that’s a conversation for another post.

The resulting shared module reduced the surface area for cross-platform inconsistencies, and the unit test coverage on shared logic actually improved because we only had to write it once and we knew both platforms were running exactly the same code.

Unlike other cross-platform tools, KMP is built from the ground up for mobile developers. Once the iOS team started working in it, that became obvious pretty quickly.


Why it was a good decision for the business too

Kotlin Multiplatform lets you write shared Kotlin code that compiles to native binaries on each target platform. On iOS it compiles to a native binary. On Android it compiles to JVM bytecode. There is no intermediate interpreter, no bridge layer, no runtime sitting between your shared code and the platform it’s running on. KMP doesn’t ask you to abandon your existing native codebase. You introduce it where it makes sense, layer by layer, and the rest of your native code works just the way it used to.

Upper management was initially worried that KMP didn’t have enough momentum to be worth the investment. The answer has gotten clearer since then. KMP usage more than doubled among multiplatform developers in a single year, rising from 7% in 2024 to 18% in 2025. At Google I/O 2024, Google announced official support for using KMP to share business logic between Android and iOS. JetBrains has been a reliable steward of developer tooling for over twenty years, and with Google now formally behind the technology, the risk profile looks very different than it did even two years ago.

The ecosystem is still maturing, and the library coverage isn’t as broad as some alternatives yet. But for a native mobile team that wants to reduce duplication without giving up the performance, platform integration, and developer experience they’ve built expertise around, KMP is the most natural fit on the market right now.