Moving from Web to Android Development: What I Learned

Before getting serious about Android development, I’d spent a good while working in web. Moving from a web mindset to mobile required some adjustments I didn’t expect — and a few of them only became clear after the app shipped and a weird bug showed up in production.

Lifecycle is real and it matters

On the web, a “page” usually has a simple life — load, then unload, done. On Android, Activities and Fragments have a much more complex lifecycle (onCreate, onStart, onResume, onPause, and so on), and forgetting to handle one of those states can crash the app or leak memory. The first bug that made this really click for me: a user rotated their device, the Activity got destroyed and recreated, and the state I’d stored in a plain variable just vanished. There’s no equivalent concept on the web of “the screen rotates and everything resets” — so this was genuinely something to learn from scratch, not just new syntax for a concept I already knew.

Resource constraints are real

On the web, you don’t usually think much about the user’s memory or battery — the browser and OS absorb most of that burden. On mobile, every background task, every wake lock, has a direct cost to the user’s battery life, and they’ll uninstall your app if it’s wasteful. I once shipped a feature that polled the server every few seconds in the background without thinking twice — a habit that’s harmless on the web, but on Android it caused a noticeable battery drain, and I found out from a one-star Play Store review, not from internal testing.

Async is the default, not optional

Network calls, disk I/O, all of it needs to be async so it doesn’t block the main thread and freeze the UI. Kotlin Coroutines makes this far more manageable than the callback hell I remember from first learning Android with Java. But the transition from how async works on the web (Promises, relatively straightforward async/await) to coroutine scopes, structured concurrency, and lifecycle-aware coroutines on Android took real time to understand properly, not just copying patterns off Stack Overflow.

Testing is more of a hassle

There’s no “refresh the browser” to see a change. The build-deploy-test cycle on Android is much slower than hot-reload on the web, though it keeps improving with modern tooling like Jetpack Compose Preview. Early on this was genuinely frustrating — the fast-iteration habit from web made me impatient waiting on an Android build that could take over a minute just to see a one-line change.

What I’m most grateful for from this experience: the “resource-aware” mindset from mobile development ended up making my web code more efficient too — I’m a lot more attentive now to how often a component re-renders or how often a request fires, a habit I didn’t have before learning Android.