Android, where the device you tested on is not the device they own
Android development builds apps for the Android ecosystem. The defining constraint is variety: thousands of device models, several supported OS versions, screen sizes from small budget handsets to tablets, and users on networks ranging from fibre to intermittent mobile data.
The gap between Android and iOS development is not language or tooling. It is that Android runs on an enormous range of hardware at every price point, and an app that performs well on a recent flagship can be unusable on the device a large share of your users actually carry, which in India, in particular, is usually a mid-range or budget handset.
Apps get built and tested on the developer's phone, which is at the top of the market. Memory pressure that never appears on a device with 12GB of RAM causes the app to be killed in the background on one with 4GB. Images sized for a flagship screen consume data users are paying for by the megabyte. Permissions are requested on launch rather than when needed, so people decline them. And Play Store policy requirements, data safety declarations, target API levels, get treated as paperwork until a submission is rejected.
When this work makes sense
Questions worth asking any supplier
What devices do your users actually have? Analytics will tell you, and the answer is rarely flagships.
Which Android versions must be supported? Reaching further back costs compatibility work.
Would a progressive web app serve this? It installs without the store and stays indexable.
How much data does the app consume? For users on metered connections this is a retention issue.
Who handles Play Store policy compliance, including data safety declarations and API level requirements?
Deliverables
The app, native in Kotlin or cross-platform, chosen against your requirements
Testing across a device matrix representing your actual user base, not just flagships
Performance work targeting mid-range hardware and constrained memory
Data efficiency, image sizing, caching, and behaviour on slow connections
Offline handling appropriate to how the app is used
Permissions requested in context rather than on launch
Play Store listing, data safety declaration and policy compliance
Crash reporting and analytics segmented by device class
Built with
Process
The device matrix is agreed before development, from your own analytics rather than from market share statistics. Building and testing against the devices your users hold changes real decisions, memory budgets, image sizes, how much work happens on the main thread. Teams that test only on recent flagships ship apps that reviewers on budget hardware describe as slow, and the reviews arrive before the diagnosis does.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Native Android, cross-platform, or a progressive web app
Native Kotlin
Fits: Performance-critical apps and deep platform integration
Limits: Android only; an iOS version is a separate build
Cross-platform
Fits: Standard interfaces needing both stores from one codebase
Limits: Platform-specific work still appears; some capabilities need bridging
Progressive web app
Fits: Content and tools where installation from a link is enough
Limits: No Play Store listing; some device capabilities out of reach
Case studies
No published Android case study. Download and rating figures are easy to quote selectively.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
How many Android versions should we support?
Check your own analytics rather than global statistics. Supporting older versions extends reach and costs compatibility work, and the trade-off is specific to your user base. For consumer apps in India that trade usually favours reaching further back than a Western-market app would.
Native or React Native?
Cross-platform if the interface is mostly standard and you want both stores from one codebase. Native if you are doing something performance-critical or deep in the hardware. Most business apps do not need native, and the ones that do usually know why.
Why is our app slow on some phones?
Almost always memory and CPU on mid-range hardware. Apps tested on flagships hide the problem: background processes get killed, scrolling stutters, and startup takes seconds. Testing on a representative device finds it in an afternoon.
How much data will the app use?
As much as you let it, and for users on metered connections it matters more than most teams assume. Oversized images, unnecessary polling and uncached requests are the usual causes, and heavy data use shows up in uninstalls rather than in complaints.
What are the Play Store requirements?
A data safety declaration describing what you collect and share, a minimum target API level updated annually, and policy compliance for your category. The annual API level requirement catches teams out, an app that is not updated eventually stops being distributable.
Do we need an iOS version too?
Depends entirely on your audience. In India Android dominates and an Android-only launch is often reasonable. In markets where iOS carries more of the spending, launching Android-only can miss your best customers. Check your existing web analytics for the split.
Can we publish to other Android stores?
Yes. There are alternative stores, and in some markets they carry real share. Each has its own submission process and policies, so it is additional work rather than a free extension of reach.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.