Android app development with Kotlin
Built on the handset your customer owns, not the flagship in the demo video.
We build native Android apps in Kotlin with Jetpack Compose. Consumer products, field and logistics tools, and the apps that need real hardware access: barcode scanners, Bluetooth peripherals, background location. Every build is tested on mid-range devices and shipped through the Play Console in staged rollouts, so a bad release reaches one per cent of users rather than all of them.
When is native Android worth the extra cost?
Kotlin is the language Google recommends for Android and Jetpack Compose is how its interfaces get written now: declarative, far less code than XML layouts, and where the platform investment goes. Native is worth paying for in three situations. The app leans on hardware. Performance on cheap devices decides whether people keep it. Or Android simply is your market.
That third case gets missed in product meetings held in San Francisco or Auckland. Across India, Southeast Asia, Africa and much of Latin America, Android holds the overwhelming majority of handsets, and the typical one is a mid-range phone with 4 GB of memory on a patchy network. Native code lets us control memory, background work and download size for that specific device. It is the difference between an app someone keeps and the one they delete when storage runs out.
Fragmentation is the price, and we are not going to pretend otherwise. Dozens of manufacturers, battery-saving behaviour that differs by brand, a long tail of OS versions still in daily use. Our answer is unglamorous: test on real mid-range handsets instead of emulators, put anything that must survive being killed into WorkManager, and set the minimum supported version from your analytics rather than from what is convenient for us.
One thing to budget for. Google raises the required target API level every year, and an app that misses the deadline stops being distributed to new users. That is a maintenance line item, not a project, and it belongs in the retainer alongside cross-platform work and store releases.
What we build for Android
Consumer Android apps
Products for markets where Android is most of the install base, built and profiled on the hardware those users actually hold.
Explore →Field, logistics and retail apps
Barcode and RFID scanning, route and job management, offline capture that syncs through WorkManager when signal returns.
Hardware and peripheral integration
Bluetooth devices, payment terminals, label printers, NFC and USB accessories, wrapped behind an interface the app code can trust.
Enterprise distribution
Managed Play distribution, kiosk and dedicated-device modes, MDM enrolment for staff apps that never touch the public store.
Native modules for cross-platform apps
Kotlin behind a Flutter or React Native app when one feature needs the platform itself.
Play Store compliance and releases
Target API upgrades, data safety declarations, staged rollouts, pre-launch reports and crash triage after each release.
Explore →Our Android stack, by layer
Native Android compared with the alternatives
Kotlin vs Flutter or React Native
For most business apps, cross-platform is the better economics and we say so before anyone signs. One codebase, both stores, roughly two thirds of the cost. Native Android earns its premium when you need tight control of memory and background execution on low-end hardware, deep peripheral work, or a platform feature on the day it ships.
Jetpack Compose vs the older View system
Compose for anything new. Less code, better tooling, and it is where Google's effort goes. What we will not do is rewrite a working View-based app to Compose for its own sake. The two interoperate cleanly, so new screens go in Compose and the old ones stay put until there is a reason to touch them.
Kotlin Multiplatform vs Flutter
Multiplatform shares the business logic and leaves each interface native, which reads well on a slide. In practice the ecosystem is younger and the tooling less settled than Flutter's. We recommend it when there is already an Android team in the building and the shared code is logic rather than screens.
Android development, answered
Should we build native Android or cross-platform?
If it is the same product on both stores with ordinary requirements, cross-platform costs less and we will point you there. Go native when hardware integration, background reliability or performance on cheap devices is the point of the app, or when Android is effectively your entire market.
Which Android versions should we support?
We set the minimum from your own analytics, or from market data for your target countries if the product is new. Supporting very old releases costs real engineering hours in workarounds. You get the trade-off as a number, users reached against days of work, before the decision is made.
How do you deal with Android device fragmentation?
Real mid-range handsets on the desk and Firebase Test Lab in the pipeline, rather than trusting an emulator. Anything that has to survive aggressive battery optimisation goes through WorkManager. Manufacturer-specific background behaviour is a known problem, so we design around it in week one instead of debugging it after launch.
How much does an Android app cost?
A focused native first release usually runs $18,000 to $40,000 for Android alone. Hardware work, scanners, printers, payment terminals, sits on top of that. We quote those items separately so you can see what each one costs and drop the ones that are not worth it.
Do you handle Play Store policy and releases?
Yes. Data safety declarations, permission justifications, target API upgrades, staged rollouts and the replies to policy rejections when they come. Google's annual target API deadline goes into the maintenance plan at the start of the year, not into an email in November.
Can we hire an Android developer from you instead?
Yes. Native iOS and Android engineers are $25/hour or $3,200/month, with a 15-day trial and profiles within 48 hours. You run the sprint; we handle payroll, cover and replacement.
Planning an Android build?
Tell us who uses it, on what handsets, in which country. We will tell you whether native is worth the money for your case, including when it is not.