Android App Languages and Frameworks: Kotlin, Java, Flutter, and React Native
Published:
Last Updated:
Category: Marketing DX
Authors: Shusaku Yosa
For a new Android-only app, start by evaluating Kotlin with Compose. For an existing Java app, compare continued maintenance, incremental Kotlin additions, and migration. Flutter and React Native are candidates for Android/iOS projects, but shared code does not eliminate device integration, signing, testing, or release work.
Compare the right categories
Language | UI or framework | Typical use | Selection condition |
|---|---|---|---|
Kotlin | Compose or Views | New Android apps and additions | Features and maintenance capability |
Java | Existing Views-based UI and libraries | Maintaining existing assets | Dependencies and regression tests |
Dart | Flutter | Sharing UI and logic across platforms | Plugins and OS-specific work |
TypeScript / JavaScript | React Native | Multi-platform apps using React skills | Native APIs and library support |
Android Studio is an IDE; Compose is a UI toolkit; Flutter and React Native are frameworks. Avoid ranking these as though they were interchangeable programming languages. Game engines and C/C++ integrations address particular requirements rather than being default choices for a conventional screen-based app.
Understand Kotlin-first without dismissing Java
Android’s Kotlin-first policy recommends Kotlin for new development while continuing Java support in the platform SDK, Android Studio, AndroidX, and other areas. This is a reason to consider Kotlin’s tooling and ecosystem, not evidence that Java is unusable or that every beginner will find Kotlin effortless.
Compose is the recommended modern native UI toolkit built around Kotlin, with interoperability for existing Views. Kotlin/Java interoperability does not mean every feature or behavior is identical. In particular, Compose is not something you write equivalently in Java alone.
Use the Kotlin-Java interoperability guide to check nullability, calling conventions, exposed APIs, builds, and tests at the boundary. An incremental feature can reveal these issues before a full rewrite is considered.
Choose by the work you already have
Situation | Starting option | What may change the choice | Avoid assuming |
|---|---|---|---|
New Android-only app | Kotlin with Compose prototype | Libraries or device requirements | Shorter syntax guarantees speed |
Existing Java app | Maintain or add a Kotlin feature | Tests, build setup, team skills | Maintenance must be Java-only or a rewrite |
Shared UI across OSs | Compare Flutter and React Native | Native APIs and interface requirements | Shared code removes OS-specific work |
Team with web React skills | Prototype React Native on devices | Native UI, builds, dependencies | Web screens transfer unchanged |
In a fictional maintenance case, a Java/Views app needs a settings screen. Add and test that screen in Kotlin first if appropriate. Check navigation, null values, persistence, and older supported devices. Expand only when the team can support the mixed project; migration itself need not be the initial business objective.
Account for platform-specific development
Flutter can share Dart UI and application logic, but its iOS setup guide still requires Xcode-based preparation on macOS and testing on iOS devices. A plugin’s existence does not establish that every required permission or hardware feature works on the intended devices.
New React Native projects use TypeScript by default and also support JavaScript. React experience helps, while native components, build processes, notifications, and camera integration remain separate learning and testing tasks. Do not promise a fixed performance advantage or code-sharing percentage.
Run a small proof of capability
For a fictional barcode-recording app requiring a camera, offline storage, and notifications, test those capabilities on both target operating systems before building every screen. Record the evidence and the remaining native work.
Requirement | Test | Example acceptance condition |
|---|---|---|
Camera | Allow, refuse, scan | Refusal has an explanation and recovery path |
Offline records | Save, close, restart | Records persist without synchronization |
Notifications | Permission, resume, open destination | Required action works on target OSs |
Maintenance | Dependency update, build, release | Another maintainer can reproduce the process |
For a retail or service app, start with the customer task: membership identification, collection, or access without an account. The industry-specific OMO experience examples help frame those requirements, including whether another app is needed at all. Once the technology is chosen, follow the independent Android development workflow for costs, testing, distribution, and maintenance preparation.
