MA1: How mobile is different: devices, networks and the app lifecycle
What a mobile developer does
🎯You'll be able to
Describe the mobile developer's job from the first screen to the store, and explain why mistakes last longer on phones than on the web.
🏠The everyday picture
A printed railway timetable is handed to thousands of travellers. If it has a mistake, you can print a new one, but people keep using the old copy in their pocket until they happen to pick up the new one.
📘What it really is
-
A mobile developer builds apps that run on phones and tablets: the screens, the data kept on the phone, the connection to a server, and the release through the App Store and Google Play.
-
Releases are slow to reach people: each one may wait for a store review, and users update when they choose. Old versions keep running for months, so they must keep working with your server.
-
The device is shared: your app competes with others for memory, battery and attention, and the system can pause or close it.
-
The work is constraint-driven: small screens, touch instead of a mouse, networks that come and go, and phones of very different power.
-
The job includes the store: signing the app, testing with real users before release, writing the listing and answering privacy questions truthfully.
📝A worked example
Input: KhetNote's brief: crop advisers record farm visits in Nashik district, where signal drops in many fields.
Steps:
- List who uses it and where: advisers, outdoors, often in bright sun, sometimes with gloves or wet hands.
- List what can go wrong: no signal, the phone low on battery, a call interrupting, an old phone with 2 GB of memory.
- Turn each into a requirement: save without signal; large touch targets and good contrast; keep work when interrupted; a light app.
Expected output: a short list of requirements that come from the device and the setting, not just from the features.
🌍Where it's used
- Ride-hailing apps work in moving cars with changing signal.
- Banking apps release carefully, because a broken version stays on phones.
- Field apps for health workers, farmers and delivery staff work offline for hours.
📝Case scenario
A delivery app shipped a release that sent the wrong date format to the server. The server team fixed their side in an hour, but the broken app stayed on thousands of phones for weeks. After that, the team kept the server accepting both formats until old versions were rare, and tested every release against the previous app version.
🖱️Try it
Install the KhetNote kit, run npm test, and read README.md. Write three requirements for KhetNote that come from where advisers work
rather than from what the app does. Success: each requirement names a condition (signal, light, gloves, memory) and what the app must do.
⚠️Common mistakes
- Designing at a desk. Sign: the app is only tried on Wi-Fi and a new phone. Fix: list the real conditions first.
- Treating a release like a web deploy. Sign: "we'll fix it in an hour". Fix: plan for old versions staying in use.
- Forgetting the store. Sign: no time planned for review, signing or privacy answers. Fix: put the release in the plan from day one.
🛠️For your project
Your capstone design notes start from these requirements. Keep your list.
✅Quick check
Why do mistakes in a mobile app last longer than on a website?
Show the answer
Releases may wait for review and people update when they choose, so old versions stay on phones.
Which two conditions shape a field app like KhetNote?
Show the answer
Patchy signal and older, low-memory phones (also bright light, gloves and interruptions).