Native Android App Development in Kotlin
Client comes with ready design, sometimes with Figma prototype, asking: "Why can't we just use React Native?" Answer depends on what the app actually needs. If it's Bluetooth LE work, complex navigation stack, background geolocation, or screen recording — native Android in Kotlin saves from whole class of problems that in cross-platform are solved via hacks and native modules, which is essentially the same code, just hidden behind abstraction.
Kotlin is the main Android development language since 2019. Google rewrites its own libraries from Java to Kotlin, Jetpack Compose exists only in Kotlin, and new APIs like kotlinx.coroutines or Flow simply don't have proper Java equivalents. Choosing Kotlin is not preference, it's following the ecosystem.
What Modern Android Project Actually Consists Of
Architecture of typical commercial app in 2024 looks like: Clean Architecture with layer split data / domain / presentation, MVVM as presentation layer pattern, Hilt for dependency injection. Navigation via Navigation Component with NavGraph or more flexible Decompose for complex nested stacks.
UI built on Jetpack Compose. This is not "trendy technology" — it's already standard. Compose eliminates gap between state and UI: no notifyDataSetChanged(), no ViewHolder boilerplate, no sync between XML and code. @Composable function just describes what UI looks like given state, and Compose itself recalculates what changed through smart recomposition.
For state management use StateFlow plus ViewModel. For complex UI with shared state across screens — MVI pattern with single UiState and UiEffect. Business logic lives in UseCase classes, unaware of Android specifics, easily covered by unit tests without Robolectric.
Network layer: Retrofit 2 plus OkHttp with interceptor chain for auth, logging, retry logic. Serialization — kotlinx.serialization or Gson/Moshi by team preference. Local storage — Room with TypeConverters for custom types and @Transaction for atomic operations.
Background tasks — WorkManager for delayed and periodic operations, coroutines with proper CoroutineScope for one-off tasks. Problem of "coroutine started, Activity died, thread leaked" solved via viewModelScope and repeatOnLifecycle.
Where Time Gets Lost Most During Development
Problem is not code writing — it's decisions made in first two weeks. Most expensive mistakes happen there:
Navigation without clear scheme. In Navigation Component tempting to add fragments as needed. Three months later you get graph you can't understand: where user came from, where returns after deep link. We design NavGraph upfront, isolate nested graphs for each feature module, and backstack doesn't become puzzle.
Wrong lifecycle. collectAsStateWithLifecycle() instead of collectAsState() — seems minor. But without proper lifecycle-aware collection, Flow keeps working when app is backgrounded, and battery dies. Crashes from Firebase Crashlytics with IllegalStateException: Cannot collect flow on dead lifecycle say exactly this.
Multithreading on main thread. Database access Room on main thread in debug build throws IllegalStateException — good, immediately visible. But decoding 4K photo Bitmap in onBindViewHolder with old RecyclerView approach doesn't throw, just drops frames. Coil and Glide solve this via coroutines and worker threads, but only if ImageLoader properly set.
Wrong scope at Hilt components. @Singleton repository with @ActivityScoped dependency inside — and Hilt honestly crashes with [Dagger/MissingBinding] at build. Not at runtime — at build. Good, but not everyone understands long Dagger codegen stack trace.
How Work Is Organized
Start with technical audit of requirements: screen list, integrations (API, third-party SDK, push via FCM, analytics via Firebase/Amplitude), offline mode requirements, minimum supported API version (usually API 24 / Android 7.0, rarely API 21).
Then — architectural decision: monolithic module or multi-module project. Multi-module speeds up incremental Gradle builds and provides feature team isolation, but adds dependency setup complexity. For projects under 5–7 feature teams, monolith with clear package boundaries more practical.
Development goes in 1–2 week sprints with demo at end of each. CI set up from day one: GitHub Actions or GitLab CI, build plus unit tests plus lint on each PR, Firebase App Distribution for test build distribution.
Testing: unit tests on UseCase and ViewModel via JUnit5 plus MockK, UI tests via Espresso or Compose Testing API. For complex flows — integration tests with in-memory Room database.
Before release — obfuscation via R8, check android:exported for all components (Google Play requirement from API 31), test on several devices from different manufacturers via Firebase Test Lab.
Timeline Estimates
| Project Type | Estimate |
|---|---|
| MVP with 5–8 screens and REST API | 4–6 weeks |
| App with complex logic, offline, push | 8–12 weeks |
| Complex product with multiple integrations | 3+ months |
Cost calculated individually after requirements analysis and technical specification creation.
What Affects Complexity Most
Not screen count — integrations do. FCM with rich notifications and custom sounds — three days. Biometric auth via BiometricPrompt API with PIN fallback — day-two. Bluetooth LE work via BluetoothGatt on multiple devices simultaneously — separate project within project, because manufacturers implement GATT stack differently.
Maps: Google Maps SDK connects in hour, but custom markers with clustering, polygons, offline tiles — several days already. In-app purchases via Google Play Billing Library 6.x with subscriptions, promo codes, graceful degradation on Play Store unavailability — easily a week.
All this scope must be understood before development starts. So first step — detailed specification, not "back of napkin" estimate.