5.7 Mobile application development

Overview and motivation

Mobile application development is the discipline of building software for phones and tablets. For many people, a phone is now the primary or only computer they own. That makes the mobile app the front door to your service, and often the surface where users judge your whole organisation.

Mobile is a distinct engineering environment, not a small version of the web or desktop. The device runs in a pocket, on battery, over connections that come and go. Screens are small. The operating system controls what your app may do. Two dominant platforms exist (iOS from Apple and Android from Google), each with its own languages, design rules, and store. You cannot simply ship an update whenever you like, because a store reviews it first, and users choose when to install it. This chapter builds on frontend engineering (chapter 5.6), UX foundations (chapter 5.1), and accessibility (chapter 5.3), and it leans on application security (chapter 4.2) and CI/CD and delivery (chapter 8.1).

Enterprise and government relevance is high. Enterprises ship customer apps and internal apps for their own workforce, often managed through mobile device management (MDM: central software that configures and secures company devices). Governments build citizen-facing apps for benefits, health, identity, and payments, and they must serve everyone, including people on old devices and slow connections, under accessibility laws. In both settings, mobile is a serious, long-lived commitment, so treat it with the same rigour you give any other production system.

Key principles

Design for the device: small screen, battery, and a network that comes and goes.
Assume intermittent connectivity; work offline first and sync when you can.
Respect each platform’s design and interaction conventions.
You do not control release timing; the store and the user do.
Fragmentation is normal; support a real range of devices and OS versions.
Store data securely on the device, because devices get lost and stolen.
Accessibility is a requirement, not a finishing touch.
Choose your build approach for the whole life of the app, not just launch day.

Recommendations

Choose the build approach deliberately

There are three broad approaches, and each fits different needs.

Native development means writing separately for each platform using its own tools: Swift for iOS, Kotlin for Android. You get the best performance, the fullest access to device features, and the most faithful platform feel, at the cost of building and maintaining two codebases.

Cross-platform frameworks let one codebase target both platforms. React Native uses JavaScript and renders real native components. Flutter uses the Dart language and draws its own widgets. These reduce duplicated effort and can speed delivery, but they add a dependency on the framework’s health and can lag behind the newest platform features.

A progressive web app (PWA: a website that can be installed and can work offline) needs no store and updates instantly, but it has limited access to some device features and a weaker presence on the home screen.

Choose based on the required device features, the performance profile, the maintenance horizon, the skills you can hire, and the reach you need. A high-performance consumer app may justify native. A content-and-forms app with a small team may fit cross-platform or a PWA well.

Follow the platform design guidelines

Each platform has published, detailed conventions. Apple provides the Human Interface Guidelines, and Google provides Material Design. These cover navigation, gestures, typography, spacing, and system behaviours. Following them makes your app feel familiar, which lowers the effort users spend learning it. Fighting them makes an app feel foreign and awkward. A cross-platform codebase still needs to honour per-platform conventions where they differ, rather than forcing one platform’s look onto the other.

Design for mobile constraints

Build offline-first: let core tasks work without a connection, store changes locally, and sync when the network returns. Handle conflicts thoughtfully when the same data changes in two places. Be frugal with battery and data: batch network calls, avoid constant location or background work, compress payloads, and respect the user’s data-saver settings. Plan for fragmentation, the wide spread of screen sizes, device power, and OS versions. Pick a support range based on real usage data, and test on modest hardware, not just flagships. Design for small screens with clear hierarchy, large touch targets, and content that adapts to different sizes and orientations.

Plan distribution, versioning, and updates

Publishing goes through the Apple App Store and Google Play, each with review processes and policies that can delay or reject a release. Build review time into your schedule, and read the policies early. Because users choose when to update, you will always have many versions in the field at once. Keep your app backward compatible with older clients, and version your APIs (chapter 2.3) so an old app keeps working. Provide a way to require an update when you must, for example a forced-update prompt when a version is unsafe or unsupported, and use it sparingly. Enterprises can also distribute internal apps through MDM or private channels rather than the public stores.

Use push notifications and deep links with care

Push notifications let you reach users when your app is closed. Use them for genuine value, respect the user’s consent and platform permissions, and avoid noise, because people disable notifications from apps that overreach. Deep links send a user straight to a specific screen from a link or a notification. Configure them so a link opens the right place in the app, and falls back to the web gracefully when the app is not installed.

Secure the app and its data

Treat the device as untrusted and possibly lost. Store sensitive data in the platform’s secure storage (the iOS Keychain or the Android Keystore), never in plain files. Offer biometric authentication (fingerprint or face) to unlock sensitive actions, backed by a passcode. Consider certificate pinning (checking that the server presents an expected certificate) for high-value connections, and plan for rotating those certificates. Minimise what you store on the device, protect secrets, and follow the broader guidance in application security (chapter 4.2).

Build a real testing and delivery pipeline

Test on real devices, not just emulators and simulators, because hardware, sensors, and performance differ. Use a device lab or a cloud device farm to cover a representative spread of models and OS versions. Automate builds, tests, signing, and store submission through continuous integration and delivery (chapter 8.1), including beta distribution to testers before public release. Managing signing keys and store credentials safely is part of this pipeline.

Make accessibility a requirement

Support each platform’s accessibility features: screen readers (VoiceOver on iOS, TalkBack on Android), dynamic text sizing, sufficient colour contrast, and large touch targets. Label controls so assistive technology can describe them. Test with the actual assistive tools, not just automated checks. For government especially, accessibility is a legal mandate, and the details live in accessibility (chapter 5.3).

Trade-offs: pros and cons

Approach	Pros	Cons
Native (Swift, Kotlin)	Best performance, full device access, true platform feel	Two codebases, higher cost, more staff
React Native	One JavaScript codebase, real native components, fast iteration	Framework dependency, bridging complexity, feature lag
Flutter	One codebase, consistent UI, strong performance	Dart skills less common, larger app size, own widget model
Progressive web app	No store, instant updates, one web codebase	Limited device features, weaker presence, platform limits
Forced updates	Removes unsafe old versions quickly	Annoys users if overused; can block access
Certificate pinning	Strong protection against interception	Breaks if certificates rotate without app updates

The recurring trade-off is reach and speed of delivery versus depth and fidelity. Native gives the richest, most faithful experience but costs the most to build and maintain. Cross-platform and PWA approaches save effort and broaden reach, at some cost in platform feel or device access. For a small team shipping forms and content, sharing a codebase is often wise. For a demanding consumer app, native depth can be worth the price. Decide with the full life of the app in view, not just the launch.

Questions to discuss with your team

How long do we support old clients in the field, and is our API versioned to keep them working? Because users choose when to update, you always have many versions of the app installed at once, and a backend change that assumes everyone is current will break the long tail of older clients. Decide your backward-compatibility window, version your APIs so an old app keeps working, and keep a rarely used forced-update path for versions that are genuinely unsafe. This matters for government citizen apps and enterprise workforce apps alike, where people on old devices cannot or will not upgrade on your schedule. Bring your current version-distribution data and ask what breaks for the oldest client still in real use. If you do not know that distribution, instrument it before you ship your next breaking change.
What is our bar for sending a push notification, and who decides what is worth interrupting a user? Push notifications reach people when the app is closed, which makes them powerful and easy to abuse, and users disable notifications (or delete the app) from products that overreach. Agree on what counts as genuine value, how users control frequency and channel, and how you honour platform consent rather than nagging for permission. Without a shared bar, every team with a metric to hit will reach for a push, and the whole channel degrades into noise. Bring the last month of notifications you sent and ask which the user would have thanked you for. If most were promotional, tighten the policy before the opt-out rate does it for you.
Is our mobile delivery pipeline real, covering signing, a device farm, and beta distribution, or is release a stressful manual scramble? Mobile adds hazards the web does not have: store review can delay or reject a release, signing keys and store credentials must be handled safely, and hardware and sensors differ enough that emulators hide real problems. Automating builds, tests, signing, and store submission through CI/CD, with beta distribution to testers and a cloud device farm covering the models your users actually carry, is what turns releases from heroics into routine. Decide who owns the pipeline and the signing keys, and how store review time is built into every release plan. Bring the story of your last release and count the manual steps. Each one is a place a stressful release can go wrong under deadline.
Have we chosen native, cross-platform, or a progressive web app for the whole life of this product, or only for launch day? The build approach is the single largest lever on the cost and capability of a mobile app for years, and a choice made to ship fast can trap you: native buys the richest device access and platform feel at the price of two codebases and two skill sets, while cross-platform and PWA share code but add a framework dependency or lose access to some device features. For a large team, this decision drives hiring, the maintenance budget, and how quickly you can adopt each yearly OS release, so it deserves an explicit owner rather than a default set by whoever wrote the first prototype. Bring the required device features, the performance profile, the maintenance horizon, and the skills you can actually hire, and be honest about which platform features you would forfeit under each option. In enterprise and government settings, weigh whether the app is a long-lived commitment that must survive staff turnover and a decade of platform change, and record the decision and its rationale so a future team is not left guessing why the codebase looks the way it does.
What device and OS-version support range do our real users need, and are we testing on the hardware they actually carry rather than the phones on our desks? Fragmentation is the normal condition of mobile: users span a wide spread of screen sizes, device power, and OS versions, and an app tuned on the team’s flagships will ship sluggish or broken on the modest hardware much of your audience owns. Setting a support range is a trade-off between reach and effort, because every older model and OS version you promise to support widens the test matrix and the maintenance burden, so the range must come from real usage data rather than assumption. Bring your device and OS-version distribution, the models a cloud device farm or lab currently covers, and the performance you have measured on low-end hardware, not just simulators. For government citizen apps this is close to non-negotiable, because you must serve everyone including people on old devices and slow connections under accessibility obligations, and for enterprise fleets you should test the exact rugged handsets staff carry rather than a generic sample.
What sensitive data lives on the device, and is each piece protected against a phone that is lost, stolen, or in someone else’s hands? A mobile device travels in a pocket and gets lost or stolen, so any data or secret stored in a plain file is one misplaced phone away from exposure, and the blast radius grows with every user. The considerations pull against each other: caching data on the device is what makes offline-first work and keeps the app fast, yet each cached item is a liability that must sit in the platform’s secure storage (the iOS Keychain or the Android Keystore), be minimised, and ideally be gated behind biometrics or a passcode. Bring an inventory of exactly what the app persists locally, where each item is stored, what unlocks it, and whether high-value connections use certificate pinning with a workable rotation plan. In enterprise settings, tie this to mobile device management policy and remote wipe, and in government settings treat on-device personal data as a privacy and legal exposure that must be justified, documented, and defensible under audit.

Sector lens

Startup. With a tiny team and little runway, you rarely can afford two native codebases or two sets of skills, so a cross-platform framework or even a PWA that reaches both stores from one codebase usually wins. Ship offline-first for the one core task that matters, keep any token in secure storage rather than a plain file, and build store review time into every release so a rejection does not blow a launch date. Skip forced updates, certificate pinning, and a device farm until real usage justifies them.

Small business. With no dedicated mobile specialist and a tight budget, lean hard toward buy over build: a no-code app builder, a white-label app from your point-of-sale or booking vendor, or a well-made PWA off your existing website often beats a bespoke app you cannot maintain. If you do commission an app, own the signing keys and store accounts yourself so a contractor cannot hold your presence hostage, and insist on accessibility and secure on-device storage in the contract. Keep the scope to the one or two tasks customers actually do on a phone.

Enterprise. At scale, the app is a long-lived commitment across many teams, so standardise the build approach, the secure-storage pattern, the CI/CD pipeline, and the API-versioning policy rather than letting each product reinvent them. Internal workforce apps usually flow through mobile device management for installation, configuration, remote wipe, and policy, while customer apps need a device farm covering real usage and audited accessibility and security. Govern signing keys, store credentials, and release timing centrally so a breaking backend change never strands the long tail of older clients.

Government. Procurement rules, transparency, and public accountability shape every choice. You must serve everyone, including people on old devices and slow connections, so accessibility is a legal mandate verified with real assistive tools, and a wide device support range is close to non-negotiable. Favour approaches and contracts that avoid vendor lock-in, keep data portable, and let the public inspect what the app does with their data, and treat on-device personal data as an exposure you must justify and document under audit.

Examples

Startup. A three-person startup building a habit-tracking app had to reach both iOS and Android but could not afford two native codebases or two sets of skills. They chose a cross-platform framework so one small team could ship to both stores, and designed offline-first from the start so a user could log a habit on the subway with no signal and sync later. They kept the login token in the platform secure storage rather than a plain file, built store review time into every release plan, and tested on a couple of cheap older phones alongside their own, which caught sluggish performance they would otherwise have shipped.

Enterprise. A logistics company built an internal app for its drivers and warehouse staff. Because warehouses and delivery routes have patchy signal, the team chose an offline-first design: scans and status updates save locally and sync when a connection returns. They used a cross-platform framework to serve one codebase to both platforms with a small team. The app is distributed through mobile device management rather than the public stores, so IT controls installation, configuration, and security policy on company devices. Sensitive credentials live in the platform secure storage, and biometrics unlock the app. A cloud device farm tests a representative spread of the rugged handsets staff actually carry.

Government. A national agency shipped a citizen-facing app for identity and benefits. Accessibility was a hard requirement from day one: full screen reader support, dynamic text sizing, and strong contrast, tested with real assistive tools to meet the law. Because citizens use a huge range of devices, the team supported a wide band of older models and slow connections, and kept core tasks working offline. Sensitive data stays in secure device storage, biometrics protect access, and high-value connections use certificate pinning with a planned rotation process. API versioning keeps older installed apps working, and a rarely used forced-update path exists for security fixes. Store review timelines are built into every release plan.

Business case: motivations, ROI, and TCO

Mobile is where many users meet your service, so the app affects adoption, satisfaction, and completion of the tasks that matter to your organisation. A fast, reliable, well-designed app increases usage and reduces support load. For enterprises, an internal mobile app can make a mobile workforce measurably more productive and cut paperwork. For governments, a usable citizen app widens access and reduces call-centre and in-person demand.

On total cost of ownership (TCO), the choice of approach is the biggest lever. Native means paying for two codebases and two skill sets over the app’s whole life. Cross-platform trades some of that for a dependency you must keep current. Beyond code, budget for store fees and review cycles, a device testing lab or cloud farm, ongoing OS-version support as platforms release yearly, and the security work that mobile demands. The cost of underinvesting shows up as crashes on unsupported devices, security incidents from unprotected on-device data, rejected or delayed releases, and users who abandon a slow or awkward app.

To make the case to leadership, connect the app to concrete outcomes: task completion, retention, workforce productivity, or reduced support cost. Price the full approach decision across the app’s life, not just the first release, and name the risks (security, accessibility law, store rejection) that a serious mobile practice reduces.

Anti-patterns and pitfalls

Treating mobile as a shrunken website: ignoring touch, gestures, and platform conventions.
Assuming a perfect network: no offline handling, so the app breaks the moment signal drops.
Testing only on the latest flagship: hiding poor performance on the devices real users carry.
Storing secrets in plain files: sensitive data exposed when a device is lost or stolen.
Notification overload: too many pushes, so users mute or delete the app.
Ignoring store review time: release plans that assume instant publishing and then slip.
No forced-update path: unsafe old versions live on with no way to retire them.
Draining battery and data: constant background work and chatty networking that users notice.
Accessibility as an afterthought: excluding users and, for government, breaking the law.
One codebase forced to look identical everywhere: an app that feels foreign on both platforms.

Maturity model

Level 1: Initiate. Mobile is ad hoc and reactive. The app is built like a website, tested on the team’s own phones, and often breaks offline. Little thought goes to secure storage, accessibility, or store review timelines. Releases are a stressful manual scramble, and no one owns the build approach or the signing keys.

Level 2: Develop. Basic practices appear, but they are inconsistent across teams and products. A build approach is chosen for a given app, it follows platform basics and is tested on a few real devices, and some offline handling and secure storage exist. Builds are partly automated and someone owns store submissions, yet another team’s app may still do all of this differently or not at all.

Level 3: Standardise. Good practice is documented and enforced org-wide. Offline-first is the default, a documented device support range is tested on a device lab or cloud farm, and platform design guidelines and accessibility are followed and verified with real assistive tools. Secure storage, biometrics, and API versioning are standard, CI/CD automates builds, tests, signing, and beta distribution, and store review time is planned into every release.

Level 4: Manage. Mobile quality is measured and controlled against baselines. Crashes, cold-start and screen-render performance, battery and data use, and task-completion rates are captured continuously from real devices and tracked against targets, with per-model and per-OS-version breakdowns so a regression on low-end hardware is caught, not shipped. Accessibility and security are audited rather than assumed, notification opt-out and update-adoption rates are monitored, and the support range and build approach are reviewed on this evidence. Kill or fix decisions for a release rest on the metrics, not on how the app felt on the lead’s phone.

Level 5: Orchestrate. Mobile is continuously improved and integrated across the organisation, and it adapts as the device landscape shifts. Certificate rotation, forced-update paths, and rollback are routine, the support range and build approach are re-scoped on evidence as platforms release yearly, and the whole spread of users and devices is treated as first-class. Mobile planning is joined up with security, accessibility, API, and delivery practice, so an OS change, a new device tier, or a policy shift is absorbed as routine work rather than an emergency.

Ideas for discussion

How do you decide between native, cross-platform, and a progressive web app for a given product?
What device and OS-version support range fits your real user data, and how do you keep it current?
Where is offline-first essential in your app, and how will you handle sync conflicts?
When is a forced update justified, and how do you avoid blocking users unfairly?
How will you test on real devices at a scale that reflects your users?
What sensitive data lives on the device, and how is each piece protected?
How do you honour each platform’s conventions from a shared codebase?

Key takeaways

Choose the build approach (native, cross-platform, or PWA) for the whole life of the app.
Follow the platform design guidelines so the app feels familiar and lowers user effort.
Design for mobile constraints: offline-first, frugal battery and data, fragmentation, small screens.
You do not control release timing; plan for store review, versioning, and forced updates.
Use push notifications and deep links with restraint and consent.
Secure on-device data with secure storage, biometrics, and, where warranted, certificate pinning.
Test on real devices and automate the mobile pipeline through CI/CD.
Make accessibility a requirement, which for government is a legal mandate.

References and further reading

Apple, Human Interface Guidelines
Google, Material Design guidelines
Apple, App Store Review Guidelines
Google, Google Play developer policies and Android developer documentation
OWASP, Mobile Application Security Verification Standard (MASVS) and Mobile Security Testing Guide
React Native project documentation
Flutter project documentation
Google, web.dev guidance on progressive web apps
U.S. Section 508 and WCAG (Web Content Accessibility Guidelines) references for mobile accessibility
NIST, Guidelines on mobile device security and management