openskills.info
← The sensible career map

Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming a Mobile Engineer

A mobile engineer builds an application the customer carries in their pocket, which is a perfectly reasonable arrangement until the pocket rings, the application is killed, and the customer is left holding the call. You translate "make it an app" into lifecycles, permissions, navigation, state, persistence, networking, and the quiet assumption that the operating system is your friend, a position the operating system holds only between updates and never during them. You learn that a lifecycle event will destroy your state at the exact moment the user needed it, that a permission dialog the user dismissed once is a permission the user will not be asked again, and that an app store review is a bureaucracy that reviews your submission with the diligence of a clerk who has never heard of your deadline. The work travels from one screen that works on one emulator to an app that works across devices, OS versions, networks, and the user who is not on the latest phone and has never been on the latest phone and is doing fine. This guide moves from writing one screen to setting mobile platform strategy across teams, with practical stops at lifecycles, architecture, testing, security, delivery, and the recurring discovery that the crash was always in the lifecycle; it was merely waiting for a background event to make it official. The grand objective is a reliable app at a defensible battery cost; the daily evidence is usually a build that does not require a hotfix, a crash-free rate that survives a real device, and a release whose store review did not require an appeal to a bureaucracy that has never heard of you.

Level 1 · Novice

Read the lifecycle before trusting the screen to remember what a user is

You inspect screens, lifecycles, platform docs, and an emulator log without shipping to a store, learning how a polite screen can lose a user's state before the background event finishes agreeing with itself.

You begin with read-only artifacts: a screen's layout, the activity or view controller's lifecycle callbacks, the platform's documentation, the emulator log, and a recent crash report. Mobile foundations covers the lifecycles, platform constraints, and interaction models that decide when an app is foreground, background, paused, or dead; native development builds applications using Android or iOS platform tools and conventions. A lifecycle callback is the function the operating system calls when the app's state changes — onCreate, onResume, onPause — and the function the engineer forgets is the function the operating system forgets with the diligence of a clerk following orders. You review these with designers, a platform-aware reviewer, and an experienced engineer so everyone can trace how a screen becomes state before anyone ships a feature whose restoration will outlast the user's patience.

Suppose a team wants to add a "compose message" screen. In a sandbox with no store access, you read the lifecycle, follow the pause into the save-state handler, inspect the manifest's launch mode, and note that the screen saves nothing on pause and the OS will reclaim it on background with the poise of a system following orders. You record the gap, the draft the user will lose, and the single permission the manifest requests unnecessarily. One brisk walkthrough is a sighting, not a design; but it prevents the team from launching a screen that forgets the user's message at the exact moment they needed to answer a call.

Words from the spaceship manual, translated

Lifecycle
The sequence of states an app moves through — foreground, background, paused, stopped, destroyed — and the callbacks the OS issues at each. It is the lease the operating system grants, and the system will evict without notice when memory is short.
Activity or view controller
The platform unit that holds a screen's state and handles its lifecycle. It is the screen's landlord, and the landlord will reclaim the screen when the user turns away.
Save-state
The discipline of persisting a screen's transient state on pause so the OS can restore it after reclaim. Save-state is the difference between a draft that survives a background event and a draft the user rewrites with the patience of someone who has been here before.
Manifest
The platform file that declares an app's screens, permissions, and launch modes. It is the app's passport, and a permission declared without need is a permission the user will question.