For an initial iOS app estimate, describe one user, one task and the result they need. Then add data, error states and checks. That brief gives you a way to discuss a small first version before writing a detailed technical specification.
The template and educational example below do not set a price, schedule or universal screen count.
A use case says more than a feature name
“Add a shopping list” leaves important questions open. Who maintains it? Does it need sharing? What happens offline? How are changes saved? Those answers affect the work.
Describe the route from start to result: “Someone writes a list at home, closes the app, opens it in the shop and checks off purchases.” You can then identify interface states and decide what stays outside the first version.
Copy this brief
1. User: who opens the app?
2. Situation: where and why will they need it?
3. Start: what do they have before the first action?
4. Result: what should they have at the end?
5. Actions: which steps lead to that result?
6. States: what happens with empty data or an error?
7. Data: what is saved, and on which device or server?
8. Network: which actions must work offline?
9. Accounts: are sign-in and multiple users actually needed?
10. Devices: iPhone, iPad, system versions and languages?
11. Materials: which copy, images and data are ready?
12. Services: which external systems are needed, and who controls them?
13. Limits: which features are outside the first version?
14. Acceptance: how will we check the use case on a working build?
15. Handover and release: what is delivered, and is the App Store needed?Leave unknown answers as open questions. Do not include passwords, keys or real user records. An estimate needs the purpose and shape of access, rather than its secrets.
Educational example: a local shopping list
This illustrates scope; it is not a client case study or an account of BAGGO’s original release. The following items are requirements for a fictional first version, not a report of completed work.
| Field | Answer |
|---|---|
| User | Someone who prepares their own shopping and takes the list to the shop |
| Result | Items added at home are visible in the shop; purchases can be checked off |
| Interface | A list with an empty state and a form for adding an item name |
| Actions | Add, cancel input, check, uncheck and delete an item |
| Data | A name and checked state, stored on one device |
| Offline | The main use case works without a connection |
| Outside scope | Sharing, accounts, syncing, voice, photos, recipes, loyalty cards and in-app purchases |
| Before development | Agree on devices, iOS versions, language and a way to test builds |
| Release | Estimate App Store preparation separately if it is needed |
The list and form are only part of the work. Empty states, cancellation, invalid input and reopening the app are part of the scope too.
Acceptance checks for this example
- A non-empty name creates one item.
- Cancelling an addition leaves the list unchanged.
- An empty name is not saved, and the correction is clear.
- An item can be checked and unchecked.
- Deleting removes the selected item.
- Names and checked states remain after closing and reopening the app.
- The use case works offline on an agreed device.
- Long names and larger text do not hide the main actions.
Record the build number, device and system version with the checks. A screenshot establishes the appearance of one state; persistence and offline behaviour need action-based testing.
What expands the first version
Sharing. You need to define participants, how changes are exchanged and what happens when two people edit at once.
Photos or voice. Describe permissions, cancellation, failed recognition and correction of the result.
Payments. These introduce purchase, cancellation and unavailable states, plus restoration where it applies to the product.
A server. Define the data, access, service failures and ongoing costs. An app does not automatically need a server; the use case determines that requirement.
Add each extension to the brief and estimate before starting it. Record “later” features too, so they are not mistaken for part of the original agreement.
Testing a working build
Agree on installation and who will test before development starts. One option is TestFlight, which Apple provides for testing builds and collecting feedback before public release. The exact route depends on the account and distribution method.
Write down what a particular build is ready to test. An installed app does not establish acceptance of the entire scope. Apple makes the App Store approval decision under its review guidelines.
Record the handover
- Source-code location and the revision matching the delivered build.
- Build instructions and dependencies.
- Devices, languages and system versions that were tested.
- Connected services and the people who control their accounts.
- Completed checks and remaining issues.
- Whether release preparation is included and what the account holder needs to provide.
- How corrections and new features are agreed after handover.
Projects need different combinations of services and documents. This list helps raise questions before an estimate; it does not automatically include every item in every service.
Use the completed brief to discuss small iOS app development. Even with open questions, it establishes the main use case and the limits of the first version.