A native Android app, built in Kotlin and released on Play

What this actually solves

Android is bought for two very different reasons and it is worth knowing which one you are. The first is capability. Android will let an app run in the background for sustained periods, talk directly to hardware, integrate with other apps on the device, and be locked to a specific piece of company equipment — a warehouse barcode scanner, a POS terminal, a driver handset. That is work a browser cannot do and a shared codebase does only partially.

The second reason is simply where your customers are, and that is not a matter of opinion — your own web analytics, order records and support inbox already say which platform people arrive on. If you sell into South Asia, Southeast Asia, Africa or the Middle East, run that check before anyone budgets for two apps. Where the answer comes back Android, building the iPhone half of a project is money spent on an audience that is not there, and a native Android app is the straightforward, undiluted answer.

What makes Android hard is not the language. Kotlin is pleasant, and Jetpack Compose has made screen work considerably faster than it used to be. The difficulty is the fleet. There are thousands of Android handsets in circulation, every manufacturer has changed something, and several of them run aggressive battery managers that will quietly kill your app's background work and stop its notifications arriving. That behaviour does not appear in the emulator, it does not appear in the documentation, and it is the single most common reason a finished Android app embarrasses its owner in the first week.

What we do, and in what order

1. Scoping call and the exclusion list. What the app must do, what it must run on, and an explicit written list of what version one will not include. If specific hardware or a specific device model is involved, that gets nailed down here rather than discovered later. Two to three days.
2. Specification and the Play Console account in your name. A Play Console developer account is a one-off $25, and Google verifies identity and address before the account can publish. If the app targets an organisation account, that verification is started immediately, because it is not instant and it is not in anyone's control. One to two days of our time, then Google's clock.
3. Screen map, data model and the build setup. Every screen named and routed, entities agreed, Gradle configuration and the signing keystore created and backed up in two places on day one. Three to five days.
4. Build, screen by screen, in Compose. Static screens first, then reading, then writing. Background work, permissions and notification behaviour are treated as features with their own testing rather than as details bolted on at the end. Six to sixteen weeks depending on scope.
5. Real-handset testing across manufacturers. Physical devices from several makers, old and new, with battery optimisation left in its default aggressive state rather than switched off to make the results look good. One to two weeks.
6. Store assets and the compliance forms. Icon, screenshots at each required size, short and long descriptions, a live privacy policy URL, the Data safety declaration and the content rating questionnaire. Two days.
7. Internal and closed testing tracks, then production. Builds go to you through Play's own testing tracks so there is a record of which version you saw. Note that the requirements around closed testing before a first production release have changed more than once, so we check the current rule in Play Console at the time rather than quoting one from memory. One to two weeks.
8. Handover. Keystore file and password, Play Console ownership, Firebase access and a written page on how the next release is built and shipped. One day.

Tools, so it is not a black box — Android Studio, Kotlin, Jetpack Compose, Gradle, Play Console, Firebase, and Crashlytics or Sentry for what happens after release.

What moves the price

The range is $7,000–$50,000 across 2–6 months, and it is set by three things rather than by screen count alone.

How deep into the device the app goes. Reading from an API and drawing screens is one tier. Continuous background location, direct hardware or peripheral integration, foreground services, and anything that must keep running when the phone is asleep is another, because each of those has to be made to work across manufacturers that treat them differently.

How far back support has to reach. Supporting current Android is straightforward. Supporting handsets several versions old, which is common in markets where devices are kept for years, adds testing surface and forces compromises in what the app can assume.

Whether it has to run on a particular device. Company-issued hardware — scanners, rugged handhelds, POS units — narrows the target usefully but adds procurement, an often thin manufacturer SDK, and testing that can only be done on the physical unit.

What usually goes wrong

Everything is tested on the emulator. The emulator is Google's own clean Android, with none of the manufacturer modifications that matter. The app runs perfectly there, ships, and then the notifications never arrive on a Xiaomi, or the background sync stops overnight on a Vivo because the battery manager put the app to sleep. This is the classic Android humiliation and the only defence is a drawer of real handsets.

The keystore is treated as a build artefact. It gets left on one machine, or held by whoever built the app, or never handed over. Then the business wants an update from someone else and finds it cannot update its own listing — the only route is a new app with a new URL, zero installs and zero reviews. The keystore and its password belong to you, backed up, from the first release.

Nobody tracks the target API level. Google raises the bar annually. An app that is otherwise working fine hits the deadline, Play stops accepting updates, and a small scheduled task becomes an urgent one that also drags in a pile of dependency upgrades that were deferred at the same time. It is entirely predictable and entirely avoidable.