We build Android apps in Kotlin and Jetpack Compose, and we rescue older Java and XML codebases that struggle with new Android releases and Play Store policy. This page covers when Android should lead, what the stack looks like, and how we deal with the part of Android that iOS teams rarely face: hundreds of device and OS combinations. The broader platform choice sits on the mobile development page.
When should Android come first?
Lead with Android when your users are there: markets across Latin America, South and Southeast Asia, Africa and parts of Europe, field workforces with company-issued devices, and products tied to Android hardware. Lead with native Kotlin rather than a cross-platform layer when:
- The app needs deep system integration, such as background services, foreground location, accessibility services, custom keyboards or widgets.
- It talks to hardware over Bluetooth Low Energy, USB or NFC and must stay connected in the background.
- You target devices outside phones: tablets, foldables, Wear OS or kiosks.
- Performance on low-end hardware is a hard requirement.
For apps made mostly of lists, forms, maps and payments, one codebase for both stores is usually cheaper. Our React Native vs Flutter comparison covers that route.
Which technologies do we use on Android?
| Layer | Our default | Notes |
|---|---|---|
| Language | Kotlin | Java only in inherited code |
| UI | Jetpack Compose with Material 3 | Google’s recommended toolkit for native Android UI |
| Async | Kotlin coroutines and Flow | Replaces RxJava in new code |
| Architecture | ViewModel, repositories, unidirectional state | Keeps screens testable |
| Dependency injection | Hilt | Koin on small projects |
| Data | Room, Retrofit or Ktor | Chosen by offline needs |
| Build | Gradle with version catalogs | Modularized when the app grows |
| Quality | JUnit, Compose UI tests, Espresso for legacy screens | Run in CI on emulators and device farms |
Compose lets teams adopt it screen by screen next to existing View-based screens, which is how we modernize older apps without a freeze: new screens in Compose, old ones migrated as they are touched. Material 3 provides the theming and dynamic color, and adaptive layouts support tablets and foldables.
How do we handle device fragmentation?
Android runs on devices from many manufacturers, with different screen sizes, memory, vendor skins and battery rules. Some vendors kill background work aggressively, which breaks naive sync and notification code. We handle this in three ways:
- A device matrix from your data. Analytics or market data picks the models we test on, always including a low-memory phone and a recent flagship.
- Background work through WorkManager, with foreground services only where the user expects ongoing activity.
- Pre-launch reports and device farms to catch crashes on hardware we do not hold in the office.
Android also changes behavior with each major version: notification permission, exact alarms, photo access, predictive back. We read the behavior-change notes for each target API level before upgrading and schedule that work early.
What do we need to know about Google Play?
Google Play requires new apps to target a recent API level, and the required level moves each year, so an app that is not updated will eventually be blocked from updates. Apps also need a data safety declaration, a privacy policy and correct permission use. For personal developer accounts created after November 13, 2023, Google requires a closed test with at least 12 testers opted in for 14 consecutive days before production access. Organization accounts follow different rules, and we check which applies to you before planning the launch date.
Releases go through internal testing, then closed testing, then a staged production rollout, with crash and ANR rates watched in Play Console before the percentage grows. Builds are Android App Bundles, signed through Play App Signing.
What drives the cost of an Android app?
- Range of devices and OS versions you promise to support.
- Background and hardware features, which need the most device-level testing.
- Backend and integrations, the same as on any platform.
- Design adaptation for tablets and foldables.
- Yearly upkeep: target API deadlines, library updates and Android release changes.
We scope after a call and write the assumptions into the estimate. The cost guide shows ranges by app type, and a mobile app designer can join if screens are not ready.
What is our Android track record?
We have not published a Kotlin-only case. Our shipped mobile cases are React Native: a travel startup app that averaged 1.8s cold start on a mid-range Android phone, and a fitness app whose cold start fell to 1.4s from 3.8s after lazy-loading and a smaller JavaScript bundle. Read the travel MVP and the fitness app cases.
How can you add Android engineers?
Hire mobile developers with Kotlin and Compose experience, or bring in a dedicated mobile team. Rates run $50 to $150 per hour depending on seniority and role.
