AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms
6–10 wks
Typical Android MVP
One core workflow, Play Store submission included
100%
Senior engineers, US-based
No offshore handoff mid-build
Every sprint
A build you can install on a device
Not a status deck between milestones
100%
Code and Play Console account yours
From the first commit
The platform decision
Native Kotlin, or a cross-platform framework that reaches Android
This page is about the Android-specific case for going native. For the general native-vs-cross-platform question, /mobile covers React Native and Flutter in full — the short version for Android specifically is below.
Kotlin and Jetpack Compose
Google's own modern toolkit for Android UI, with first access to whatever the platform ships — Material 3 theming, widgets, foldable-aware layouts, Android Auto. The cost is a codebase that only targets Android, which is the right trade when the product needs a platform capability rather than a shared interface.
React Native for a shared iOS/Android codebase
One JavaScript codebase reaching both stores, with a native-module bridge for the pieces that need it. Suits teams already React-fluent and products where interface consistency across platforms matters more than squeezing the last frame out of the GPU. See /mobile for the fuller comparison.
Java in an existing codebase
Older Android apps still run substantial Java, and Kotlin interoperates with it in the same project — so the common path is incremental, with new features in Kotlin and legacy Java migrated as it's touched. A full rewrite is rarely the first move worth making.
Tablets, foldables, and large-screen Android
Android's large-screen guidelines cover phones, tablets, foldables, and Chromebooks from one adaptive layout when done with Compose's window-size classes. Skipping this is how an app ships looking like a stretched phone screen on a Samsung Fold or a Chromebook.
None of these decisions reverse cheaply. Discovering mid-project that a React Native app needs a native module for a capability the bridge doesn't expose is a smaller problem than discovering it needs one for every screen — which is why the platform decision belongs before the first sprint.
What's involved
Android engagement types
The variable that moves an Android build's scope isn't screen count — it's how much device and OEM coverage the app needs, and whether background work has to survive aggressive battery-management defaults on non-Pixel hardware.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| Android MVP | Fixed scope | 6 – 10 weeks | One core workflow, Kotlin/Compose, backend integration, and Play Store submission for the first release. |
| Full Android build | Fixed scope | 12 – 18 weeks | Multiple workflows, offline sync, push notifications, and device-fragmentation testing across major OEM skins. |
| React Native to native migration | Fixed scope | 8 – 14 weeks | Rebuilding the Android side natively once a cross-platform build hits a ceiling a bridge layer can't clear. |
| Play Store rescue or policy fix | Fixed scope | 1 – 4 weeks | A rejected or suspended listing diagnosed and fixed against Google's actual policy notice, not guesswork. |
| Large-screen and foldable adaptation | Fixed scope | 3 – 8 weeks | Adaptive layouts for tablets, foldables, and Chromebooks added to an existing phone-only Android app. |
| Ongoing Android maintenance | Ongoing retainer | Ongoing | Yearly OS upgrades, target SDK bumps Google requires, deprecated API replacement, and crash monitoring across device models. |
Ranges assume US-based senior engineers and include QA across a representative device set, not just a flagship phone. A quote well under these bands is usually missing OEM-specific testing or the maintenance year that follows launch — that cost doesn't disappear, it just shows up later as a one-star review from a Samsung user.
Play Store review
Faster than Apple's review, and less forgiving on data
Play Store review often clears in hours rather than days, but it checks certain declarations more literally than Apple does, and it isn't a one-time event — every update goes through the same gate.
Data safety declarations are checked against the build
Google's data safety section asks exactly what the app collects and why, and a mismatch between what's declared and what the app actually does can get a build pulled after launch rather than before it. This is the single most common reason a first-time Android submission gets flagged.
Staged rollouts exist for exactly this reason
A phased rollout to a percentage of users — Google's native equivalent of Apple's TestFlight — catches the crash that only shows up on a specific device or Android version before it reaches everyone. Skipping it to save a few days is the most common cause of a one-star pile-up in week one.
Permission justifications get read, not skimmed
Requesting a permission the app doesn't clearly use — background location without a visible reason, for instance — is a common rejection trigger. Every permission request should map to a feature a reviewer can find in the app.
Target API level requirements are enforced on a schedule
Google requires new and updated apps to target a recent Android API level on a rolling yearly basis. An app that falls behind doesn't just miss new features — it can be blocked from receiving updates in the Play Store entirely.
Device fragmentation
The problem iOS mostly doesn't have
Apple ships a handful of device models a year. Android runs on thousands of device and OS combinations, and the manufacturer's own modifications matter as much as the Android version number.
OEM battery management is the top cause of "it works on my Pixel"
Samsung, Xiaomi, and other manufacturers ship aggressive battery-optimization defaults that can kill background work Android's own APIs promise will run. A sync job tested only on a Pixel can silently fail to fire on a Samsung device with default settings.
Android versions fragment differently than iOS versions do
Because manufacturers control update timelines, users can be on Android versions several releases behind current — unlike iOS, where adoption of the newest version is fast and broad. Supporting a realistic minimum API level, not just the newest one, is a deliberate scoping decision.
Screen sizes and aspect ratios vary more than on iOS
Between phones, foldables, and tablets, Android's screen-size range is wider than Apple's device lineup. Compose's adaptive layout tools handle this well when used from the start; retrofitting adaptive layouts onto a fixed-phone-size design later is a real rebuild.
A device lab beats a bigger emulator fleet
An emulator catches layout bugs; it doesn't catch OEM-specific background restrictions, real GPS drift, or thermal throttling. A short list of real devices — including at least one mid-range, non-Pixel phone — belongs in the test plan.
After launch
Android maintenance is a yearly requirement, not a courtesy
Google enforces target API level requirements on a schedule outside anyone's control, and shipping v1 is roughly half the lifetime cost of an Android app — the maintenance that follows is the other half.
Target SDK enforcement has real consequences
An app that doesn't target a current API level within Google's window can be blocked from accepting new installs or updates. This isn't a recommendation — it's a Play Store policy with an enforcement date.
Play Console ownership matters for the same reason App Store ownership does
The Google Play Console account, like the Apple Developer account, should be registered under your own organization so a change of vendor never blocks a routine update.
Crash and ANR monitoring catches what a device lab can't
Android Vitals in Play Console surfaces crash rates and Application Not Responding (ANR) events across your real install base, including devices you'll never own for testing. Watching it is cheap; ignoring it shows up as a Play Store ranking penalty.
Related
Related services
What Android projects usually connect to.
Questions
Common questions about Android development
What teams ask before a first call.
An Android developer designs and builds applications for the Android platform using Kotlin (or, in older codebases, Java) and the Android SDK, then tests them across the device and OS combinations real users carry — not just a single reference device. That includes wiring up backend integrations, handling offline behavior, and preparing the build for Play Store review.
On a team, an Android developer also owns the device-fragmentation problem specifically: making sure background work, permissions, and layouts hold up on hardware from manufacturers whose defaults differ from stock Android.
It depends on whether the app is a single-workflow MVP, a full build with offline sync and multiple integrations, or an ongoing maintenance engagement after launch. Device and OEM coverage — how many manufacturers' battery-management quirks the app has to survive — moves a quote more than screen count does.
A scoping call produces a real figure faster than any range on a page would, and it's the fastest way to find out which category your project actually falls into.
Native Kotlin and Jetpack Compose when a platform capability — widgets, Android Auto, a large-screen or foldable layout — is central to the product. React Native when the team already knows React and both iOS and Android need to ship from one codebase.
Switching after launch is closer to a second build than a refactor, so this decision belongs before the first sprint. /mobile covers the full comparison, including Flutter.
Play Store review often clears faster — sometimes within hours — but it checks data-safety declarations and permission justifications more literally, and a mismatch between what's declared and what the app collects can get a build pulled after launch rather than before it. Both stores review every update, not just the first submission.
Staged rollouts to a percentage of users are Android's native equivalent of an Apple TestFlight beta, and skipping that step to save a few days is the most common cause of a one-star pile-up in the first week.
Fragmentation is the reality that Android runs across thousands of device and OS combinations, with manufacturers like Samsung and Xiaomi shipping their own modifications — including battery-optimization defaults that can silently kill background work an app assumed would run. It's a bigger factor on Android than on iOS, where Apple controls both the hardware lineup and the OS.
We handle it with a real device lab rather than just emulators, testing background jobs, notifications, and layouts on non-Pixel hardware specifically, not just the cleanest reference device.
Yes — Jetpack Compose's adaptive layout tools make a genuinely different tablet, foldable, or Chromebook experience realistic within one codebase when planned from the start. Retrofitting adaptive layouts onto a design built assuming a single phone screen size later is a much bigger job, so we scope for the target screen classes up front.
Yes. Source code and the Google Play Console account should be registered under your own organization from day one, with us added as a collaborator — not the other way around. That's the only arrangement that doesn't lock you to a vendor to publish your own updates or move to a different team later.
We diagnose against Google's actual policy notice — usually a data-safety mismatch, a permission justification gap, or a target-API-level lapse — and fix the specific issue rather than guessing at general compliance. Most policy flags are resolvable within days once the exact violation is identified, and staying ahead of Google's yearly target-SDK enforcement window prevents most of these before they happen.