Mobile app requirements document: a template, an example and the app store rules

A mobile app requirements document looks like any software requirements document, plus about ten questions that make all the difference: which phones, with or without a signal, which permissions to ask for, how the app gets onto devices, and how to stay within Apple's and Google's rules. Most templates online skim over exactly these questions, and they are the ones that blow budgets or get an app rejected at submission.

This guide gives you a 12-section template, the mobile-specific requirements people forget, a short worked example and a checklist to run before sending the document to developers.

What the document is for

It should do three jobs: get quotes you can compare, align your team on what the first version does and does not do, and serve as the reference for acceptance testing. The general method that applies to any application is covered in our guide on writing a software requirements document. This article focuses on what is specific to mobile.

Before writing anything, check that you really need an app people install. A web app, possibly installable as a progressive web app (PWA), covers many needs at a lower cost. Our comparison of web apps, PWAs and native apps will help you decide. If mobile is the right call, here is what to write.

The template in 12 sections

Users and journeys: describe real conditions

People use mobile apps standing up, one-handed, outdoors, between two other tasks. Spell those conditions out, because they change the design:

• an inspector wearing gloves needs large targets and choices rather than free text;
• a delivery driver needs the app to resume exactly where it was after a phone call;
• a customer who opens your app once a month needs to understand it with no help at all.

Then limit the journeys. A strong first version does three to five things very well: for instance, see today's jobs, record an inspection with photos, capture the customer's signature, send the report. Everything else can wait, as we explain in MVP development: what to build first.

Platforms and devices

State:

• the platforms: iOS, Android or both, based on your users. For an internal app, the devices the company issues usually decide;
• minimum OS versions, knowing that every older version you support adds testing;
• tablets and desktops: should the same app work in the office too?
• special hardware: rugged devices, barcode scanners, Bluetooth printers.

The technical approach (fully native, or a shared codebase such as React Native or Flutter) is the developer's call, but your constraints shape it. See React Native vs Flutter for business apps for the trade-offs.

Offline behaviour: the requirement that moves the budget

Offline support changes an estimate more than any other line, and it is the one most often left out. Be specific:

• which data must be available without a signal (today's jobs, the product catalogue, the customer history);
• which actions must work offline (data entry, photos, signatures);
• how conflicts are resolved: if two people edit the same record offline, which version wins?
• how long the app must cope without a connection: an hour in a basement, or three days in a remote area.

"Works offline" cannot be priced. "An inspector can record and photograph an inspection with no signal, and the report is sent automatically when the signal returns, with no duplicates" can be priced and tested.

Permissions: justify each one

Every device feature sits behind a permission the user can refuse. For each one (location, camera, photos, contacts, notifications, Bluetooth, microphone), write why the app needs it and what happens if the user says no. An app that crashes or locks up after a refusal is a defect, and an unexplained permission worries users and app reviewers alike.

Background location deserves extra care: both platforms restrict it more tightly, and tracking employees raises privacy and employment law questions in most countries.

Accounts, including deletion

Three requirements people forget:

• sign-in: company credentials, magic link, one-time code, biometrics, and what happens when an employee leaves;
• lost or stolen devices: remote sign-out, encrypted data on the device;
• account deletion. If users can create an account, the App Store Review Guidelines (guideline 5.1.1(v)) require account deletion to be offered within the app. Google Play requires both an in-app path and a web page to request deletion of the account and its data, with permanently private enterprise apps exempt. Both pages checked on 7 November 2026.

Distribution, app stores and developer accounts

Decide how the app reaches devices in the requirements, not at the end of the project:

Four things to write down:

• developer accounts are in your company's name, with delegated access for the developer. The fees are small; see our breakdown of mobile app development cost;
• a public app must do more than wrap a website: Apple's guideline 4.2 rejects apps that are essentially a repackaged website or lack lasting utility;
• Google requires a recent Android target version: according to the Android documentation, since 31 August 2026 new apps and updates must target Android 16 (API level 36), with private internal apps exempt. The bar moves every year, which on its own justifies a maintenance budget;
• who prepares the listings (copy, screenshots, category, privacy questionnaires) and who handles a rejection.

Personal data, SDKs and analytics

Privacy rules depend on where your users are: the GDPR in the European Union and the UK GDPR in the United Kingdom, state laws such as the California Consumer Privacy Act in the United States, and Apple's and Google's own disclosure requirements everywhere. In your requirements, ask for:

• the list of data collected, with the purpose and retention period of each item;
• the list of third-party SDKs (analytics, crash reporting, advertising) and what they collect, since they also feed Apple's privacy labels and Google Play's Data safety form;
• consent collection where it is required, before any non-essential tracking;
• where the back end and backups are hosted.

Our GDPR checklist for business applications goes further. If you sell to consumers in the EU, also check whether the European Accessibility Act applies to your app.

Maintenance and the response you expect

A mobile app is never finished: Apple and Google ship a new OS every year, and store rules keep moving. Ask bidders to price the initial build and yearly maintenance separately (OS and library updates, fixes), and specify:

• milestones: prototype, internal test build, beta, store release;
• deliverables: source code, account access, documentation, with rights defined case by case in the contract;
• total cost over three years, not just the first quote.

A worked example

Context: a building inspection firm with 20 inspectors writes reports by hand and types them up at the office; reports reach clients three to five days after the visit.

Goal: report sent to the client on the day of the inspection.

Must-have journeys: see today's inspections; fill in the checklist with photos and annotations; capture the client's signature on screen; send the PDF report.

Offline: the whole journey works without a signal for a full day, with automatic sync once back online.

Platforms: iPad and iPhone issued by the company; a web view in the office for scheduling.

Distribution: private, managed devices.

Integrations: clients and sites read from the existing job management system; finished inspections sent back to it for invoicing.

Out of scope for version 1: on-site quotes, a client-facing app, payments.

If this sounds like your situation, our article on custom field service software goes further.

Common mistakes

• "Like that famous app." It took years to build; say precisely what you like about it.
• Forgetting the admin panel. Someone has to create accounts, edit the catalogue and read reports. It is often half the project.
• Staying silent on offline use. Discovered during testing, it costs the most.
• Letting the vendor own the store accounts. You become dependent on them.
• No maintenance budget. An app that is never updated eventually stops being offered to new devices.

Checklist before you send it

1. The three to five must-have journeys are described; everything else is ranked.
2. Platforms and minimum OS versions are set.
3. Offline behaviour is described in data, actions and duration.
4. Each permission is justified, with the behaviour on refusal.
5. Account deletion is planned if users can create accounts.
6. The distribution route and the account owner are written down.
7. Collected data and third-party SDKs are listed.
8. Yearly maintenance is requested as a separate line.

See the app before you commission it

With mobile more than anything else, a screen beats a page of text: people judge an app by holding it. We build a free prototype of the main screens and present it on a video call within 5 business days, from your requirements document or from a simple conversation. Your users react to something concrete before any development starts. Here is how seeing your software before you pay for it works.