Android (Kotlin & Java): native app development

Since Google I/O 2019, Google has officially recommended Kotlin as the preferred language for Android development. Kotlin runs on the Java Virtual Machine just like Java, but is considerably more concise, reduces common sources of errors such as null-pointer exceptions through built-in null safety, and combines seamlessly with existing Java code. New Android projects today are built almost exclusively in Kotlin, and the newest Jetpack libraries as well as the modern UI toolkit Jetpack Compose are designed Kotlin-first. Compose replaces the older, XML-based layout system with a declarative approach where the interface is described directly as a Kotlin function, which noticeably cuts boilerplate and makes changes to screens considerably faster.

Java remains relevant regardless, and for good reason. A substantial part of the existing Android ecosystem, including many long-grown enterprise apps, libraries and internal tools, is written in Java and will stay that way. Google continues to support Java as a fully-fledged language for Android without restriction, and Kotlin and Java files mix without friction inside the same project. In practice this means existing Java codebases do not need to be rewritten from scratch to benefit from new Kotlin features, and new modules can be added directly in Kotlin while established Java code keeps running unchanged. It is this interplay, not a choice between one language or the other, that sits at the core of modern native Android development.

This coexistence is straightforward at the tooling level too: Android Studio, Gradle and the Android toolchain treat Kotlin and Java source files within the same module as equals, so a team can migrate gradually instead of risking a single, all-at-once rewrite. In many established projects this looks concrete in practice: existing activities, fragments and utility classes stay in Java, while new features, new screens, and the interface in particular built with Jetpack Compose, are written directly in Kotlin. For clients that means predictable cost, since working code does not get rewritten purely for the sake of consistency.

This is also why "Kotlin or Java" is, on closer inspection, the wrong question. The more relevant question is: which parts of a project benefit most from Kotlin's more concise syntax and the modern Jetpack libraries, and which parts keep running stably in proven, well-tested Java code without migration risk? That trade-off gets decided module by module, not once for the whole project.

Cross-platform frameworks have closed much of the gap in recent years, but three technical properties still keep native Android development ahead in direct comparison.

None of these three strengths is exclusively native on its own; cross-platform frameworks offer some level of access to hardware and Play services too. The difference is in the consequence: native development does not need to build a bridge to these capabilities first, it is the platform itself from the ground up. Above all, that reduces the risk of running into missing or delayed framework support with new Android versions or edge cases.

Three figures show why native Android development still earns its place alongside established cross-platform frameworks. Treat them as orientation rather than exact, up-to-the-day measurements, since market share and adoption figures shift continuously and vary by methodology and region.

These figures do not mean native development is generally the better choice. They show that Android as a platform offers enough reach to justify a dedicated native app economically, and that Kotlin has established itself as a language without pushing Java out. For the choice between native and cross-platform they are one input alongside the concrete requirements for hardware access, performance and audience, not the sole criterion. Anyone who needs a solid estimate for their own project still needs a short, focused analysis of their own requirements; general market figures can put that analysis in context, but they cannot replace it.

All three approaches earn their place, and the right choice depends on the project rather than a general "winner". React Native and Flutter share most of the code between iOS and Android and often shorten development time and budget as a result. Native Android forgoes this code sharing but gains performance, access depth and closeness to the platform in return.

React Native relies on JavaScript or TypeScript and renders its interface into native UI components through a bridge. That works well for most business apps, but can mean extra custom work for very complex, animation-heavy interfaces or access to rarer native APIs. Flutter takes a different route: it ships its own rendering engine and draws the entire interface itself, independent of each platform's native UI toolkit. That gives a very consistent look across platforms, but it also means a Flutter app never looks quite like a "true" Android app, it looks like a Flutter app running on Android.

Worth mentioning too is Kotlin Multiplatform, a middle ground developed by JetBrains: business logic is written once in Kotlin and reused across Android, iOS and other platforms, while the interface stays native per platform, using Jetpack Compose on Android and SwiftUI on iOS. For projects that want native interfaces but would rather not maintain error-prone business logic twice, this is an interesting in-between option that is technically distinct from React Native and Flutter, since no UI framework is shared, only the Kotlin code itself.

The table below compares the three most widely used approaches across the criteria that most often decide the choice in practice.

Assessment based on the statements made in this chapter.

In practice the decision is rarely dogmatic. Some teams start with React Native or Flutter to test a market quickly, and only move to native Android development once user numbers, performance requirements or hardware needs grow substantially. Others commit to native from the start, because it is already clear at project kickoff that camera features, sensors or deep system integration will sit at the center of the app.

Anyone unsure should not base the decision on a single row in this table, but on the sum of their own requirements: how many platforms genuinely need to be served at once, how deep does the app need to reach into Android-specific functionality, and how long does the app need to be maintained afterward? In practice, these three questions provide a considerably more reliable basis than a general trend comparison.