Kotlin & Android: Jetpack Compose, Coroutines & MVVM

Q: Jetpack Compose or XML layouts?

For new apps, use Jetpack Compose — it's Google's recommended modern toolkit, with declarative, state-driven UI, less boilerplate than XML + View binding, and strong tooling (previews, live edit). XML/View-based UIs remain in countless existing apps and are still fully supported, so you'll encounter them — and Compose interoperates with Views for incremental migration. Greenfield Android should start with Compose.

Q: What architecture should I use?

MVVM is the de facto standard on Android: a ViewModel exposes UI state (surviving configuration changes), a repository layer owns data access, and the UI observes state. Add dependency injection (Hilt) as the app grows. For more complex apps, layer in a clean/domain layer (use cases). The key is consistency — pick the layered MVVM approach early and apply it uniformly.

Q: Native Kotlin/Android or a cross-platform framework?

Choose native Kotlin for the best Android integration, performance, and immediate access to new platform features — ideal when you don't need iOS from the same codebase or want maximum fidelity. Choose cross-platform (Flutter, React Native, or Kotlin Multiplatform for shared logic) when you need both platforms from shared code. Native maximizes platform fit; cross-platform maximizes code sharing.

Kotlin & Android Development

Modern Android development is Kotlin-first, with Jetpack Compose as the recommended UI toolkit for new apps. Kotlin replaced Java as Google's preferred Android language for good reasons — null safety, concise syntax, and first-class coroutines for asynchronous work — and Compose brings the same declarative, state-driven UI model that's become standard across platforms.

The path for a new Android app is well-paved: Kotlin + Compose for the UI, coroutines for async, and a layered architecture (usually MVVM) with a ViewModel holding UI state and a repository owning data. Standardizing that architecture early keeps a growing app maintainable.

TL;DR

Kotlin is the default Android language.
Jetpack Compose enables declarative, state-driven UI.
Coroutines handle asynchronous work cleanly.
Standardize architecture (usually MVVM) early.

Quick Example

Compose UI is declarative — it recomposes when state changes:

Core Pieces

Kotlin language + coroutines — null safety, concise syntax, structured concurrency for async work.
Jetpack Compose — declarative UI that recomposes from state.
App lifecycle — activities/composables move through lifecycle states; respect them to avoid leaks and crashes.
Navigation & deep links — Navigation Compose for in-app routing and external links.

Architecture

The standard layered approach:

ViewModel — holds UI state and logic, survives configuration changes.
Repository — owns data access (network + local), exposing a clean API to the ViewModel.
Dependency injection (Hilt/Koin) — wire it together where appropriate.

Best Practices

Keep UI stateless where possible — hoist state out of composables; pass it down, send events up.
Never do heavy work on the main thread — use coroutines with the right dispatcher (Dispatchers.IO).
Handle offline and error states intentionally — don't assume the network is available.
Scope coroutines correctly (viewModelScope) so they cancel with their owner.
Standardize on one architecture and DI approach across the team.

Common Mistakes

Blocking the main thread

Leaking coroutines / context

FAQ

Jetpack Compose or XML layouts?

For new apps, use Jetpack Compose — it's Google's recommended modern toolkit, with declarative, state-driven UI, less boilerplate than XML + View binding, and strong tooling (previews, live edit). XML/View-based UIs remain in countless existing apps and are still fully supported, so you'll encounter them — and Compose interoperates with Views for incremental migration. Greenfield Android should start with Compose.

Why coroutines instead of threads or callbacks?

Coroutines provide structured concurrency: you write asynchronous code that reads sequentially (suspend functions, launch/async), with built-in cancellation tied to lifecycle scopes (viewModelScope). This avoids callback nesting and the manual thread management and leak risks of raw threads. Combined with the right dispatcher (Dispatchers.IO for I/O), they're the idiomatic, safe way to do async work on Android.

What architecture should I use?

MVVM is the de facto standard on Android: a ViewModel exposes UI state (surviving configuration changes), a repository layer owns data access, and the UI observes state. Add dependency injection (Hilt) as the app grows. For more complex apps, layer in a clean/domain layer (use cases). The key is consistency — pick the layered MVVM approach early and apply it uniformly.

Native Kotlin/Android or a cross-platform framework?

Choose native Kotlin for the best Android integration, performance, and immediate access to new platform features — ideal when you don't need iOS from the same codebase or want maximum fidelity. Choose cross-platform (Flutter, React Native, or Kotlin Multiplatform for shared logic) when you need both platforms from shared code. Native maximizes platform fit; cross-platform maximizes code sharing.