Kotlinmobile

Why Kotlin for Android

Modern JVM language with null safety and coroutines

v1.1·9 min read·Kenneth Pernyér
kotlinandroidmobilenativecompose

The Problem

Android has 70% global market share. Any serious mobile strategy must include Android. But how?

The cross-platform pitch sounds compelling: write once, deploy everywhere. The premise was that human developers are expensive, so sharing code between iOS and Android saves money.

AI-assisted development breaks this premise.

When AI generates Kotlin as easily as Dart, the "write once" advantage disappears. What remains are the disadvantages:

  • React Native's JavaScript bridge is a runtime dependency you don't control
  • Flutter's Skia rendering engine is a runtime dependency you don't control
  • Both require plugins for platform features—more dependencies
  • Both lag behind platform releases

Cross-platform frameworks solved a human productivity problem. AI solved that problem differently. Now we can choose based on control, performance, and dependencies—not typing speed.

Java is Android's legacy, but Kotlin is its future. Google declared Kotlin the preferred language in 2019. Jetpack Compose requires Kotlin. New Android APIs are Kotlin-first.

The question isn't whether to use Kotlin—it's why would you accept cross-platform dependencies when you don't have to?

Current Options

OptionProsCons
React NativeJavaScript/TypeScript with native bridge.
  • Code sharing with iOS and web
  • Large ecosystem
  • Hot reload development
  • Lower barrier for web developers
  • Bridge latency for native features
  • Android-specific features require native modules
  • Debugging across JS and JVM is painful
  • Expo limitations for complex apps
FlutterDart with Skia rendering engine.
  • Pixel-perfect UI control
  • Fast development with hot reload
  • Growing ecosystem
  • Single codebase for both platforms
  • Not native Android UI (custom rendering)
  • Platform integration via plugins
  • Dart ecosystem is smaller
  • App size overhead
Kotlin + Jetpack ComposeGoogle's modern Android stack.
  • Native Android performance
  • First-class access to all Android APIs
  • Null safety built into the language
  • Coroutines for async programming
  • Android only (no iOS code sharing)
  • Requires Android expertise
  • Compose is newer (but stable)
  • Two separate mobile codebases

Future Outlook

Google is all-in on Kotlin. Every new Android API is designed for Kotlin first. Jetpack Compose is the future of Android UI. Java on Android is maintenance mode.

The cross-platform premise is obsolete.

React Native and Flutter solved the "two codebases" problem by adding abstraction layers. These layers are runtime dependencies—code that runs between your app and the platform, maintained by someone else, on their roadmap.

AI-assisted development solves the "two codebases" problem differently: by making codebases cheap to produce. When AI generates Kotlin as easily as Dart, the productivity argument for cross-platform collapses. What remains is: do you want runtime dependencies or not?

Kotlin's advantages compound over time:

  • Coroutines provide structured concurrency without callback hell
  • Null safety eliminates the most common crash type on Android
  • Extension functions let us add capabilities to platform types cleanly
  • Direct platform access means no waiting for plugins to support new APIs

For Converge, the Android app must match the iOS app in quality. Users switching between phones shouldn't notice a difference in reliability or responsiveness.

Native Kotlin delivers this—with zero dependencies between our code and the user.

Our Decision

Why we chose this

  • Null safetyKotlin's type system distinguishes nullable and non-nullable types. NullPointerException—the most common Android crash—is eliminated by design.
  • CoroutinesStructured concurrency makes async code readable and safe. Cancellation propagates automatically. No callback pyramid.
  • Jetpack ComposeDeclarative UI that matches SwiftUI's model. State management is built in. No more XML layouts and view binding.
  • Java interopKotlin calls Java seamlessly. Every existing Android library works. Migration can be gradual.
  • Platform accessBiometrics, KeyStore, WorkManager, widgets—everything Android offers, we can use directly.

×Trade-offs we accept

  • Two codebases (no longer a blocker)We maintain Swift for iOS, Kotlin for Android. With AI-assisted development, two codebases cost weeks, not months. Less than the ongoing cost of cross-platform dependencies.
  • Android fragmentationSupporting Android 8+ means handling device variations. This is Android's problem. Cross-platform frameworks don't solve it—they add their own fragmentation on top.
  • Gradle complexityAndroid's build system is powerful but complex. We invest in build configuration as infrastructure.

Motivation

The reasoning mirrors iOS: Converge handles business-sensitive decisions. Android users deserve the same quality as iOS users.

Eliminate runtime dependencies.

React Native puts a JavaScript bridge between your app and Android. Flutter puts Skia between your app and the screen. These are dependencies you don't control, maintained by teams with their own priorities.

With AI-assisted development, native code is no longer expensive. Why accept dependencies when the original reason for them—human productivity—has been solved differently?

Kotlin gives us:

Null safety by default — The compiler catches null errors. This alone prevents the most common class of Android crashes.

Modern async with coroutines — Business operations are network-bound. Coroutines make async code readable and correct.

Direct platform access — Google builds Android for Kotlin. No plugin, no bridge, no waiting.

The parallel with Swift is intentional. Both are modern, safe languages designed for their respective platforms. Both have declarative UI frameworks (Compose, SwiftUI). Both prioritize developer experience without sacrificing performance.

Two codebases? Yes. But two excellent apps with zero runtime dependencies between our code and the user.

Recommendation

For business-sensitive Android apps: Kotlin is the only choice. Java is legacy. Cross-platform adds dependencies without sufficient benefit—AI has eliminated the productivity argument.

For Jetpack Compose: Adopt it. The old View system is maintenance mode. Compose is the future.

For teams: The skill shifts from "can write Kotlin" to "can review Kotlin and understand Android patterns." AI handles syntax; humans handle architecture.

For existing React Native/Flutter apps: Evaluate rewrite cost with AI assistance. Removing runtime dependencies may be cheaper than you think—and the result has no vendor lock-in.

At Converge, Android is Kotlin + Jetpack Compose. Native, modern, zero dependencies. Correct.

Examples

app/src/main/java/zone/converge/obligation/ObligationScreen.ktkotlin
@Composable
fun ObligationScreen(
    viewModel: ObligationViewModel = hiltViewModel(),
    onApproved: () -> Unit
) {
    val state by viewModel.state.collectAsStateWithLifecycle()

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(16.dp),
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        // Amount with locale-aware formatting
        Text(
            text = state.formattedAmount,
            style = MaterialTheme.typography.displayLarge
        )

        // Due date with relative formatting
        Text(
            text = "Due ${state.relativeDueDate}",
            style = MaterialTheme.typography.bodyLarge,
            color = MaterialTheme.colorScheme.onSurfaceVariant
        )

        Spacer(modifier = Modifier.weight(1f))

        // Approve with biometric prompt
        Button(
            onClick = { viewModel.approveWithBiometrics(onApproved) },
            enabled = !state.isProcessing
        ) {
            Text("Approve Obligation")
        }
    }
}

Jetpack Compose's declarative model mirrors SwiftUI. collectAsStateWithLifecycle() handles lifecycle-aware state collection. Biometric authentication integrates with Android's BiometricPrompt. This is idiomatic Android code.

Related Articles

Stockholm, Sweden

Version 1.1

Kenneth Pernyér signature