Mobile App Development

Build, test and publish a production quality mobile app that works offline, handles permissions correctly and survives app store review.

8 Weeks4 Sessions/WeekIn PersonIntermediate

Mobile UIOffline SyncApp Store Release

Share this course

Overview Curriculum Capstone Assessment Enquire

What you'll be able to do

Graduates can build, test and publish a production-quality mobile application that works offline, handles device permissions correctly, consumes a real backend and survives review by an app store.

Build multi-screen interfaces that adapt across device sizes, orientations and platform conventions
Structure navigation, including nested stacks, tabs, deep links and state restoration
Choose and apply a state management approach, and justify the choice
Persist data locally and implement an offline-first synchronisation strategy
Consume REST APIs with correct handling of loading, error, empty and retry states
Implement authentication and store credentials in platform-secure storage
Use device capabilities including camera, location, storage, biometrics and push notifications, with correct permission handling
Diagnose performance problems, including dropped frames, excessive rebuilds and memory growth
Write unit, widget or component, and end-to-end tests, and run them in CI
Build signed release artifacts and submit to the Play Store and App Store

Framework Selection

The course is framework-agnostic by design. Each cohort runs on a single framework announced at enrolment, chosen from Flutter with Dart, React Native with TypeScript, native Android with Kotlin, or native iOS with Swift. The selection is made per cohort based on instructor availability and current local hiring demand.

The module structure below is identical across frameworks. What changes is the syntax, the widget or view library, and the package ecosystem. What does not change is the substance of the course: platform behaviour, lifecycle, layout systems, navigation, state management, persistence, networking, permissions, offline handling, testing, release and store submission. These transfer between frameworks, and the course teaches them as the primary material so graduates can move between stacks rather than being tied to one.

Where a topic differs materially by framework, the syllabus names the concept rather than the API, and the framework-specific implementation is covered in that cohort's labs.

Who it's for

Developers moving from web or backend work into mobile
CS/IT graduates and career-switchers with programming ability
Designers who can code and want to ship their own products
Freelancers and founders building a first mobile product

Prerequisites

Working ability in at least one programming language, including functions, classes, collections and asynchronous code
Comfort with the command line and package managers
A machine capable of running the chosen toolchain, and a physical device for testing. Students targeting iOS require a Mac.

All students complete the two-session Engineering Onboarding module before Module 1.

Tools and technologies

The chosen framework and its languageThe platform SDK and emulators or simulatorsA physical test deviceA dependency managerA version control workflowA local database or key-value storeAn HTTP clientA secure storage libraryA crash and analytics platform such as Firebase Crashlytics or SentryA push notification serviceThe platform build and signing toolingGitHub ActionsA distribution channel such as TestFlight, Firebase App Distribution or an internal testing track

Target roles

Junior Mobile Application DeveloperAndroid DeveloperiOS DeveloperFlutter DeveloperReact Native DeveloperFreelance mobile developer

Course curriculum

8 modules · 8 weeks

Concepts: how mobile differs from web, covering constrained resources, interrupted sessions, unreliable networks, battery and data cost, and the fact that the operating system can terminate the application at any time; native, cross-platform and hybrid approaches and their trade-offs; Android and iOS platform conventions covering navigation patterns, back behaviour, gestures, typography and system components, and why an application that ignores them feels wrong; the application lifecycle across foreground, background, suspended and terminated states, and what must be saved before each transition; project structure and the build system; dependency management and version pinning; emulators and simulators against physical devices, and what only a physical device will reveal; debugging tools, logging and the inspector; hot reload and its limits; the device landscape in the local market, covering screen sizes, operating system version spread and low-end hardware.
Lab: set up the toolchain and run a build on both an emulator and a physical device; instrument the lifecycle callbacks and observe every transition while backgrounding, rotating, receiving a call and being terminated by the system; read a crash log and locate the fault; profile the same application on a high-end and a low-end device and record the difference.
Project: a working environment and a first running build, committed with a README covering setup steps for a new developer.

Concepts: the layout model of the chosen framework, covering how constraints, sizing and positioning are resolved; the composition tree and the cost of nesting; responsive layout across phone, tablet and foldable form factors; safe areas, notches, system bars and keyboard insets; density-independent units and asset scaling; lists and grids, including virtualisation and why a long list must never be built eagerly; scrolling behaviour, pull to refresh and pagination; forms, input types, validation and keyboard management; theming, design tokens and dark mode; typography and multi-script text, including Devanagari and Latin; animation and transitions, and when motion helps; accessibility covering screen readers, touch target size, contrast, scalable text and semantic labelling; implementing from a design handoff.
Lab: rebuild a supplied high fidelity screen to specification and have it reviewed against the design file; build a virtualised list of ten thousand items that scrolls without dropping frames; handle keyboard overlap on a long form across both platforms; audit a screen with the platform accessibility scanner and remediate the findings.
Project: the capstone's core screens built to a supplied design, responsive and accessible.

Concepts: navigation models covering stacks, tabs, drawers, modals and nested navigators; passing data between screens and returning results; the back stack and platform back behaviour; deep links and universal or app links; state restoration after process death; route guards for authenticated sections; why state management is the decision that determines whether the application remains maintainable; local against shared against persisted state; the common patterns of lifting state, observable stores, unidirectional data flow and dependency injection; separating presentation from business logic; the framework's idiomatic options compared on a single problem; avoiding unnecessary rebuilds; structuring a project by feature rather than by file type.
Lab: build the full navigation graph including nested tabs and a modal flow; implement a deep link that opens a specific record from outside the application; kill the process from the system and restore the user to the same screen and state; implement the same feature using two state management approaches from the framework's ecosystem and write a comparison covering boilerplate, testability and rebuild behaviour.
Project: Mini-project 1: a multi-screen application with complete navigation, deep linking, state restoration and a documented state management decision.

Concepts: consuming REST APIs, covering request construction, headers, serialisation, typed models and error mapping; treating loading, error, empty and success as first-class interface states; timeouts, retries with backoff and cancellation of in-flight requests when a screen is dismissed; pagination and infinite scroll; image loading, caching and memory pressure; local persistence, covering key-value storage for preferences, a local database for structured data, and the file system for documents and media; database schema and migrations on device; caching strategy and invalidation; offline-first design covering the local store as the source of truth, optimistic updates, a write queue, background synchronisation and conflict resolution; detecting connectivity and degrading gracefully; data cost awareness on metered connections; WebSocket and real-time updates.
Lab: build a paginated list backed by a local database that renders from cache before the network responds; implement an optimistic create that queues while offline and syncs when connectivity returns; force a conflict between a local and a remote edit and implement a resolution rule; run the application in airplane mode from a cold start and confirm every screen behaves correctly; write a schema migration and verify existing user data survives it.
Project: the capstone's data layer with offline support and a documented synchronisation strategy.

Concepts: the permission model on both platforms, covering request timing, rationale, denial, permanent denial and the route to system settings; camera and gallery access, image capture, compression and upload; location covering foreground and background access, accuracy levels, battery cost and the stricter review scrutiny it attracts; maps and geocoding; file access and sharing; contacts, calendar and sensors; biometric authentication; push notifications covering token registration, foreground and background handling, notification tapping and routing, channels and categories, and permission on both platforms; local and scheduled notifications; background execution limits and what the operating system permits in practice; deep integration through share sheets, widgets and app shortcuts; platform channels or native modules for capability the framework does not expose; third-party SDK integration including payments and analytics.
Lab: implement camera capture with compression and upload, handling every permission outcome including permanent denial; implement location with a clear rationale screen and a graceful path when the user declines; wire push notifications end to end from a server trigger to a specific screen, tested on a physical device in foreground, background and terminated states; write one platform channel or native module to access a capability not available in the framework.
Project: Mini-project 2: the capstone integrates camera, location or notifications with complete permission handling.

Concepts: authentication flows on mobile, covering email and password, one-time passcode, social sign-in and biometric unlock; token storage in the platform keychain or keystore rather than in plain preferences; token refresh and silent re-authentication; session expiry and forced logout; mobile security covering insecure local storage, exposed API keys in the binary, certificate handling, reverse engineering and code obfuscation, root and jailbreak detection, clipboard and screenshot exposure, and the OWASP Mobile Top 10; privacy requirements including the data safety declaration on Play and the privacy nutrition label on the App Store, plus consent for tracking; performance covering the frame budget and what causes dropped frames, unnecessary rebuilds and layout thrash, image and memory profiling, application size reduction, cold start time, battery and network profiling; profiling tools on each platform; crash reporting, symbolication and triage; analytics and event instrumentation.
Lab: implement the full authentication lifecycle with tokens in secure storage and biometric unlock; extract a release build and attempt to recover an embedded secret from it, then remediate; profile a deliberately slow screen and reduce its frame time to target; reduce application size and cold start time and report both figures; integrate crash reporting, ship a deliberate crash and triage it from the dashboard.
Project: the capstone is authenticated, security-reviewed and profiled.

Concepts: the testing pyramid applied to mobile; unit tests for business logic; widget or component tests for interface behaviour; integration and end-to-end tests driving a real build on a device or emulator; test doubles for network and platform services; golden or snapshot testing and its maintenance cost; flakiness in device tests and its root causes; manual test matrices across operating system versions and screen sizes; build and release covering build variants and flavours for development, staging and production, environment configuration, code signing and provisioning, keystore and certificate management, and versioning and build numbers; CI/CD covering automated builds on pull request, running tests on hosted emulators, and distributing builds to testers; beta distribution through TestFlight, an internal testing track or a distribution service; store submission covering listing assets, screenshots, descriptions, age rating, data declarations, the review process and the common rejection reasons; staged rollout and forced update strategy; over-the-air updates where the framework and store policy permit; post-release monitoring and responding to reviews.
Lab: build the test suite covering business logic, three interface components and two end-to-end journeys; configure build flavours with separate configuration and application identifiers; set up the pipeline to build, test and distribute to testers on every merge; produce a signed release artifact for both platforms; prepare a complete store listing and submit to an internal or beta track; ship an update and roll it out in stages.
Project: the capstone is tested, pipelined and distributed to real testers.

Concepts: Agile practice on a mobile team, covering backlog, acceptance criteria and the definition of done for a feature that must work on two platforms; working with designers through handoff and design QA; working with a backend team, covering API contracts, versioning and the fact that old application versions remain in the field indefinitely; backward compatibility and deprecation; code review; documentation covering README, architecture decision records, release runbook and an onboarding guide; release cadence and hotfix procedure; handling a bad release; the mobile developer's first ninety days.
Lab: a two-day sprint on a shared client backlog with full ceremonies; each student reviews two classmates' pull requests against a rubric; negotiate an API contract change with a classmate acting as the backend developer and handle the older client version; write the release runbook and have a classmate execute it.

Capstone project

A complete mobile application built individually across weeks three to eight against a written client brief. Options include a field data collection application for an organisation working offline in rural areas, a delivery or dispatch application with location tracking, a clinic appointment and records application, or a marketplace listing application with media upload.

Requirements

Multi-screen application with complete navigation, deep linking and state restoration
Responsive layouts respecting platform conventions and safe areas
Documented state management approach with the decision justified
Real backend consumption with loading, error, empty and retry states handled everywhere
Local persistence with a schema migration and offline-first behaviour, including a write queue and conflict resolution
Authentication with tokens in platform-secure storage
At least two device capabilities from camera, location, notifications, biometrics or file access, with complete permission handling
Accessibility pass with screen reader support and adequate touch targets
Crash reporting and basic analytics integrated
Unit, component and end-to-end tests green in CI
Build flavours for development and production, with a signed release artifact for each target platform
CI pipeline building, testing and distributing to testers
Distributed to at least five real testers with collected feedback and at least one issue fixed as a result
A complete store listing, including screenshots, description and data declarations, submitted to an internal or beta track
README covering architecture, setup, state management decision, offline strategy, trade-offs and known limitations
Complete incremental pull request history

Assessment

25%Weekly labs and mini-projects

20%Code review participation

35%Capstone

10%Real-device verification, assessed by the instructor on a physical device

10%Demo Day presentation and technical questioning

Real-device verification is assessed separately because an application that runs only on an emulator has not been tested. Marks cover cold start behaviour, offline behaviour, permission denial paths, interruption by a call or notification, and behaviour on a low-end device.

Out of scope

Game development and game engines
Augmented and virtual reality
Wearable and television platforms
Backend development beyond consuming an API, which is covered in Python Backend Development and Full-Stack Web Development
On-device machine learning beyond integrating a supplied model