Android covers everything from a flagship phone to a five year old handset and a scanner in a warehouse. We build for that spread rather than for the emulator on a developer's desk.
Background sync stops overnight on one manufacturer and runs fine on another. Notifications arrive instantly on the test device and forty minutes late on the one the sales team carries. A layout that looks right on a Pixel wraps badly on a cheaper handset with a larger font scale. None of this appears on an emulator. It appears in the field, usually reported by the person least equipped to describe what they saw.
We write Kotlin, use Compose for the interface, coroutines and flows for background work, and keep a single source of truth for state so the screen cannot disagree with the data behind it. Staying close to Google's own architecture guidance is a maintenance decision as much as a technical one, because the next developer to open the project will recognise its shape straight away. We set the minimum supported Android version from your install base rather than from a default, test on the skins that show up in your analytics, and write background work to survive an aggressive battery manager killing the process.
For a public app we run the Play Console: staged rollouts, crash and unresponsive rates watched through the ramp, and data safety declarations kept accurate as the app changes rather than corrected once a year in a hurry. For an internal app we handle managed distribution, device policy and kiosk lockdown, so the tablet on the shop floor does one job and cannot be turned into a browser. Either way the developer account is registered to you, and the signing key is yours.
Android's own rules for background work are documented and reasonable. Several manufacturers then add their own on top, and those are more aggressive, less documented and different from each other. The result is the defect that defines this platform: an app that syncs perfectly overnight on the developer's phone and is silently frozen by morning on the handset your warehouse supervisor carries. It never shows up in testing, because testing happens on the wrong phone. Building around it means using the platform's scheduled work APIs rather than long-running services, treating every background task as something that may be deferred or killed, making sync resumable rather than assuming it completes, and where the job genuinely depends on it, walking the user through the manufacturer's own exemption screen. Assume the system is trying to stop you and the app survives contact with real devices.
An app for your own staff is not a public app with a smaller audience, it is a different piece of work. Distribution is managed rather than searched for. Devices are enrolled, policy-controlled and often locked to a single task, so the tablet by the loading bay cannot become a browser. Updates have to be pushed rather than hoped for, because nobody on a shop floor opens the Play Store to check. And the failure modes are physical: a device that is dropped, flat, out of coverage in the same corner of the same building every day, or shared across three shifts by people who never sign out. Those are design questions, and they get asked before the build rather than raised as tickets afterwards.
Public Play Store apps in Kotlin and Compose, with the minimum supported version set from your install base rather than from a default that quietly drops users.
The app your own people carry, built for the places they work: warehouses, vans, basements, sites. Offline behaviour is the design, not a feature added later.
Locked-down tablets and terminals that do one job, survive being unplugged, and update without anyone visiting them.
Handhelds with hardware triggers and barcode engines, integrated properly rather than emulating a keyboard and hoping the focus is in the right field.
Java to Kotlin, Views to Compose, incrementally and only where it pays. Both interoperate, so working code does not need rewriting to benefit from newer work beside it.
Staged rollouts, crash and unresponsive rates watched on the ramp, data safety declarations kept accurate as the app changes rather than corrected annually in a panic.
Your analytics decide the support floor: which Android versions, which manufacturers, which screen sizes and font scales. Not the emulator, and not the newest phone in the office.
Kotlin, Compose, coroutines and a single source of truth for state, kept close to Google's own guidance so the next developer recognises the shape of the project immediately.
Written assuming the system is hostile to background work: schedulable, resumable, and safe to be killed at any point without losing what the user just did.
Real handsets and manufacturer skins from your own numbers, plus the largest font scales and your longest locale, which is where layouts actually break.
A slice of users first, crash and ANR rates watched before it widens. Internal and closed tracks so your own team sees a release before your customers do.
Late notifications, background sync that stops overnight, layouts that wrap on cheaper handsets. All of it invisible on an emulator and obvious in the field.
Warehouses, basements, vans, remote sites. On Android this is the normal case, and offline-first has to be the design rather than a later addition.
Tablets on a shop floor, scanners in a depot, terminals in a branch. Enrolment, lockdown and pushed updates are the actual product.
Java, Views, an unsupported library, a minimum version chosen years ago by someone who has left. Modernising incrementally beats rewriting from nothing.
That is a decision to make deliberately, from your own numbers rather than a default. Supporting older versions costs engineering time; dropping them costs users. We look at what your customers actually run, set the floor there, and test on the spread that matters to you: cheap handsets, tablets, and where relevant the kiosks and rugged devices your staff carry, which behave nothing like a developer’s phone.
Kotlin is what Google builds Android for now: the documentation, the samples and the newer libraries are written in it first, and the language removes a whole class of null-related crashes by making them a compile error. Existing Java code keeps working alongside it, so an older app does not need rewriting to gain the benefit; new work is simply written in Kotlin.
On Android it usually has to. Staff use these apps in warehouses, basements and vans, and an app that needs a connection is an app they stop trusting. We build offline first where the job calls for it: the work is recorded locally, the sync resolves when coverage returns, and the conflict rules are decided in the design rather than discovered in production.
Through staged rollouts rather than all at once. A release goes to a slice of users first, with the crash reporting watched before it widens, so a bad build reaches a fraction of your users rather than all of them. Internal and closed testing tracks let your own team see a release before customers do.
Because several manufacturers add their own battery management on top of Android's, and it is more aggressive than the platform's own rules. An app that syncs happily overnight on a Pixel can be frozen by morning on a handset from a manufacturer that decided it was idle. This is the single most common Android defect that never appears in testing, because testing happens on the developer's phone. The fixes are known, using the platform's scheduled work APIs rather than long-running services, declaring work correctly, and where it genuinely matters, guiding the user through the manufacturer's own exemption screen, but they have to be chosen deliberately.
Yes, and they are worth naming separately because they are not just bigger phones. A tablet needs layouts that use the width rather than stretching a phone screen across it. A kiosk needs lockdown so the device does one job and cannot be turned into a browser, plus a plan for what happens when someone unplugs it. A rugged handheld usually has a hardware scan trigger and a barcode engine that needs integrating properly rather than emulating a keyboard. Each of those is a design decision, not a screen size.
You do, and on Android the signing key deserves particular attention. Historically, losing it meant you could never update your own app again, which is an outcome businesses have genuinely suffered. Play App Signing removes most of that risk by having Google hold the release key, but the developer account, the upload key and the enrolment still need to sit in your company's name with more than one person able to reach them. We set that up at the start rather than at handover.
Usually, and the assessment is short. We want a clean build from a fresh checkout, the Play Console access, the signing arrangement and whatever the previous team wrote down. Older apps often mix Java and Kotlin, or Views and Compose, and that is fine: both interoperate and there is no requirement to rewrite working code to gain the benefit of the newer approach. What actually decides takeover versus rebuild is whether the app's data and background layers can be reasoned about, not which language they are written in.
We are happy to answer any questions you have and help you work out which of our services fit your needs.
