Swift.CodeCompared.To/Kotlin

Kotlin needs an entry point — fun main() — where Swift lets top-level statements be the program. Beyond that this is the same language wearing different keywords: func is fun, print is println, semicolons are optional in both, and type inference does most of the work.

let is val, and the immutable-by-default habit carries straight over. The only adjustments are cosmetic: interpolation is $name and ${expression} rather than \(…), and a raw string needs an explicit .trimIndent() where Swift strips the indentation based on the closing delimiter.

The operators line up one for one — ?. is ?., ?? is ?:, ! is !! — and the difference is in the unwrapping. Swift binds a new value (if let name = name), while Kotlin smart-casts the existing one: after if (name != null), the compiler narrows the type of name itself, so there is no shadowing dance. guard let … else becomes the ?: return idiom, which works because Kotlin's return and throw are expressions of type Nothing. One real gap: smart casts only work on values the compiler knows cannot change between the check and the use, so a mutable class property (var) will not smart-cast — you assign it to a local first, which is the one place Swift's if let is simply better.

Both languages have a hole at the boundary with an older, unannotated language, and both holes work the same way: a value the compiler treats as non-null but which may be null at run time (Kotlin's platform type String!, Swift's implicitly unwrapped String!). The difference is how much of it you meet. Apple audited its frameworks years ago, so Swift developers rarely see one; a Kotlin codebase on Android or the JVM is calling Java constantly, so platform types are everywhere, and they are where NPEs in "null-safe" Kotlin actually come from. The habit to build: at every Java boundary, write the type yourself as T?, and the compiler starts protecting you again.

Kotlin has no value types (a value class exists, but it wraps exactly one property and is a different tool). So every data class is a reference, second = first aliases, and a var property mutated through one name is visible through the other — the exact bug Swift's structs make impossible. Two consequences worth internalizing. copy() is a method you must call, not something the language does for you, and it is shallow — nested objects are still shared. And the way to recover value semantics in Kotlin is to make your data classes immutable (all val, no var), so that sharing cannot hurt you and copy(field = new) is the only way to produce a changed version. That is the idiom to adopt on day one; it is also, not coincidentally, how Swift developers already write structs.

Both languages have named arguments and default values, which puts them together in a small club. The difference is compulsion: a Swift argument label is part of the function's name and the caller must write it (unless you opt out with _), while Kotlin's names are optional at the call site and exist only when you want the clarity. Kotlin also has no separate external name — the parameter name is the label, so by delta: has no equivalent and you name the parameter for the caller's benefit.

Nearly identical, down to trailing-lambda syntax: $0 is it, and the closure lives outside the parentheses when it is the last argument. Two things to pick up. The lambda's parameter list goes inside the braces ({ first, second -> … }) rather than being declared before in. And Kotlin's scope functions — let, run, apply, also, with — have no Swift counterpart at all; they are lambdas with a receiver, and apply { } in particular replaces the configure-then-assign dance you would otherwise write.

The primary constructor is Kotlin's best syntax and Swift's clearest omission: class Rectangle(val width: Double, var height: Double) declares the parameters, the properties, and the initializer in one line, where Swift needs the properties, the init, and the self.x = x assignments spelled out. Computed properties exist in both (val area get() = …). Property observers become delegates — by Delegates.observable is didSet, and by lazy is lazy var — which is a more general mechanism, since you can write your own delegate.

The call sites are identical (User.make("Ada")), but the machinery is different in a way that occasionally matters: a companion object is a genuine object — it can implement an interface, be assigned to a variable, and be passed to a function — where Swift's static members are not values. Kotlin also has the object declaration, a language-guaranteed singleton, which replaces the static let shared = … pattern you have written a hundred times.

A Kotlin enum class is a fixed set of singletons — closer to a Swift enum with a raw value and no associated values. The moment a case needs a payload, you want a sealed interface (or sealed class) with a data class per case, and then when over it is exhaustive exactly like switch. The ergonomic difference: Swift destructures in the pattern (case .circle(let radius)), while Kotlin smart-casts and you reach through the value (shape.radius). Both compilers reject a missing case, which is the guarantee that actually matters.

Kotlin enums carry constructor parameters, properties, and methods, so most of what you do with a Swift enum ports directly — with two gaps. There is no rawValue: valueOf matches the name and throws rather than returning null, so a failable lookup by payload is a hand-written entries.find { }. And allCases is entries (the older values() allocated a fresh array on every call, which is why it was replaced).

Close to a rename: an interface can declare properties and provide default method bodies, so a protocol extension becomes a default implementation written inside the interface itself. Two differences. A Kotlin interface cannot hold state — it may declare a property but never store it, which is why override val name appears on every implementer. And override is a mandatory keyword in Kotlin, where Swift infers conformance from the signature; forgetting it is a compile error rather than an accidental new method.

Both languages have extension methods and extension properties, and neither can add a stored property. The gap that matters is retroactive conformance: Swift can make an existing type conform to an existing protocol from outside (extension Int: Error {}), which is the trick that makes so much of the standard library composable — and Kotlin cannot do it at all. Note also that extensions are dispatched statically in both languages: the last line of the right column prints "base", because the declared type is what gets looked at, not the runtime one.

Kotlin runs on a JVM that erases generic types, so by default a generic function does not know what T is at run time — value is T will not even compile. The workaround is elegant and has no Swift analog: mark the function inline and the parameter reified, and the compiler substitutes the real type at each call site, so filterIsInstance<T>() works. Swift's generics are reified natively, so you never think about this. Variance is the other adjustment — Swift has no declaration-site variance, while Kotlin has out/in (covariant/contravariant) on type parameters.

Same operations, different place for the mutability. Swift puts it on the binding (a let array cannot be appended to), while Kotlin puts it in the type (List has no add; MutableList does) — so val numbers = mutableListOf(…) is a constant reference to a mutable list, which reads strangely for about a day. Be aware that Kotlin's List is a read-only view, not a guarantee of immutability: whoever holds the underlying MutableList can still change it under you, which a Swift value-type array can never do.

A direct translation: .lazy is .asSequence(), and both languages default to eager collection operations that allocate at every step. The advice is the same in both — the laziness pays for itself on a long chain, a large collection, or a short-circuiting search, and costs more than it saves on a three-element list.

All Kotlin exceptions are unchecked, and there is no throws annotation, so a function's signature no longer tells you it can fail — the information Swift puts in the type system lives in the KDoc, or nowhere. In exchange, the happy path is uncluttered (no try on every call) and lambdas compose without fighting a throws clause. try is an expression in both languages, runCatching is try?, and Kotlin's toIntOrNull family means a lot of code that would throw in Swift simply returns null instead.

Three habits to unlearn. Cycles are not a leak, so weak and unowned have no counterparts and no purpose — a tracing collector finds unreachable cycles that reference counting cannot. There is no deinit, and no deterministic destruction at all: finalize() is deprecated and effectively never runs, so anything that must be released (a file, a socket, a lock) is released explicitly. And there is no defer — the nearest thing is try/finally, or use { }, which closes an AutoCloseable on every exit path. Note the direction of the trade: you stop thinking about retain cycles, and you start thinking about resource lifetimes.

The mapping is unusually clean: async func is suspend fun, Task.sleep is delay, withTaskGroup is coroutineScope, addTask + a value is async { } returning a Deferred, and both scopes wait for their children and propagate cancellation down the tree. Two differences. Kotlin has no await keyword — calling a suspend function looks like an ordinary call, and the suspension is invisible at the call site (which reads more cleanly and hides more). And Kotlin makes you choose a dispatcher (Dispatchers.Default for CPU work, Dispatchers.IO for blocking calls, Dispatchers.Main for UI), where Swift's cooperative pool and @MainActor handle that with less ceremony.

This is the gap that will annoy you most. Kotlin has no actor and no Sendable: shared mutable state is protected by a Mutex (a suspending one, from kotlinx.coroutines.sync) that you must remember to take, and nothing in the type system connects the lock to the data it guards. Forgetting it compiles perfectly. The idiomatic defenses are the ones you already know from Swift — confine state to a single coroutine, pass immutable data, or funnel updates through a StateFlow — but they are conventions rather than guarantees. Coming from Swift 6's strict concurrency checking, this feels like a step backward, and it is.