Specification
Mobile build specification
| Platforms | iOS and Android. Cross-platform (Flutter or React Native) by default; native Swift or Kotlin where justified. |
|---|---|
| Architecture | Clear separation between interface, state and data access, documented in the repository. |
| Data | Versioned API contracts, local caching with explicit sync rules, safe handling of conflicts. |
| Security | Secure storage for tokens, certificate pinning where appropriate, no secrets in the app bundle. |
| Testing | Unit and integration tests, plus manual testing on an agreed device list. |
| Releases | Automated build pipeline to TestFlight and Play testing tracks. |
| Handover | Repository, signing credentials in your accounts, runbooks for each release step. |
Comparison
Choosing the approach
| Best for | Most business and consumer apps |
|---|---|
| Maintenance | One codebase, one team |
| Watch for | Very new platform features may arrive later |
| Best for | Hardware-heavy or performance-critical apps |
|---|---|
| Maintenance | Two codebases |
| Watch for | Higher ongoing cost |
| Best for | Occasional use, internal tools |
|---|---|
| Maintenance | Single web deployment |
| Watch for | Limited device integration |
Questions
Common questions
Can you rebuild an unstable app?
Often the right answer is to stabilise the foundations first: API, data and release process. We assess before recommending a rewrite.
What happens when iOS or Android updates?
Under a support plan we test against beta releases and schedule any changes before the public update.