July 5, 2026
Every so often a client asks why I build Android apps in Kotlin instead of Java. The short answer: there isn’t really a debate anymore.
Less boilerplate, fewer bugs. Null safety alone eliminates a huge class of crashes that used to eat up debugging time in Java codebases. Data classes, extension functions, and coroutines cut the amount of code needed to do the same job.
Google’s own tooling assumes Kotlin first. New Jetpack libraries, sample code, and Compose itself are written Kotlin-first. Building in Java today means constantly translating documentation in your head.
Interop isn’t a real blocker. Kotlin and Java classes call each other freely, so legacy Java modules don’t need a risky rewrite before a team can start writing new features in Kotlin.
If you’re maintaining an old Java codebase, there’s no need to panic-rewrite it. But for anything new, Kotlin is the default I reach for without a second thought.
Compile times used to be a real Kotlin weakness. Early Kotlin releases were noticeably slower to compile than equivalent Java, which mattered on large codebases with tight iteration loops. That gap has narrowed significantly with the K2 compiler, detailed in JetBrains’ own K2 migration documentation, though very large legacy modules can still feel it.
Coroutines take real time to learn properly. Structured concurrency is a genuinely different mental model from Java’s thread and callback patterns, and teams coming from a pure Java background need to budget real ramp-up time, not just swap syntax and expect it to click immediately.
Hiring pools still skew Java in some markets. Depending on where you’re hiring, there can be more mid-level Java developers available than Kotlin specialists, which is a legitimate staffing consideration for a growing team, even if it says nothing about which language is technically better.
None of these are reasons to avoid Kotlin for new Android work in 2026, they’re just the honest tradeoffs behind an otherwise easy call. If you’re deciding on a framework more broadly, not just a language, I cover that wider decision in Choosing Between Native, Flutter, and React Native.
If you’re maintaining a large, stable Java codebase with no near-term rewrite planned, there’s no urgency to convert existing files just for the sake of it. Interop means new features can be written in Kotlin inside the same project immediately, letting the migration happen gradually, file by file, as each area gets touched anyway for other reasons.
Where I do push back is on teams starting a brand-new Android project in Java in 2026 purely out of familiarity. The tooling gap has become real: fewer new samples, fewer updated Stack Overflow answers, and a growing share of Jetpack libraries that assume Kotlin-first usage patterns in their documentation, even when Java interop technically still works.
A concrete example: coroutines versus callbacks. A network call chained with three dependent requests in old-style Java callbacks quickly becomes deeply nested and hard to read. The equivalent in Kotlin coroutines reads almost like synchronous code, top to bottom, while still being fully asynchronous under the hood. That readability difference compounds across a whole codebase, and it’s a big part of why fewer subtle concurrency bugs show up in the Kotlin projects I maintain compared to older Java ones.
The debate that used to exist, whether Kotlin was mature and stable enough for production Android work, is genuinely settled. The only live question left is migration pace for existing codebases, not which language to choose for new ones.
Don’t schedule a dedicated “Kotlin migration sprint” that pulls the whole team off feature work, that approach tends to stall out once a deadline pressures the team back onto Java out of familiarity. Instead, set a simple rule: any brand-new file is written in Kotlin, no exceptions, starting immediately. Existing Java files only get converted when they’re already being touched for an unrelated bug fix or feature change, using Android Studio’s built-in Java-to-Kotlin converter as a starting point, then cleaned up by hand since the automated conversion is rarely idiomatic on the first pass.
Budget real time for the team to get comfortable with coroutines specifically, separate from the general Kotlin syntax learning curve. Syntax converts in an afternoon of pair programming. Structured concurrency, understanding scopes, cancellation, and how coroutines interact with the Android lifecycle, takes closer to a few weeks of real production use before it clicks fully. Treating those as two separate learning curves, rather than one, sets more realistic expectations for how long the transition actually takes for a team coming from a pure Java background.
If your team is still debating this in 2026, the debate itself is usually the bigger cost. Time spent arguing about the choice is time not spent shipping in either language.
My own rule going forward is simple: default to Kotlin unless a specific, named constraint says otherwise. That single default has removed a recurring conversation from every new project kickoff since I adopted it.
Every team I have helped move to Kotlin has said the same thing a few months in: they wish they had made the switch sooner, not because Java stopped working, but because the daily friction it removed was bigger than anyone expected going in.
For anyone still genuinely undecided, the lowest-risk path is simply trying Kotlin on the next small feature in an existing Java app rather than committing to a full rewrite upfront. Most developers who take that small first step never go back to writing new Android code in Java again, and the decision stops being theoretical the moment real code is involved.
Two years from now, this whole debate will likely read as dated as asking whether a new iOS app should be written in Objective-C instead of Swift. Getting ahead of that shift now costs almost nothing and saves a harder migration later.
So no, in 2026 there is not really a debate left to have. There is only the pace at which individual teams choose to catch up to where the ecosystem already is.