Why Android needs special care
Android runs on thousands of device models from dozens of manufacturers, with different screen sizes, chipsets and OS versions. An app that looks perfect on one phone can stutter or break on another. Good Android development is as much about testing and performance across devices as it is about writing features.
When to choose native Android
- Your users are mainly on Android, for example in field services, logistics or emerging markets
- The app runs on rugged devices, scanners, kiosks or point-of-sale hardware
- You need deep access to Bluetooth, NFC, background services or device management
- Performance and battery use are critical
Building for both platforms? See Flutter and React Native development.
What we build for Android
Consumer apps
Google Play billing, subscriptions, notifications and deep links.
Enterprise & field apps
Offline-first data, barcode and NFC scanning, managed-device deployment.
Device & IoT apps
Bluetooth Low Energy, hardware integration and kiosk modes.
Tablet & foldable layouts
Adaptive UI for large and folding screens.
Our Android stack
Material Design and Android conventions
Android users expect apps to behave like Android apps: the system back gesture works predictably, notifications are grouped and actionable, and the interface follows Material Design patterns adapted to your brand. We use Material 3 components in Jetpack Compose, support dynamic colour where it suits the brand, and design layouts that adapt to phones, tablets and foldables using window size classes rather than fixed breakpoints.
Performance and battery on real devices
Many Android users run mid-range or older devices with limited memory. An app that feels fine on a flagship can stutter elsewhere. We profile startup time, frame rendering and memory use on representative devices, use baseline profiles to speed up launch, schedule background work with WorkManager so it respects battery-saving modes, and keep the app size small with resource shrinking and app bundles. Google Play’s Android vitals then help us track crash rates and ANRs after release, so issues on specific devices are caught early.
- Startup time measured on low- and mid-range devices
- Background work that respects Doze and battery optimisation
- Offline-first data where connectivity is unreliable
- Android vitals monitored after every release
Enterprise Android and device management
Companies deploying apps to staff devices — delivery drivers, field technicians, warehouse teams — often use Android Enterprise with a mobile device management (MDM) platform. We build apps that support managed configurations, so IT can set server URLs and options remotely, work in kiosk or dedicated-device mode, and distribute privately through managed Google Play. This keeps devices secure and lets IT roll out updates to hundreds of devices at once.
Scoping an Android app
Android scoping has a few questions that iOS projects do not. Which minimum Android version will you support? Which device categories matter — budget phones, tablets, rugged handhelds, foldables? Will the app be distributed through Google Play, a private enterprise channel or both? Do you rely on manufacturer-specific hardware such as barcode scanners or payment terminals?
The answers change both effort and testing. Supporting older Android versions or a long tail of low-memory devices takes more work than targeting recent flagships, and we put that trade-off in front of you with your real user data rather than guessing.
Kotlin, Jetpack Compose or cross-platform?
| Option | Best when | Watch out for |
|---|---|---|
| Kotlin + Jetpack Compose | Android-first products, deep device integration, best performance | Separate codebase for iOS |
| Kotlin + XML views | Extending existing apps built before Compose | Slower UI development for new screens |
| Kotlin Multiplatform | Sharing business logic with iOS while keeping native UIs | Smaller ecosystem; team needs both skill sets |
| Flutter / React Native | One app for both platforms on a tighter budget | Platform-specific features may need native modules |
If you need both platforms, compare with cross-platform development before deciding.
Releasing on Google Play
-
Developer account & signing
Your organisation owns the Play Console account; Play App Signing protects the release key.
-
Store listing & data safety
Screenshots, descriptions and an accurate Data safety form describing what the app collects.
-
Testing tracks
Internal, closed and open testing tracks to collect feedback before a public release.
-
Staged rollout
Release to a percentage of users first and watch crash and ANR rates before expanding.
-
Target API updatesYearly
Google requires apps to target recent Android API levels; we plan these updates ahead of deadlines.
Measuring Android quality
- Crash-free users and ANR rate (“app not responding”) in Android vitals
- Cold start time on mid-range devices, not just flagships
- App size, which affects installs in markets with limited storage or data
- Battery and wake-lock behaviour flagged in Play Console
- Ratings and review themes, read regularly and fed into the backlog
Questions to ask an Android development partner
- Which physical devices will you test on, and how were they chosen?
- How do you handle manufacturer-specific background restrictions?
- Will we own the Play Console account and signing keys?
- How will you keep the app compliant with yearly target API requirements?
- Who handles store review issues and policy changes after launch?
Need engineers inside your team instead? See hire Android developers.
Designing for the Android device range
Android runs on phones with very different screens, memory and processing power, plus tablets, foldables and Chromebooks. Layouts are built to adapt with window size classes rather than fixed dimensions, so the same screens work on a compact phone, an unfolded device and a tablet in landscape.
We also design for system settings users actually change: large font sizes, display scaling, dark theme, gesture navigation and battery saver. Handling these properly avoids the clipped text, broken layouts and failed background tasks that lead to poor reviews on certain devices.
Background work and notifications on Android
Android limits what apps can do in the background to protect battery life, and some manufacturers add stricter rules of their own. Syncing data, uploading photos or tracking location therefore needs the right tools: WorkManager for deferrable tasks, foreground services with a visible notification for ongoing work, and Firebase Cloud Messaging to wake the app when the server has news.
We test these flows on several manufacturers’ devices, because a sync that works perfectly on one phone can be silently delayed on another unless it is built with these rules in mind.
Where a task genuinely cannot wait, we explain the trade-off openly and use the most battery-friendly option available.
Timeline and budget
| App type | Typical timeline | Typical budget (USD) |
|---|---|---|
| Simple app | 6–10 weeks | $20k – $45k |
| App with accounts, payments and backend | 12–18 weeks | $50k – $110k |
| Enterprise or hardware-integrated app | 4–8 months | $100k+ |
Typical ranges to help you plan. Your written estimate comes after a free discovery call.
This page is part of Mobile App Development Services — see the full overview for related services, approach and pricing.