Kotlin Android development
The hard part of Android is not the language. It is the device range, the manufacturer battery rules, and the background work that quietly stops running on somebody's phone. Native Kotlin is how you get control over all three.
01Capabilities
Three jobs on the handset, and one behind it
Kotlin is the default language for Android, so the interesting question is never Kotlin or something else on Android. It is whether you should be native on Android at all, which is decided on iOS and Android. When the answer is yes, it is usually one of the first three below. The fourth is the half nobody asks about.
- Field
Rugged hardware with a vendor SDK
Handheld scanners, label printers and vehicle-mounted terminals, of the kind that run warehouse operations. The vendor's kit for that hardware ships as an Android library, and wrapping it for a cross-platform framework is a maintenance obligation you would own forever.
- Background
Work that has to survive the battery manager
Location tracking on a route, queued uploads, sync that survives a lost signal, the shape of app logistics and transportation teams depend on. Android's background rules tighten with every release and each manufacturer adds its own, so this needs direct control of the platform.
- Range
Consumer apps on old and cheap handsets
Products where your users are on mid-range and three-year-old hardware, not on the newest phone. Memory ceilings, cold start time and long list performance on that hardware are engineering constraints, and they are where cross-platform overhead becomes visible first.
- Server
Kotlin behind the app, not only on it
Kotlin is a first-class language on the JVM, the same runtime Java uses, so the service behind the app can be written in it too. We judge that as a Java ecosystem decision rather than an Android one, because the trade-offs share nothing with the three cards above. The build around it is custom software development.
02Fit
Whether you need a second native codebase at all
Because Kotlin is the standard Android language, this table is not about the language. It is about whether a second native codebase earns its keep. We argue for native Android when the hardware or the background behaviour is central, and against it when the app is largely screens over an API. Five of the six rows below send you somewhere that is not a native Android project with us, and one names no page of ours at all.
| Your situation | What we recommend |
|---|---|
| Rugged hardware with a vendor kit, or background work that must survive the manufacturer's battery manager | Go nativeThis is where "it works on my phone" comes from, and fixing it needs direct access to the platform rather than a wrapper around it. |
| You already run a React and TypeScript team, and the app is conventional screens | Different pageOur React Native page. Shared people and shared rules with your web product are worth more than native purity here. |
| Both platforms, one custom design language, and it has to look identical on each | Different pageOur Flutter page. Its own rendering engine is the right tool when platform convention is not the goal. |
| Somebody has proposed Kotlin Multiplatform so you get one codebase for both platforms | Read that carefullyIt shares business rules well. It does not hand you one shared interface, and the pitch usually implies that it does. |
| An existing Android app in Java that works | No rewriteKotlin and Java call each other file by file, so convert where you are already changing code and leave the rest alone. |
| You want the service behind the app written in Kotlin as well | Different questionJudge it on the Java ecosystem page, as a server decision. Nothing that decides the rows above applies to it. |
Scope
What we own is that decision and the parts of it you live with afterwards. That means the oldest Android version you support and which handsets it drops, what the app is allowed to do while nobody is looking at it, and whether your own team can maintain what we hand over. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries. The work runs under an ISO 27001:2022 certified information-security management system. Where one shared codebase would serve you better than two, you will hear that instead.
03Delivery
What Android punishes you for skipping
The same four omissions cost money on nearly every project here. So we deal with them before feature work, rather than discovering them during testing.
- Fix the device matrix before the designThe oldest Android version you support, the actual handsets your users hold or the rugged units you have already bought, screen sizes and form factors. Android's variance shapes the design, the estimate and the test plan, and guessing at it is how a project acquires a late surprise.
- Get the build and dependency floor currentThe build tooling, the Kotlin version and the Android version the app declares it targets. On an inherited estate this comes first, because Google raises that target requirement each year, and an app that stops being maintained eventually stops being publishable at all.
- Design background work explicitlyWhat runs deferred, what needs to keep a visible notification, and what happens when the system or a manufacturer's battery manager kills the process anyway. This gets written down, because it is the most common source of bugs that only reproduce on a customer's phone.
- Test on real hardware, including the cheap and oldA device set covering low-end and older handsets, plus any rugged units already in the field. Emulators hide memory pressure, heat throttling and manufacturer behaviour, and those are the three things that make an app feel bad in the real world. Every build meets our QA and test automation practice.
04Stack
What sits beside this, on the phone and off it
The five pages the table hands you to, four on the handset and one on the server.
05Questions
What Android teams ask us first
Answered the way we would answer them on a call. If yours is not here, it is a good first message.
Yes, our Android engineers can join your team and work in your process. What does not come with that is us stepping back from the result, because what decides whether an app behaves in the field is architectural rather than hourly. Design review comes from an architect outside the delivery team, under the same QA practice as our own projects. Team extension is managed teams; the outcome is mobile app development.
Kotlin for anything new. It is what the platform, the tooling and the documentation are built around now, and its null safety alone removes a category of crash Android apps used to ship routinely. For an existing Java codebase, none of that justifies a conversion project on its own. The two call each other file by file, so convert what you are already editing and leave the rest.
Compose for a new app, and for new screens in an existing one. It is where the platform is going and it is markedly less code for the same result. The older view system stays reasonable where you have a large working interface layer, or depend on a mature widget with no Compose equivalent. A mixed codebase is a legitimate steady state, as long as the boundary was chosen on purpose.
We would judge it as a server decision, not an Android one. Kotlin runs on the JVM, so it inherits the Java libraries, the hosting and the operational tooling your team may already run, and sharing a language with the app is a real convenience. It is not on its own a reason to move a working service. That conversation belongs on our Java ecosystem page.
A scoping call with an engineer. For an existing app we want the repository, the crash reporting and the Play Console vitals beforehand, because crash and freeze rates broken down by handset find the real problem faster than any description. For a new build we want the device situation and the background requirement. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based and quoted per project, offered once the first read is done. Team extension is billed monthly per engineer. The rate depends on the seniority mix the work needs, so it is quoted rather than listed.
Building for Android, or fixing an Android app that shipped?
Tell us what the app does, which handsets it runs on, and what it has to finish in the background. You will get a straight read on it. That includes the case where one cross-platform codebase would serve you better than two native ones.