Marcus runs a courier business out of Birmingham. Thirty-two drivers, three depot managers, and a dispatch system that had been running on spreadsheets and WhatsApp groups for longer than he was comfortable admitting. He needed an app, specifically one that worked on the cheap Android handsets he’d been issuing to drivers because buying thirty-two iPhones wasn’t happening. He started talking to agencies and quickly ran into a problem: most of the mobile development portfolio work he was seeing was consumer-facing iOS apps, beautifully designed, clearly expensive, and nothing like what a fleet dispatch tool for delivery drivers needed to be. He eventually found the right team by getting specific about what Android-first actually meant for his use case. The experience left him with strong opinions about what to ask an Android App Development Company before signing anything, and this guide covers the territory he had to learn the hard way.
What Android-First Development Actually Means
Building for Android first is a different technical and strategic posture than building cross-platform and treating Android as the secondary target. An Android-first team works natively in Kotlin, the language Google recommends for all new Android development, and builds against Android’s native SDK rather than abstracting over it with a cross-platform layer. They use Android Studio as their development environment, Gradle for build management, and the Jetpack library suite for architecture, navigation, local storage, background processing, and UI.
This matters because native Android development gives full access to Android-specific capabilities that cross-platform frameworks either don’t support or support partially: WorkManager for reliable background task scheduling, Room for structured local database access with complex query support, Android’s foreground service model for features that need to keep running when the app isn’t in the foreground (like live location sharing from a delivery driver’s phone), and the full Android notification system including notification channels, bubbles, and heads-up notifications.
For Marcus’s dispatch app, the ability to reliably run location tracking in the background, even on budget Android handsets that aggressively kill background processes to preserve battery, was a technical requirement that only a team with real Android background processing experience could address confidently. Cross-platform frameworks handle this inconsistently across Android device manufacturers, which is a known limitation that matters a lot in a fleet tracking context.
The Device Fragmentation Reality
Android runs on thousands of device models from dozens of manufacturers, each running slightly different versions of Android with different manufacturer customizations, different battery management policies, and different hardware capabilities. A Samsung Galaxy A-series budget phone, a Xiaomi Redmi, a Google Pixel, and an older Motorola device can all run the same version of Android and still behave meaningfully differently for background processing, camera access, notification delivery, and performance.
A strong Android development agency has QA processes that account for this. They test on a representative spread of actual devices, not just emulators, and they know which device families have which quirks. Xiaomi and Huawei devices, for example, have particularly aggressive battery optimization that kills background processes in ways that Google’s own Pixel devices don’t. An agency that has shipped apps requiring reliable background processing on Chinese Android handsets has already solved problems that an agency primarily testing on Pixels hasn’t encountered yet.
Ask directly how a prospective team handles device fragmentation in QA. The specificity of their answer tells you whether they’ve actually dealt with this in production.
Jetpack Compose and Modern Android UI
Jetpack Compose is Google’s modern declarative UI framework for Android, announced in 2019 and now stable and recommended for new Android development. It replaces the older XML-based layout system with a component model that’s conceptually similar to React on web and SwiftUI on iOS, and it’s where the Android UI ecosystem is firmly headed.
An agency still building new projects primarily in XML layouts rather than Compose is either working on legacy codebase maintenance or hasn’t kept pace with where Android development has moved. For new projects in 2026, Compose is the right choice for UI development, and an agency that can speak fluently about Compose’s state management model, side effects handling, and theming system with Material Design 3 is demonstrating genuine current Android expertise.
Google Play Services and Ecosystem Integration
Android’s ecosystem advantage over iOS is its integration depth with Google’s service layer. Google Maps SDK, Google Pay, Firebase for authentication, real-time database, cloud messaging, and analytics, ML Kit for on-device machine learning, Google Wallet, and the full suite of Google Play Services APIs are all natively available and deeply integrated.
For Marcus’s dispatch app, Google Maps SDK was foundational: route display, live driver location overlays, geofencing for depot arrival and departure detection, and turn-by-turn navigation handoff. A team that has actually shipped apps using Google Maps SDK in production, including handling the quota and billing implications of heavy map usage, knows things about real-world implementation that a team with shallow Maps experience doesn’t.
Google Play’s testing infrastructure is also more accessible than Apple’s equivalent: Firebase Test Lab provides automated testing across real physical devices, pre-launch reports from Google Play run automated tests before an app goes live, and the internal testing and closed testing tracks make staged rollouts straightforward to manage.
What Development Actually Costs
Android App Development Cost follows the same regional and complexity structure as iOS, with some nuances worth understanding. A simple utility app runs $12,000 to $35,000 with a Western agency, less with Eastern European teams ($30,000 to $90,000 for a standard business app) or South Asian teams ($18,000 to $60,000 for comparable scope). A complex app with native Android features, background processing, hardware integrations, and significant backend infrastructure runs $120,000 and up.
Where Android sometimes costs less than iOS is in QA complexity when the device spread being tested is controlled, as in Marcus’s case where all thirty-two devices were the same model. When the target audience uses a wide range of consumer devices, Android QA typically costs more than iOS QA because the test matrix is larger.
The Google Play Developer account is a one-time $25 fee versus Apple’s $99 annual subscription. Ongoing maintenance runs similarly to iOS, approximately 15 to 20 percent of the original build cost per year for a production app, covering OS compatibility updates, security patches, and the ongoing work of keeping the app functional as the Android ecosystem evolves.
What Marcus’s Project Looked Like
His dispatch app launched eleven weeks after the contract was signed. The background location tracking worked reliably across all thirty-two handsets because the agency’s Android specialist had specifically addressed battery optimization behavior for that device model during development rather than discovering it during rollout. Depot arrival detection via geofencing worked accurately enough that Marcus was able to automate the job completion logging that previously required a phone call.
The thing he said mattered most in agency selection: he’d asked each prospective team to describe a background location tracking problem they’d solved on Android and how they’d solved it. Two agencies gave him vague answers about background services. One gave him a specific answer about WorkManager, foreground services, and how different manufacturers’ battery optimization required different handling approaches. He hired the third.
The question was simple. The answer revealed everything that actually mattered about whether the team had done this work in production or just read about it.