Android Apps in Kotlin That Behave on Real Phones
Native Android development for US startups and small businesses — Jetpack Compose interfaces, a device matrix agreed up front, and Play Console releases rolled out gradually rather than all at once.
Kotlin and Jetpack Compose
The stack Google itself recommends, which matters more on Android than it sounds: it is what the documentation, the samples and any engineer you hire will assume.
Kotlin throughout
Null safety removes an entire category of crash that used to dominate Android bug reports, and coroutines make background work readable instead of a nest of callbacks. No Java left behind unless we are taking over a codebase that already has it.
Compose for the interface
Screens described in code rather than XML layouts, which means far less boilerplate, easier theming, and previews while building. Adaptive layouts for phones, tablets and foldables come from the same code instead of parallel layout files.
Jetpack libraries, not inventions
Room for local storage, WorkManager for deferrable background jobs, DataStore for preferences, Navigation, Hilt for dependency injection. Standard, well documented, and still maintained long after we hand the project over.
Material Design, Used Properly
Material is not a skin you apply at the end. It is a set of conventions Android users already know: where navigation lives, how a bottom sheet behaves, what a long press does, how the system back gesture should work. Follow them and your app feels native. Ignore them and it reads as an iOS layout that arrived on the wrong device.
- Material 3 components and type scale, themed to your brand rather than fought against
- Predictive back and edge-to-edge layouts handled, including gesture insets
- Dark theme as a first-class mode, and optional dynamic colour on devices that support it
- Font scaling and display size honoured, because a great many people change them
- TalkBack labels and touch targets checked as part of testing, not after a complaint
Play Console and Staged Rollouts
The single best thing about releasing on Android is that you do not have to release to everyone at once. A staged rollout puts the new version in front of a small slice of users, lets you watch the crash-free rate, and lets you halt it if something is wrong — while most of your users are still safely on the previous build.
Internal testing
Your team and ours, builds available within minutes
Closed testing
An invited group, and a requirement before production access on new personal accounts
Open testing or pre-launch report
Wider beta, plus Google automated runs on real devices in their lab
Production, staged
A small percentage first, increased as the numbers hold, halted if they do not
Release notes, country availability, pricing and the rollout percentage are all controlled per release. We run this for you under your Play Console account.
Many Manufacturers, One App
The Android problem is not screen sizes. It is that different manufacturers change how the system behaves underneath you.
Two phones running the same Android version can treat the same code differently. Manufacturer battery managers kill background work that stock Android would allow. Notification behaviour varies. Camera hardware abstraction layers differ enough that photo capture succeeds on one device and returns a rotated or empty image on another. Low-end handsets with slow storage expose performance problems a flagship hides completely.
You cannot test everything, so the honest approach is to be explicit about what you will test, put it in the scope document, and make sure the list is representative rather than convenient. That is what the matrix beside this is for.
On top of the named devices we use Google automated pre-launch reports, which install each release on a set of real devices in their lab and hand back crashes, screenshots and accessibility warnings before any user sees the build. It is free, it runs on every upload, and it is routinely ignored.
| Slot | What it represents | What it catches |
|---|---|---|
| Low-end handset | Budget chipset, slow storage, small RAM | Jank, slow startup, out-of-memory crashes |
| Current flagship | The device your stakeholders own | Newest OS behaviour, edge-to-edge layout |
| Oldest supported OS | Your minimum SDK level | Missing APIs, permission model differences |
| Aggressive battery vendor | A manufacturer skin known for killing background work | Dropped notifications, stalled sync |
| Large screen | Tablet or foldable, if in scope | Stretched layouts, broken multi-pane views |
| Cloud device farm | The long tail you do not own | Manufacturer-specific crashes |
Illustrative matrix showing the shape of what we agree during scoping — your real list depends on who your users are and what your analytics say they carry.
Battery Restrictions, and Doing Background Work Anyway
Most “the app stopped syncing” reports are not bugs. They are Android working exactly as designed.
Doze and standby buckets
Once a device is idle, network access and alarms are batched into occasional windows, and apps the user rarely opens are restricted harder than apps they use daily. Code that assumes a timer fires every fifteen minutes forever will quietly stop working.
WorkManager for deferrable jobs
Uploads, sync, cleanup and retries expressed as work with constraints — run when charging, run on unmetered network, retry with backoff. The system decides exactly when, survives reboots, and does not drain the battery.
Foreground services, declared honestly
Work the user has asked for right now — a run being tracked, a file uploading, audio playing — runs in a foreground service with a visible notification and a declared service type. Using one to dodge background limits is a policy violation, not a clever trick.
Push instead of polling
Let the server tell the app something changed rather than having the app ask every few minutes. Cheaper on battery, cheaper on your infrastructure, and far more reliable under Doze.
Runtime permissions, asked in context
Notifications, location, camera and nearby devices are all runtime prompts now, and background location gets a separate, stricter request plus a Play review of why you need it. Asking at the moment the feature is used rather than on first launch makes an enormous difference to acceptance rates.
Measured, not assumed
Android vitals in Play Console reports excessive wakeups, stuck partial wake locks, slow startup and crash rates on real user devices. It is the closest thing to an objective grade for how well an app behaves, and Play uses it in ranking.
Play Store Requirements You Cannot Skip
Less about review queues than about deadlines. Android policy obligations continue for as long as the app is listed.
The Data Safety form
A declaration of what data you collect and share, whether it is encrypted in transit, and whether users can request deletion. It has to match the behaviour of your code and every SDK inside it, so we complete it from the dependency list and hand it to you to approve.
Target API level deadlines
Play requires apps to target a recent Android version and enforces it on a schedule. Miss it and you eventually cannot ship updates, and older listings can stop being discoverable to newer devices. This is the main reason an app cannot simply be left alone for two years.
Account deletion
If people can create an account in your app, Play requires a way to delete it from inside the app and a web page that does the same for people who have uninstalled. It is a backend endpoint and a confirmation flow, and it is frequently missed.
Sensitive permissions need a case
Background location, SMS and call log access, all-files access and similar permissions require a declaration form explaining the user-facing feature that justifies them, sometimes with a demo video. If the feature does not clearly need it, plan on removing the permission rather than arguing.
AAB, not APK, for the store
New apps upload an Android App Bundle. Play then builds a device-specific APK containing only the densities, languages and processor architecture that device needs, which meaningfully reduces download size. Signing keys live in Play App Signing under your account, not on a laptop.
New developer account testing rules
Personal Play developer accounts must run a closed test with a minimum number of testers for a set period before applying for production access. It is a real schedule item. We start it early so it runs alongside the build instead of blocking launch.
When Native Android Is the Wrong Choice
Look at cross-platform instead if
- You need iOS at launch too and the budget is fixed
- The app is mostly screens, lists, forms, payments and notifications
- One small team has to maintain both apps afterwards
- Speed to first real user matters more than squeezing the last frame of performance
Native Android is the right call if
- Android is where your users actually are, and iOS can follow
- The app needs serious background work, Bluetooth, camera pipelines or offline storage
- It ships on managed or kiosk devices, or anywhere outside the Play Store
- You want new platform features the season they arrive
Where People Go From Here
iOS App Development
Swift, SwiftUI, TestFlight and the App Store review rules that catch people out.
Learn moreMVP Development
Scoping a first Android release down to something that ships in 8 to 16 weeks.
Learn moreMaintenance & Support
Target API deadlines, OS releases and policy changes handled on a monthly retainer.
Learn moreAndroid Questions We Get Asked
Why is Android testing harder than iOS testing?
Because you are not testing one product line. Android runs on handsets from many manufacturers, across a wide range of screen sizes, chipsets and OS versions, and several of those manufacturers add their own layer on top that changes how background work, notifications and battery optimisation behave. We handle it with an agreed device matrix rather than an open-ended promise: a low-end handset, a current flagship, the oldest OS version you support, the newest one, and a tablet or foldable if either is in scope.
What is the difference between an APK and an AAB?
An APK is the installable package that ends up on a phone. An AAB, or Android App Bundle, is what you upload to Google Play instead: it contains everything for every device, and Play generates a smaller APK tailored to each one, so a user only downloads the screen densities, languages and processor code their device actually needs. Play requires AAB for new apps. APKs are still used for direct installs, internal distribution and enterprise deployment outside the store.
How long does Google Play review take?
Often a few days, and longer for a brand-new developer account or an app that requests sensitive permissions. Google also requires new personal developer accounts to run a closed test with a minimum number of testers over a fixed period before they can apply for production access, which is a schedule item rather than a formality. We build that into the plan at kickoff so it never becomes a surprise two weeks before launch.
Which Android versions should my app support?
There are two separate numbers and people mix them up. Target API level is what your app is built against, and Google Play enforces a deadline requiring it to stay close to the current Android release, so ignoring it can eventually stop you shipping updates. Minimum SDK is the oldest version that can install your app, and that is your commercial decision: lower reaches more devices but costs compatibility work. We usually recommend covering the large majority of active devices rather than chasing the last few percent.
Why does my app stop doing things in the background?
Because Android is deliberately protecting battery life. Doze mode, app standby buckets and manufacturer-specific battery managers all restrict what an app can do once the screen is off, and some vendors are far more aggressive than stock Android. The fix is to use the right tool: WorkManager for deferrable jobs, a properly typed foreground service with a visible notification for work the user has asked for right now, and push messages to wake the app rather than polling on a timer.
What is the Data Safety form and who fills it in?
It is the declaration in Play Console describing what data your app collects and shares, whether it is encrypted in transit, and whether users can request deletion. It must match what the code and every third-party SDK actually do, so we complete it from the dependency list and the code rather than from a marketing description, and you approve it. Play also requires apps with accounts to offer account deletion from inside the app and through a web link.
Get an Android Build Scoped Properly
Tell us what the app needs to do and who carries the phones. You get a written scope, a device matrix and a budget range back within two business days.