Mobile Development Technical Specification
A specification without technical details is a document for a lawyer, not a developer. "The app should work fast and be convenient" is not a requirement. "The order list should load in no more than 2 seconds on 4G with 100 simultaneous users" is a requirement you can build design decisions on.
What distinguishes good mobile development specs
A good spec solves three problems simultaneously: developer effort estimation, acceptance testing checkpoint, and QA test plan basis. If the document doesn't allow at least one of these — it's incomplete.
Functional requirements in mobile context — this is not "user can log in". It's:
- Authentication via email + password, Google Sign-In (
google_sign_in/ GoogleSignIn SDK), Apple Sign-In (required for iOS if other social networks exist — App Store Guideline 4.8) - Session storage: JWT in
flutter_secure_storage/ iOS Keychain / Android Keystore, access token lifetime — 15 minutes, refresh token — 30 days - Behavior on token expiration: silent refresh via interceptor, don't throw user to login screen on every app launch
This level of detail eliminates dozens of "how should this work" questions during development.
Non-functional requirements (NFR) — often overlooked
NFR for mobile application:
| Parameter | Example requirement |
|---|---|
| Performance | App launch (cold start) — no more than 3 seconds on iPhone XR and Pixel 5 |
| Network timeout | HTTP requests: connect timeout 10s, receive timeout 30s |
| Offline | Last 50 records accessible without internet |
| App size | IPA no more than 50 MB before resource loading (App Thinning) |
| Supported versions | iOS 15+, Android 8.0+ (API 26+) |
| Localization | ru, en — mandatory; de, fr — next version |
| Accessibility | Dynamic Type support (iOS) and font scale (Android) |
Without NFR, the developer will do "whatever's convenient", not "what's needed".
Screens and User Stories
Spec structure by screens: each screen is described via User Story (As [role], I want [action], so [goal]) + wireframe or Figma link + behavior details. Not "profile screen", but:
"Edit Profile" screen: user can change name (required, 2–50 characters), avatar (gallery or camera selection, 1:1 crop, maximum 5 MB), phone number (SMS OTP validation). Changes save on "Save" button press. Button inactive if no changes. Network error — toast with error text, changes not lost.
API contracts and dependencies
Spec must fix external dependencies:
- List of third-party APIs and SDKs (Firebase, Stripe, Google Maps, etc.) with specific versions or minimum requirements
- Data exchange format with backend: REST / GraphQL / WebSocket, authorization scheme (Bearer JWT, API Key, OAuth 2.0)
- If backend develops in parallel — minimal OpenAPI 3.0 contract as the mobile team reference
What not to write in spec
Implementation approach is developer responsibility, not customer's. Spec describes what should work, not how. "Use Flutter" — acceptable. "Use BLoC for state management" — that's not spec, those are technical decisions discussed separately.
Process and timeline
Work on spec:
- Customer interview — gather business requirements, user roles, functionality priorities
- Competitor analysis — if product in existing niche, study UX patterns of leaders
- Document writing — functional requirements, NFR, screens, API dependencies
- Agreement — iterations with customer, clarification of edge cases
Ready spec: 2–3 days for app up to 20 screens. For complex products (marketplace, fintech) — 4–6 days. Cost calculated individually.