Approach
We choose technology after the specification, not before. Swift and Kotlin suit products that lean on device hardware or platform-specific design; Flutter or React Native suit products that need parity across platforms on a shared budget. The decision, with its trade-offs, is written down for you.
Every screen is specified across its states: loading, empty, partial, error, offline and success. Those states are then tested at large text sizes and with screen readers.
Device coverage matrix
Filter the checks we typically run by platform. Your actual matrix is agreed during scoping.
| Check | Platform | Method |
|---|---|---|
| Dynamic / large text sizes | Both | Manual on device |
| VoiceOver navigation of core journey | iOS | Manual on device |
| TalkBack navigation of core journey | Android | Manual on device |
| Offline and slow-network behaviour | Both | Network conditioning |
| Small-screen and foldable layouts | Android | Device and emulator |
| Notch, Dynamic Island and safe areas | iOS | Device and simulator |
| Permission denial paths | Both | Manual scripted |
| Unit and widget tests in pipeline | Both | Automated |
| Back gesture and system navigation | Android | Manual on device |
Deliverables
- Source repository in your organisation's account
- State inventory and acceptance criteria
- Automated build pipeline with signed test builds
- Device test record for each increment
- Accessibility findings and resolutions
- Store readiness checklist