Swift vs Kotlin: A Comparison from a Developer Who Uses Both

I’ve spent a good while in Android development — that’s actually how I got into this industry — and lately I’ve been picking up Swift more for client iOS projects that need both platforms at once. I get asked often, “which one’s better?” The honest answer is: it depends on what you’re prioritizing, and I want to explain why that answer isn’t as much of a cop-out as it sounds.

On syntax and ergonomics, both are modern and null-safe, so the whole class of null-pointer bugs that used to haunt Java barely shows up in either anymore. Kotlin has sealed class and data classes that are very expressive for modeling state — I use this in almost every ViewModel to represent loading/success/error states, and the compiler forces me to handle every case through an exhaustive when. Swift has enum with associated values, a similar concept with slightly different syntax, plus optional chaining that feels very natural once you’re used to it — though it takes some adjustment coming from Kotlin, since force-unwrap (!) is a tempting shortcut when you’re in a hurry, and its failure mode is a runtime crash that the compiler never warned you about.

Tooling is honestly what frustrates me most on the Swift side. Android Studio (built on IntelliJ) for Kotlin feels far more mature and stable than Xcode, at least in my experience across recent projects — Xcode still crashes or slows to a crawl as a project grows, and SwiftUI previews sometimes freeze for no clear reason until I restart the whole thing. I don’t think this is a knock on Swift the language itself, purely the tooling around it, but it genuinely affects day-to-day productivity.

Concurrency is one area where Kotlin wins clearly for me. Kotlin Coroutines is one of my favorite things in the whole mobile ecosystem — simple to use but powerful, and suspend fun lets async code read like ordinary synchronous code without callback hell. Swift’s async/await is relatively newer than Coroutines, but it’s quite solid now after a few iterations — though I still run into actor isolation edge cases that send me back to the docs, something that rarely happens with Coroutines.

The ecosystems have a different character too. The Android SDK has more third-party library options because its developer base is larger and older — almost anything I need already has a library on Maven Central. iOS’s ecosystem is more controlled through Swift Package Manager, but sometimes more limited for niche cases, and I’ve had to write my own wrapper a few times for something that would’ve been a one-line implementation on Android.

My takeaway: if you can only pick one to learn first, start with whichever platform is more relevant to your target users — if your market skews Android-heavy (like Indonesia), start with Kotlin. But if you can do both, each language will teach you a different way of thinking about state management and concurrency, and that’s made me a more complete mobile developer than if I’d stayed stuck on just one platform.