Mobile App Developer · path guide

Mobile App Developer: path guide

Read this before you start. It explains what the role is, what you'll be able to do at the end, which core lessons you need, how to set up your tools, what it may cost and how long it really takes.

The role

A mobile app developer builds apps for phones and tablets, from the first screen to the store listing. They work with constraints a website rarely meets: small screens and fingers instead of a mouse, patchy networks, limited battery and memory, many low-cost phones, and stores that review every release. They choose between native and cross-platform tools, keep the app working when the signal drops and sync when it returns, make screens fast and usable for everyone, ask for the phone's features with care, and take each release through testing, signing and a staged rollout. Success is measured by an app people can rely on, in the conditions they actually live in, not by how it looks on the developer's own phone.

Everyday applications

• A health worker in a village records patient visits with no signal, and they reach the clinic's system when she's back in town.
• A delivery app that stays smooth on a phone with 2 GB of memory, with a list of hundreds of orders.
• A banking app that someone using a screen reader can use as easily as anyone else.
• A ride-hailing app that asks for location only when you book, and explains why.
• An update that reaches 10% of users first, so a bug on one phone model is caught before everyone gets it.

What you'll be able to do

By the end of the path you will be able to:

1. PO1 Explain how mobile differs from the web: screens, touch, networks, battery, lifecycles, stores and updates (MA1).
2. PO2 Build screens with React Native and Expo: components, state, lists, navigation and the project's tools (MA2).
3. PO3 Choose between native and cross-platform approaches for a team, its users and its app, and explain the trade-offs (MA3).
4. PO4 Organise an app's code into screens, state, storage and sync, and keep its data on the phone safely (MA4).
5. PO5 Make an app work offline first, with an outbox, idempotent sends, backoff, timeouts, cursors and conflict merging (MA5).
6. PO6 Design for touch and accessibility: target sizes, roles and names, gesture alternatives, dark mode and contrast (MA6).
7. PO7 Make an app fast on low-cost phones with virtualised lists, memoised rows, a bundle budget and device testing (MA7).
8. PO8 Use device features with permissions asked in context, work within background limits, and protect users' data (MA8).
9. PO9 Test, version, sign, build automatically and release through the stores' testing tracks and a staged rollout (MA9).
10. PO10 Combine all of this in three tested projects and a capstone on the KhetNote practice kit (MA10).

The coverage of each outcome by lessons, quizzes and the path test is listed at the end of this guide.

How it compares with neighbouring paths

The difference in one line: other paths build for screens and servers you control; this path builds for phones you don't, in people's hands, through stores that check every release.

Before you start: core lessons to know

The path opens after you pass the final examination. These core modules matter most; revisit them if the entry diagnostic shows a gap:

Setup guide

Tested on 2 November 2026 on Linux. Versions change, so check each tool's official page when you install. The practice kit pins its packages in package-lock.json, so npm ci installs the same versions for everyone.

Install:

1. Install Node.js 22 or newer from nodejs.org. Check: node --version prints v22 or newer.
2. Download the starter kit from this path's Projects page and unzip it. In a terminal, go to the khetnote folder.
3. Run npm ci. It installs about 1,000 packages (about 640 MB) in under a minute on a good connection.
4. Run npm run server and, in a second terminal, curl http://127.0.0.1:8095/visits?since=0. You should see visits as JSON. Stop the server with Ctrl+C.

Verify your setup: run npm test in the khetnote folder. In the starter all 28 tests fail on purpose; what matters is that the tests start, list 28 checks and finish. One release test builds the code bundle, so the whole run can take a minute or so.

Windows and macOS: we could only verify Linux on 2 November 2026, so Windows and macOS are marked "not verified" in the kit. The commands are the same in PowerShell and the macOS terminal.

Hardware and accounts

• Computer: a laptop from the last 6 to 8 years with 8 GB of memory and about 2 GB of free disk space. Emulators, if you try them, need more.

• No paid accounts are needed. The kit runs on your own computer, with a practice sync server and simulated connectivity. KhetNote's 120 farms, 520 visits and advisers (listed by ID only) are invented. Passing its tests shows your code handles these cases; it doesn't prove the app behaves the same on every real phone, or that a store would accept it.

• Optional: if you create a store or cloud build account, read its fees and limits first, set any spending limit it offers, and keep tokens and signing files out of shared files.

Workload

Times are realistic estimates for a learner who has finished the core programme. They are not measured averages.

At 8 to 10 hours a week that is about 13 to 18 weeks.

How completion works

You complete the path when all of these are true, as shown on your completion record:

• every lesson is marked done;
• every module quiz is passed (70% or more);
• the path test is passed (70% or more);
• the three projects and the capstone are self-checked complete, with evidence links and your explanations.

Projects are self-checked for now: you tick the marking guide yourself and save your evidence on this device. Review by a team is planned for later; until then nothing on this site says a reviewer has approved your work. Progress is saved in this browser only, so download a backup from My progress now and then.

Outcome coverage