A mobile developer builds software that lives in someone's pocket, on a battery\nthat's always dying, a network that's always flaky, a device picked up two\nhundred times a day in conditions you never tested. The discipline exists because\nthe phone is the most personal and most constrained computer most people will\never own: interrupted constantly, killed by the OS without warning, throttled\nwhen it gets hot, judged in the first three seconds. The job is to make software\nthat feels instant and trustworthy inside a sandbox you don't control, on\nhardware you can't choose, mediated by a platform owner who can reject your\nrelease on a whim.
\n","wordCount":108},{"heading":"Core Mission","id":"core-mission","markdown":"Ship an app that launches fast, respects the device's battery, memory, and\nnetwork, survives being suspended and killed at any moment, and feels native to\nthe platform it runs on — and keep it alive across OS versions and a thousand\ndevice models you'll never hold.","html":"Ship an app that launches fast, respects the device's battery, memory, and\nnetwork, survives being suspended and killed at any moment, and feels native to\nthe platform it runs on — and keep it alive across OS versions and a thousand\ndevice models you'll never hold.
\n","wordCount":45},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"The visible work is building screens; the actual work is managing the device's\nhostility toward your process. A mobile developer designs UI that respects\nplatform conventions (Human Interface Guidelines on iOS, Material on Android);\nmanages the lifecycle so state survives backgrounding, process death, rotation,\nand low-memory kills; keeps the main thread free so the app never janks or\ntriggers an ANR; minimizes battery, memory, and network use; builds offline-first\nso the app works on a subway; wires up push notifications and deep links;\ninstruments crash and ANR reporting; navigates store review; and supports the\nlong tail of OS versions and screen sizes. Underneath it all: the user blames\nyour app for the platform's behavior, so you own problems you didn't cause.","html":"The visible work is building screens; the actual work is managing the device's\nhostility toward your process. A mobile developer designs UI that respects\nplatform conventions (Human Interface Guidelines on iOS, Material on Android);\nmanages the lifecycle so state survives backgrounding, process death, rotation,\nand low-memory kills; keeps the main thread free so the app never janks or\ntriggers an ANR; minimizes battery, memory, and network use; builds offline-first\nso the app works on a subway; wires up push notifications and deep links;\ninstruments crash and ANR reporting; navigates store review; and supports the\nlong tail of OS versions and screen sizes. Underneath it all: the user blames\nyour app for the platform's behavior, so you own problems you didn't cause.
\n","wordCount":123},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **The main thread is sacred.** 16ms per frame at 60fps, ~8ms at 120Hz. Any\n blocking work on the UI thread is jank, and >5s of it on Android is an ANR. Do\n work off-thread or don't do it.\n- **Assume the OS will kill you at any moment.** Your process is the first\n sacrificed under memory pressure. Persist state continuously; treat every\n lifecycle callback as possibly your last.\n- **Offline is the normal case, not the error case.** The network is absent,\n slow, or lying more often than it works. Design for it first, add the network\n as an optimization.\n- **Battery is the user's budget, not yours.** Wakelocks, GPS, unbatched calls,\n and background work drain trust along with the battery; the OS and the user\n both punish abusers.\n- **Native feel is a feature.** Back-button semantics, scroll physics, safe\n areas, and gesture conventions are not polish; getting them wrong reads as\n \"broken\" to users who can't say why.\n- **Test on real devices, especially cheap old ones.** The emulator lies about\n performance, thermals, and the camera; your worst user is on a three-year-old\n midrange Android. And the store is a gate you don't own — design release trains\n around its review latency.","html":"Mobile developers sit between designers who often draw for one screen size,\nbackend engineers whose APIs must work over flaky links, product managers who\nunderestimate release latency, and platform owners (Apple, Google) who can reject\na build. The healthy patterns: push back early on designs that ignore safe areas,\ndark mode, accessibility, and small screens; negotiate API shapes that minimize\nround-trips and support offline (pagination, deltas, ETags); and remind product\nthat a shipped bug can take days to roll out and a fix days more. The recurring\nfriction is the API contract and the release calendar — over-communicate at both.
\n","wordCount":101},{"heading":"Ethics","id":"ethics","markdown":"The phone is intimate: it holds location, contacts, photos, health, and is on\nthe user's body all day. Core duties: request the minimum permissions and explain\nwhy in context; never sell or leak location and identifiers behind the user's\nback; honor App Tracking Transparency and platform privacy manifests in spirit,\nnot just to pass review; refuse dark patterns — disguised ads, fake close\nbuttons, notification spam; build for accessibility (VoiceOver, TalkBack, Dynamic\nType), because a phone is how many disabled users access the world; and be honest\nabout the battery and data costs you impose. The gray zones — engagement loops\nengineered for compulsion, kids' apps — deserve to be named in the room, not\nshipped by default.","html":"The phone is intimate: it holds location, contacts, photos, health, and is on\nthe user's body all day. Core duties: request the minimum permissions and explain\nwhy in context; never sell or leak location and identifiers behind the user's\nback; honor App Tracking Transparency and platform privacy manifests in spirit,\nnot just to pass review; refuse dark patterns — disguised ads, fake close\nbuttons, notification spam; build for accessibility (VoiceOver, TalkBack, Dynamic\nType), because a phone is how many disabled users access the world; and be honest\nabout the battery and data costs you impose. The gray zones — engagement loops\nengineered for compulsion, kids' apps — deserve to be named in the room, not\nshipped by default.
\n","wordCount":115},{"heading":"Scenarios","id":"scenarios","markdown":"**The form that loses everything on rotation.** Android users lose a long\ncheckout form when they rotate. The junior instinct is to lock orientation. The\nexpert sees the real bug: the form state lived in the Activity, destroyed and\nrecreated on configuration change. The fix is architectural — move state into a\nViewModel backed by SavedStateHandle, so it survives both rotation and process\ndeath (the harder case, hit after backgrounding). They verify with \"Don't keep\nactivities,\" which forces process death on every backgrounding.\n\n**A one-star review wave: \"app drains my battery.\"** Reviews spike after a\nrelease, but there's no crash in Crashlytics. The energy profile shows a\nbackground sync meant to run every 15 minutes firing far more often: a retry loop\non network failure has no backoff, so on flaky networks it never stops retrying,\nholding a wakelock. The fix: exponential backoff with jitter, and batch the work\ninto WorkManager/BGTaskScheduler with OS constraints. The radio stops waking;\ncomplaints stop.\n\n**A \"simple\" launch-day feature blocked by store review.** Product wants a\nfeature using background location for a launch campaign. The expert checks policy\nfirst and finds both stores require a prominent disclosure and strong\njustification, and Apple's privacy manifest must declare it — a near-certain\nrejection or multi-day delay that misses the launch. They reframe: the feature\nonly needs location while the app is in use, which takes only foreground\npermission and passes review cleanly. The campaign ships on time; the background\nvariant goes behind a flag for a later, properly-disclosed release.","html":"The form that loses everything on rotation. Android users lose a long\ncheckout form when they rotate. The junior instinct is to lock orientation. The\nexpert sees the real bug: the form state lived in the Activity, destroyed and\nrecreated on configuration change. The fix is architectural — move state into a\nViewModel backed by SavedStateHandle, so it survives both rotation and process\ndeath (the harder case, hit after backgrounding). They verify with "Don't keep\nactivities," which forces process death on every backgrounding.
\nA one-star review wave: "app drains my battery." Reviews spike after a\nrelease, but there's no crash in Crashlytics. The energy profile shows a\nbackground sync meant to run every 15 minutes firing far more often: a retry loop\non network failure has no backoff, so on flaky networks it never stops retrying,\nholding a wakelock. The fix: exponential backoff with jitter, and batch the work\ninto WorkManager/BGTaskScheduler with OS constraints. The radio stops waking;\ncomplaints stop.
\nA "simple" launch-day feature blocked by store review. Product wants a\nfeature using background location for a launch campaign. The expert checks policy\nfirst and finds both stores require a prominent disclosure and strong\njustification, and Apple's privacy manifest must declare it — a near-certain\nrejection or multi-day delay that misses the launch. They reframe: the feature\nonly needs location while the app is in use, which takes only foreground\npermission and passes review cleanly. The campaign ships on time; the background\nvariant goes behind a flag for a later, properly-disclosed release.
\n","wordCount":256},{"heading":"Related Occupations","id":"related-occupations","markdown":"A mobile developer is a software engineer specialized against the hard wall of a\nconstrained, OS-governed device. They share the frontend engineer's obsession\nwith UI, rendering, and perceived performance, but on a platform that can kill\nthe process mid-frame. They lean on backend engineers for APIs and must shape\nthose contracts for flaky links. UX designers own the experience they implement,\nand product managers own the why. They share with embedded systems engineers the\ndiscipline of doing real work inside tight memory, power, and CPU budgets.","html":"A mobile developer is a software engineer specialized against the hard wall of a\nconstrained, OS-governed device. They share the frontend engineer's obsession\nwith UI, rendering, and perceived performance, but on a platform that can kill\nthe process mid-frame. They lean on backend engineers for APIs and must shape\nthose contracts for flaky links. UX designers own the experience they implement,\nand product managers own the why. They share with embedded systems engineers the\ndiscipline of doing real work inside tight memory, power, and CPU budgets.
\n","wordCount":88},{"heading":"References","id":"references","markdown":"- *iOS / Apple Human Interface Guidelines* — developer.apple.com/design\n- *Android / Material Design Guidelines* — m3.material.io\n- *Android App Architecture Guide* — developer.android.com/topic/architecture\n- *Effective Kotlin* — Marcin Moskała\n- App Store Review Guidelines and Google Play Developer Policy","html":"