Kotlin or Java? How We Pick the Language for a New Android Build

Almost every Android kickoff call includes some version of the same question: Kotlin or Java? For a brand-new app, the answer is Kotlin in nearly every case we have seen. But the verdict matters less than the reasoning behind it, because that reasoning ends up steering the whole architecture of the app, and the long-term cost of maintaining it.

This article lays out the decision process we run before writing the first screen: why Kotlin wins by default, where Java still earns its place, how to migrate an existing app without a risky rewrite, and what to ask yourself before you commit.

The short answer

Choose Kotlin for new Android code. Google made Kotlin its recommended language for Android development in 2019, and new Android APIs, documentation and samples have been Kotlin-first ever since. Keep Java where you already have a large, stable Java codebase that your team knows well, and add Kotlin gradually rather than rewriting.

That recommendation is the same for a small single-purpose app and for a large product. What changes is how you apply it: a new app starts clean, while an existing app needs a migration plan.

Why Kotlin is the default for a new app

Jetpack Compose is built for Kotlin

Jetpack Compose is the current standard toolkit for building Android interfaces. It is designed around Kotlin language features such as lambdas, default arguments and extension functions, and it is impractical to use from Java. If you want the modern UI toolkit, you are choosing Kotlin.

Null safety removes a whole class of crashes

NullPointerException has long been one of the most common causes of crashes in production Android apps. Kotlin's type system distinguishes nullable and non-null types, so the compiler flags the problem before the code ships. In practice that means fewer emergency patches after a release and a calmer first week on Google Play.

Coroutines make asynchronous code readable

Almost everything interesting in a mobile app is asynchronous: a network request, a database read, a background sync. In Kotlin, coroutines let you write that code in a straight line. The equivalent Java usually means callback chains or an extra reactive library, both of which are harder to read and to test.

Less boilerplate, more intent

Data classes, properties, extension functions and sealed types let you express the same logic in fewer lines. Less code is less to review, less to test and less to get wrong, which matters most when a small team owns the app for years.

Where Java still earns its place

None of that makes Java a dead language for Android. There are real situations where staying with it is the sensible call.

• A large, stable Java codebase. Rewriting it in Kotlin purely to switch languages rarely pays for itself. Kotlin interoperates cleanly with Java, so new Kotlin modules can sit next to existing Java code.
• Deep Java expertise and a slow-moving app. If the code rarely changes and the team knows Java well, consistency can be worth more than migration.
• Libraries and SDKs with Java-first APIs. These still work from Kotlin, but you should check that wrappers and generated code behave well on both sides.

In those cases we treat Kotlin adoption as something to phase in, not a wholesale rewrite done for its own sake.

The decision process we run

Before choosing, we work through five questions. They take about an hour in a discovery call and save weeks later.

1. Is this a new app or an existing one? New apps start in Kotlin. Existing apps get a module-by-module review.
2. Who will maintain it in two years? The best language is the one your team can keep improving with confidence, including the engineers who join after us.
3. Which UI approach are we using? If the answer is Compose, the decision is already made. If you must keep the View system for a large existing screen set, Java and Kotlin can coexist.
4. Which libraries and SDKs are unavoidable? Check them for Kotlin support and for maintained releases.
5. What is the cost of being wrong? A slow, careful migration is cheap to reverse. A big-bang rewrite is not.

Migrating a Java app to Kotlin without a rewrite

A gradual migration keeps the app shipping while the codebase improves. The approach we use looks like this:

1. Stop adding new Java. Agree that all new files are Kotlin from today.
2. Add tests around the code you will touch. Characterization tests that capture current behaviour make conversion safe.
3. Start at the edges. Convert leaf classes with few dependencies first, such as utilities, models and small view models.
4. Use the IDE converter, then review by hand. The converter produces working code that is rarely idiomatic. Replace getters and setters with properties, loops with collection operations and nullable flags with proper types.
5. Protect the Java callers. Annotations such as @JvmStatic and @JvmOverloads, and clear nullability, keep remaining Java code working.
6. Move to Compose screen by screen. New screens in Compose can live inside the existing navigation, and old screens can be replaced when they next need real changes.

What it means for budget and timeline

For a new app, choosing Kotlin and Compose rarely changes the price on its own, but it changes what happens afterwards. Less boilerplate and fewer null-related bugs mean faster iteration and cheaper maintenance. For an existing app, a gradual migration spreads the cost over normal feature work instead of creating a separate project with its own risk.

Most of our Android projects take 6 to 16 weeks, depending on scope. The Starter App package is a native Kotlin app with a focused feature set, and larger packages add a custom backend, notifications and a store optimization pass. The Android development page lists what each includes.

How this plays out in our own apps

The Android apps we publish, including Maya: Yoga for Beginners, Matric Guru, Traffic Quiz, English Grammar and CVForge, are built natively. Matric Guru in particular is native Kotlin so that it stays light and fast to open on the low-to-mid-range phones most of its students use. Choosing a language is partly a decision about the devices your users actually own.

A checklist before you choose

• I know whether this is a new app or an existing codebase.
• I have named the people who will maintain the code in two years.
• I have decided on Compose or the View system for the interface.
• I have checked that every required SDK works well with Kotlin.
• If I am migrating, I have tests around the first modules I will convert.
• I have agreed a rule for new code: from now on, Kotlin.

If you want a second opinion on an existing app, choose "Improving a product" in our project brief and tell us what you have. We start with a short review of the codebase before proposing any work.