Technologies / Java
Java app development for Android apps and mobile backends
Java app development today means two different jobs, and it helps to separate them. On Android, Java is the language most older apps were written in, and plenty of those apps still earn money every day. On the server, Java (usually with Spring Boot) runs the APIs and integrations behind mobile apps at many larger companies. If you have Java code to keep, extend or replace, the sections below set out what we would do with it.
Our position is simple: for new Android work we prefer Kotlin, and we say so. Java stays where it is doing a good job. Java is one of the languages in our mobile app development technologies overview; this page goes one level deeper on the Java decision.
- Kotlin for new Android code
- Gradual migration, no big-bang rewrite
- Play target API deadlines planned in
- Code in your own repository
Java on Android: the history that explains your codebase
Java was the language of Android from the first SDK, so most older Android apps are Java on XML layouts, Activities and Fragments.
The direction changed at Google I/O on 7 May 2019, when Google said Android development would become increasingly Kotlin-first. Since then new Jetpack libraries, samples and documentation have been written with Kotlin in mind. Jetpack Compose, which Google calls Android’s recommended modern UI toolkit, is built around Kotlin, and Google now describes Android as Compose-first.
What Google did not do is drop Java. Its Kotlin FAQ answers the Java-or-Kotlin question with “You don’t have to pick! You can use both.” Kotlin interoperates with Java, so the two can call each other in the same project and a team can add Kotlin to existing Java code bit by bit. That single fact is what makes a low-risk migration possible.
When Java app development still makes sense, and when it does not
We keep writing Java in three situations. The first is a stable Java Android app that needs fixes and small features, not a new architecture. The second is a backend already running on Java, where your team, monitoring and deployment pipeline are built around the JVM. The third is a library or SDK whose consumers are still Java-only: we keep its public API Java-friendly, even if the code behind it moves to Kotlin, so their builds do not break.
We do not start new Android apps in Java: it works against the platform’s Kotlin-first direction, cannot use Compose without adding Kotlin anyway, and narrows your hiring pool. If you are planning a new app, our Kotlin app development page explains the default we recommend instead.
Keep Java when
- The Java Android app is stable and mostly needs fixes
- Your backend and platform team already run on the JVM
- You must integrate with Java-based enterprise systems
- A library has Java-only consumers
- There is no budget or reason to touch working code
Kotlin preferred: migrating Java Android code without a rewrite
Most Java Android apps we see do not need a rewrite. They need a plan that lets new work happen in Kotlin while the old code keeps shipping. This is the approach we use in our Android app upgrade services.
1. Audit before touching code
We check the target API level, Gradle versions, deprecated libraries, test coverage and the Play Console crash rate. Older Java apps are often several API levels behind Google Play’s target requirement, so the audit usually turns up compliance work before any feature work.
2. New code in Kotlin, old code converted when touched
New features and screens are written in Kotlin. A Java class is converted only when it is being changed anyway, which spreads the cost across feature work and keeps pull requests small. Android Studio’s converter gives a first draft; a developer then cleans up the nullable types it leaves behind.
3. Views to Compose, screen by screen
XML layouts and Compose can live in the same app and even on the same screen. We move frequently changed screens first. Our Jetpack Compose vs XML views comparison covers when a Views screen is fine to leave alone.
4. Fix the large-screen and billing traps
Apps targeting API 36 must work on tablets and foldables even if they were portrait-locked, and updates need Play Billing Library v8 or later. Our OS update compatibility support page covers both; they belong in the first sprint.
What we build and maintain with Java
Mostly keeping valuable systems healthy while the next layer moves to a current stack.
Java Android app maintenance
Fixes, target API upgrades and crash reduction for Java apps on Google Play, delivered through our app maintenance services.
Java to Kotlin and Compose migration
A staged plan that moves the codebase to Kotlin and the UI to Compose without freezing feature work. See our Jetpack Compose development page for the UI side.
Spring Boot APIs for mobile apps
Mobile-facing REST endpoints, token-based auth, push triggers and admin APIs on an existing Java platform, following our API development practices.
Enterprise system integration
Connecting mobile apps to Java-based ERP, CRM, insurance and banking systems through a thin, well-tested API layer. Read more about enterprise app integration.
Inherited a Java Android app?
Tell us about the app or share read access to the repository. Within one business day you get our view on what to keep in Java, what to move to Kotlin and what must change before the next Play deadline.
Java compared with the alternatives
Where Java fits next to the other options for Android and backend work.
| Use case | Java | Kotlin | Other options |
|---|---|---|---|
| New Android app | Not recommended | Our default | Flutter or React Native if iOS launches at the same time |
| Existing Java Android app | Keep and maintain | New code and classes being changed | Rewrite only if the code blocks required upgrades |
| Android UI | XML Views | Jetpack Compose | Views and Compose mixed during migration |
| Backend API | Spring Boot; strong for enterprise integration | Spring or Ktor with Kotlin | Node.js or Laravel for smaller teams |
| Hiring | Large pool for backend; shrinking for Android | Main pool for modern Android | Depends on the stack |
Java behind the app: backends, hiring and maintenance
On the server, Java is a sensible choice when you already run it. Spring Boot gives a mature structure for REST APIs, security and scheduled jobs, and many enterprise systems are simplest to call from the JVM. With a Java platform team, we add a mobile-facing Spring Boot layer rather than a second backend language.
For a startup with no backend yet, Java is rarely our first pick. A Node.js or Laravel API, or a managed backend, usually reaches launch with less code and fewer people. Our mobile app backend development service explains how we choose.
Hiring and upkeep
Java developers are easy to find for backend work. Android developers who want to write Java are getting scarcer, because most have moved to Kotlin. In practice, the people you hire as Android developers or Kotlin developers read and fix Java comfortably, but expect them to push for Kotlin in new code. Budget for a target API upgrade every year either way: Google Play’s deadlines fall on 31 August, whatever language the app uses.
Code-quality practices on our Java and mixed Java/Kotlin projects
What you can check in your own repository.
- Nullability annotations on Java code that Kotlin calls, so Kotlin sees real types instead of guesses
- Android Lint and a static analyser such as SpotBugs or Error Prone in CI, with warnings tracked
- Unit tests written around a Java class before it is refactored or converted
- Target API, Gradle and dependency versions reviewed every quarter
- R8 shrinking with tested keep rules for reflection-heavy Java libraries
- Crashlytics or Sentry with mapping files uploaded by CI
- For Spring Boot: a supported Java LTS runtime, dependency vulnerability scanning and API contract tests
Java app development: frequently asked questions
Is Java still used for Android apps?
Yes. Google still supports Java on Android, and its Kotlin FAQ says you can use both languages in one app. Many apps on Google Play are mostly Java and keep shipping updates. What has changed is the direction: Android has been Kotlin-first since 2019 and is now Compose-first, so new libraries, samples and UI tooling assume Kotlin.
Should we rewrite our Java Android app in Kotlin?
Usually not in one go. Kotlin and Java work in the same project, so we write new features in Kotlin and convert Java classes when they are changed for other reasons. A full rewrite only makes sense if the code blocks a required upgrade or nobody can change it safely, and even then we work module by module with tests in place first.
How long does a Java to Kotlin migration take?
It depends on code size, test coverage and how much of the app is changing anyway. Because conversion happens alongside feature work, many teams never schedule it as a separate project. After an audit we give a written plan covering what to convert first, what to leave in Java, and a typical effort estimate in hours, clearly labelled as an estimate.
Can a Java app meet the 2026 Google Play requirements?
Yes. Target API and billing rules apply to the app, not the language. From 31 August 2026 new apps and updates must target API 36 and use Play Billing Library v8 or later. Java apps can meet both, but older ones often need library upgrades and large-screen layout fixes first, so start well before the deadline.
Do you build Java backends for mobile apps?
Yes, mainly with Spring Boot, when the client already runs Java services or must integrate with Java-based enterprise systems. For new products with no existing backend we usually recommend Node.js, Laravel or a managed backend, because they reach launch with less code. We explain the choice in writing after discovery, which runs for one to two weeks.
Can Kotlin developers maintain our Java code?
Yes. Android developers who work in Kotlin almost always know Java, because much of the platform’s history and many libraries are written in it. They will maintain Java code without trouble. Expect them to recommend Kotlin for new files, which we agree with, and to add nullability annotations so the two languages work safely together.
Keep what works, modernise the rest
Book a 30-minute scoping call. We will look at your Java app or backend and tell you what to keep, what to migrate and what the next Google Play deadline means for your release plan.