Android / Kotlin

The system owns your screen

Rotate the device and Android destroys your activity and builds a new one. So does changing the language, resizing a window in split screen, switching theme, or connecting a keyboard. The object your code was holding is gone and a fresh instance is running the same screen. Every new Android developer meets this the same way — as a form that empties itself the first time someone turns the phone sideways.

There is a second, harsher version of the same thing. While your app is in the background, the system may kill its process outright to reclaim memory — and when the user comes back, Android recreates the app at the screen they left, from nothing. This is not an edge case on a mid-range phone with a dozen apps open. It is why the storage question has three answers rather than one, and why picking the wrong one produces a bug you cannot reproduce on your own device.

The same reasoning governs background work. An app that is not on screen has no right to keep running, and the platform has tightened this with every release — background limits, doze mode, and manufacturers who add their own restrictions on top. Work that must eventually happen goes to WorkManager, which persists it and runs it when the system permits, surviving both process death and reboot. Work that must be visible while it happens needs a foreground service and a notification, because the user is entitled to know.

Kotlin, and coroutines in particular

Kotlin is the language of Android now — Google's recommendation, the language the documentation is written in, and what all the modern APIs are designed around. It runs on the JVM and calls Java libraries directly, so adopting it in an existing Java codebase is file by file rather than all at once. Two of its features earn their place immediately: nullability is part of the type system, so a value that can be null cannot be used as if it cannot, and data classes remove the boilerplate that made Java models tedious.

Coroutines are the part that changes how Android code is written. A suspending function can pause without blocking its thread, so asynchronous work reads top to bottom instead of as nested callbacks. The concept that makes them safe rather than merely convenient is structured concurrency: every coroutine belongs to a scope, and when the scope is cancelled every coroutine inside it is cancelled too. Launch work in viewModelScope and it stops automatically when the ViewModel goes away — the leak of a background task updating a screen that no longer exists is designed out rather than remembered.

On top of coroutines sits Flow, a stream of values over time — the natural shape for a database query that should re-emit when the data changes, or a search field that should query as the user types. For screen state specifically, StateFlow holds a current value and emits updates, which is exactly what a UI needs: something that can be read immediately when the screen is rebuilt and observed for changes after that.

Compose and the View system

Jetpack Compose is the modern UI toolkit and the recommended one: you write composable functions that describe the interface for a given state, and the framework recomposes what changed. It replaces XML layouts, findViewById, adapters and the whole apparatus of holding view references and mutating them by hand — for a list, it is the difference between a RecyclerView adapter with a view holder and a LazyColumn with a lambda.

The pattern the platform documentation now assumes, and which is worth adopting whichever UI toolkit you use: state flows down and events flow up. A composable receives its state as a parameter and reports events as lambdas, holding no state of its own where it can avoid it. That makes it previewable, testable and reusable, and it puts every decision about what the screen should show in one place — the ViewModel — which is also the only place that survives the recreation this page opened with.

How this shows up in real delivery

Fragmentation is real but it is not what people imagine. The API level problem is largely solved — the support libraries backport most of it, and minSdk is a number you choose with data from your own users. What genuinely differs is the hardware underneath: a phone with two gigabytes of memory and a slow processor will kill your process sooner, drop frames your test device never drops, and expose every allocation in a scroll handler. Test on a cheap device, because a meaningful share of your users are on one.

Release is more forgiving than on iOS in one way and stricter in another. Google Play review is usually faster, and staged rollouts let you release to one per cent of users, watch the crash rate in the console, and halt without shipping a new build. On the other hand, policy enforcement is automated and unsentimental — target API level deadlines, permission declarations, and data safety forms that must match what the app actually does. Both of those are calendar items, not engineering ones, and they are the ones teams forget.

Where it degrades

• Screen state held in the activity, which empties the first time the device is rotated.
• Nothing written to saved state, so the app returns blank after the system reclaims the process.
• An activity context held by a singleton or a static field, leaking the whole view hierarchy.
• Background work started outside a lifecycle scope, which keeps running with nowhere to deliver.
• Deferred work run in a service rather than WorkManager, so it dies with the process.
• Permissions requested at launch instead of in context, which trains users to decline.
• Testing only on a flagship, which hides every memory and frame problem your users actually have.

When to use it

Related pages

• DevelopmentiOS / SwiftiOS is one vendor, one toolchain and one set of rules — and, in exchange, a platform where the hardware, the OS and the language are designed together. Swift is a modern, strongly typed language with no garbage collector, which makes memory something you reason about rather than something that happens to you. This page covers reference counting, SwiftUI against UIKit, concurrency, and the release process that surprises teams arriving from the web.
• DevelopmentJavaJava has been the default language of large back-end systems for thirty years, and it is still the one you find when a bank, an airline or a telecom opens its source tree. What makes Java what it is has less to do with its syntax than with the machine it runs on: bytecode instead of native code, a compiler that optimises while the program runs, and a garbage collector you tune rather than replace. This page covers the JVM, the type system, Spring, concurrency, and what virtual threads changed.
• DevelopmentFlutterFlutter is Google's answer to building for several platforms from one codebase, and it takes the opposite approach to React Native: instead of asking the operating system for its widgets, Flutter ships a rendering engine and draws every pixel itself. That one decision explains the consistency, the performance, the size of the binary and the places the approach struggles. This page covers the rendering pipeline, Dart, state management, and where Flutter fits.