Decision Guide
Choose Android Kotlin Compose when native Android capability is the product, not just the packaging format.
Use Android Kotlin Compose When
| Trigger | Why Native Android Wins |
|---|---|
| SMS parsing, call logs, contacts, notifications, device storage, Bluetooth, camera, sensors, widgets, or background scheduling are core | You need Android APIs, runtime permissions, Play declarations, and real-device behavior |
| Offline-first finance, ledger, tracker, or field app | Room, local files, exports, WorkManager, and low-connectivity testing are first-class |
| Play Store release is the main distribution path | Native release signing, app bundles, target API, and Play policy checks become unavoidable |
| Budget-device performance matters | Compose can be tuned and tested directly against Android rendering, memory, and startup behavior |
| Privacy posture matters | A no-network local app can be implemented and verified without a web backend |
Prefer Another Stack When
| Need | Better Default |
|---|---|
| Content, docs, dashboards, admin tools | Web app or PWA |
| Same-day iOS and Android launch with mostly shared UI | Flutter or React Native/Expo |
| Shared business logic but native UI on each platform | Kotlin Multiplatform later, not for the first Android-only v1 |
| Desktop-first local app | Native desktop, Tauri, or web depending on the product |
| Policy-sensitive SMS use without a strong core-functionality case | Avoid restricted SMS permissions; use manual import, user copy/paste, or explicit file import |
Android Native Versus PWA
Use PWA if the app can live inside the browser permission model and tolerate limited background behavior. Use native Android if users expect a launcher app that handles device events, local storage, restricted permissions, offline usage, notifications, or Play distribution.
For a Kenya SMS expense tracker, native Android is the right default because SMS access, local-first storage, budget-device testing, and Play policy evidence are not side details.
Android Native Versus React Native Or Flutter
React Native and Flutter reduce duplicate UI work across platforms. They do not remove Android policy, signing, target API, background work, or permission realities. If Android is the only near-term platform, native Compose removes a layer of indirection.
Pick cross-platform only when iOS parity is a near-term requirement and you can afford platform-specific escape hatches.
Android Native Versus Kotlin Multiplatform
Kotlin Multiplatform is useful when you already have meaningful shared business logic across Android and another platform. It is not the simplest first step for a solo Android v1.
Start Android-only. Keep repositories and pure domain logic Android-light where reasonable. Revisit KMP after the product proves it needs another platform.
Default Recommendation
For Android-first local apps, use this stack:
Kotlin + Compose + Material 3 + ViewModel + Flow + Room + WorkManager + Play App SigningKeep the first build boring. Ship one clear app module before modularizing.
Gotcha: A restricted permission can decide the whole stack. If the app needs
READ_SMS, design the policy narrative, fallback mode, data minimization, and privacy policy before writing the parser.