Android App Development: Fragmentation, Kotlin, and Play Store Reality

Android reaches far more devices than iOS globally, publishes with less editorial friction, and costs more to test. Those three facts define the platform. The engineering is not harder than iOS engineering. The variability is the work.

‍

A team that budgets Android as though it were iOS with different syntax will underestimate quality assurance and overestimate how much of its test coverage on flagship hardware means anything.

Fragmentation, described accurately

Fragmentation is real and frequently exaggerated into a reason to avoid the platform. Three dimensions matter and they matter unequally.

OS version spread. Android adoption of new releases is slower and less uniform than iOS, so a meaningful share of active devices run versions two or three years old. This affects which APIs you can rely on and where you need compatibility handling. Google's support libraries absorb much of this, and the residual work is real.

Screen and form factor variety. A far wider range of sizes, densities, aspect ratios, and notch or cutout arrangements, plus foldables and tablets. Layouts must be genuinely responsive rather than tuned to a handful of known sizes.

Manufacturer behaviour. The dimension people underestimate. Several manufacturers implement aggressive battery and process management that kills background work, delays notifications, or restricts alarms in ways that differ by brand and by device settings. An app relying on background sync or timely notifications will behave differently across manufacturers, and no amount of standards compliance fully resolves it.

That third point is the most common cause of an Android app working perfectly in testing and failing in the field. Test on the hardware your users actually carry, which is frequently mid-range devices several generations old rather than the current flagship on the developer's desk.

Kotlin, and cross-platform alternatives

Kotlin is the standard language for native Android development, officially preferred by Google, and Java remains supported and common in older codebases. For anything new, Kotlin is the answer.

Cross-platform via Flutter or React Native serves Android and iOS from one codebase and reduces build cost by 30 to 40 percent against two native builds. It also reduces the fragmentation testing burden somewhat, because the framework absorbs some device variability, though not manufacturer background restrictions, which reach every app regardless of how it was built.

Native Android remains correct when the product depends on background execution, Bluetooth peripherals, advanced camera control, or tight integration with platform services. Bolder Apps builds native Android in Kotlin and cross-platform in Flutter and FlutterFlow, and the practical question to any partner is which specific requirement in your product drives their recommendation, because on Android the honest answer is frequently background behaviour rather than performance.

The Google Play surface

Publishing on Android is less editorially controlled than on iOS and has hardened considerably in recent years.

Target API level requirements. Google Play requires apps to target a recent Android API level, and the threshold rises annually. Apps that are not updated eventually become undistributable to new users. This is a maintenance obligation with a deadline attached, and it is the single most common reason a neglected Android app disappears from the store.

App bundles. Distribution uses the Android App Bundle format, with Google generating optimised builds per device configuration.

Data safety declarations. A required disclosure of what data your app collects and shares, covering third-party SDKs. Inaccuracy is an enforcement matter.

Permissions justification. Sensitive permissions, particularly location, storage, and any accessibility service use, require declared justification and are reviewed. Background location in particular receives close scrutiny.

‍

‍

Account deletion. Apps with account creation must provide deletion, including a web-accessible route.

Billing. Digital goods sold in the app generally use Google Play Billing with commission applied, subject to specific exceptions that have shifted. Verify current policy rather than relying on prior understanding, since it affects unit economics.

The Android maintenance obligation that surprises people most is the annual target API level requirement. An Android app left untouched for two years is not merely dated. It becomes unavailable to new users, which is a business outcome rather than a technical one.

Background work, which is the platform's defining constraint

If your product depends on doing something while the app is not in the foreground, this section is the project.

Android's modern approach routes deferrable background work through WorkManager, which respects system constraints and survives process death. Foreground services with visible notifications cover genuinely ongoing work such as navigation or active tracking. Exact alarms are restricted and require justification.

On top of the platform rules, manufacturer battery optimisation may still restrict your app unless the user exempts it, and the exemption path differs by brand. Products that need reliable background behaviour, delivery tracking, field data sync, medication reminders, need an explicit strategy here including user-facing guidance, and they need testing across brands rather than on one device.

Cost and timeline

Android quality assurance costs more than iOS QA for the same feature set, commonly by 20 to 40 percent, because the device matrix is wider. Budget it explicitly rather than assuming parity. Bolder Apps prices project work fixed-scope rather than hourly with projects starting around $30,000, and on Android specifically the value of a fixed scope is that device coverage is defined up front rather than negotiated when a bug appears on a brand nobody agreed to support.

Choosing a partner for Android work

Five questions that separate teams who have shipped Android at scale from teams who have shipped Android once.

What device matrix do you test on, and does it include mid-range hardware? An agency that tests on current flagships has not encountered the performance and memory realities of the devices most Android users carry.

How do you handle manufacturer battery restrictions? A specific answer involving WorkManager, foreground services where justified, and user-facing exemption guidance. A general answer about following best practices means they have not hit the problem yet.

Who manages target API level compliance after launch? This has an annual deadline and consequences for distribution, and it needs an owner rather than an assumption.

How do you handle data safety declarations across third-party SDKs? This is an inventory exercise, and a partner who has done it will describe it as one.

Under whose Play Console account does the app live? Yours, with the agency added as a user. An app published under an agency's account is a dependency that becomes visible at the worst possible moment.

Bolder Apps builds native Android in Kotlin and cross-platform in Flutter and FlutterFlow and prices project work fixed-scope rather than hourly. On Android the specific value of a defined scope is that the supported device and OS range is agreed in writing up front, rather than becoming an argument the first time a bug appears on a brand nobody discussed.

‍

‍

Maintaining an Android app

Android maintenance is driven by two calendars: Google's annual platform release and Google Play's rising target API level requirement. The second is the one with teeth, because non-compliance eventually removes your app from distribution to new users rather than merely dating it.

Beyond that, expect dependency updates, adaptation to new permission models, and periodic re-testing across the device matrix as manufacturers ship their own OS layers. Fifteen to twenty percent of build cost annually is the realistic reserve, and neglecting it for two years converts routine upkeep into a migration.

Where Android is the right first platform

Three cases, and they are commercially significant rather than exotic.

Markets where Android dominates. Much of Asia, Africa, and Latin America, plus large parts of Eastern Europe. A product targeting these markets that launches iOS first has launched to a minority.

Field and industrial deployments. Rugged devices, handheld scanners, and company-issued hardware are overwhelmingly Android, which makes Android the only platform that matters for construction, logistics, warehousing, and field service applications.

Products needing device-level latitude. Android permits background behaviour, file access, and hardware interaction that iOS restricts, which occasionally makes it the only viable platform for a specific capability.

Designing for Android specifically

Android users notice when an app ignores platform conventions, and the tells differ from iOS. Back navigation, including predictive back and hardware or gesture back, must behave correctly. Material design patterns are expected rather than optional, though a strong brand system is perfectly acceptable. Notification channels let users control categories of notification and are a requirement rather than a nicety. Dark theme and dynamic colour should be handled. And text scaling settings must be respected, which is an accessibility obligation as much as a preference.

Cross-platform frameworks again do not exempt you. A Flutter app that ships iOS-shaped navigation on Android reads as a port, and users say so in reviews.

Frequently asked questions

How many devices do we need to test on? A representative matrix rather than an exhaustive one. Two or three OS versions covering your active user spread, a low-end or mid-range device, a current mainstream device, one large-screen or tablet form factor, and one device from a manufacturer known for aggressive battery management. Cloud device farms cover breadth economically once your core set is defined.

Is Google Play review as strict as Apple's? Less editorially opinionated, and policy enforcement is substantial and increasingly automated. Data safety accuracy, permission justification, and target API level compliance are the common friction points, and enforcement can arrive after publication rather than only at submission.

What does a Google Play developer account cost? A one-time registration fee of $25, considerably cheaper than Apple's annual membership. Note that newer developer accounts may face additional verification and testing requirements before public distribution, so enrol early.

Should we support tablets and foldables? Support responsive layouts from the start, because it costs little during design and is expensive to retrofit. Dedicated tablet-optimised experiences are worth building where your audience uses them, which is common in field, medical, education, and creative contexts and rare in consumer social products.

Why does our app get killed in the background on some phones? Manufacturer battery optimisation, in most cases, rather than a defect in your code. The mitigations are using WorkManager for deferrable work, a foreground service for genuinely ongoing work, and guiding users to exempt your app where reliability is essential. Test across brands, because this behaviour is not uniform.

Sources

• Android developer documentation on background work restrictions and WorkManager, developer.android.com
• Google Play target API level requirements and policy documentation, support.google.com/googleplay/android-developer
• Google Play Data safety section requirements
• Android App Bundle documentation, developer.android.com
• Material Design guidelines on navigation and adaptive layouts, m3.material.io
• Kotlin language documentation, kotlinlang.org