Mobile apps: iOS and Android
Mobile app development
A mobile app is needed when a solution genuinely requires device capabilities, or when work happens without a stable connection. Otherwise a well-built mobile website is often enough. So the first decision is not design but platform: one cross-platform codebase, separate native apps, or no app at all. That choice determines the testing scope, the store submission process and the cost of ongoing support.
Discuss an app ideaIn short: what to decide first
Three answers are worth having before development starts. Which device capabilities are required — camera, background location, push notifications, Bluetooth, on-device files, or none. How the app must behave without a connection, and what happens when the connection returns. And who owns the App Store and Google Play accounts and the signing keys. If no feature actually needs device capabilities, it is worth starting with a mobile website and deferring the app.
When an app is the right choice
- The solution needs device capabilities: camera, background location, push notifications, Bluetooth or reading files on the device.
- Work happens where connectivity is unreliable — data must be stored locally and synchronised later without duplication.
- The app is used daily and repeatedly, so an icon on the home screen genuinely shortens the path to the work.
- Distribution through the stores is required, or internal distribution to staff with managed versions.
When something simpler is enough
- Users only read information or complete a form – a mobile-friendly website costs less and has no store review cycle.
- You need an internal tool for the team with no device capabilities – a browser web app reaches every device with one update.
- A platform you already use has its own app with the features you need – configuring it is then cheaper than building your own.
Choosing a platform
The comparison below helps choose a direction based on the capabilities you need rather than on a technology name. It is an illustrative comparison for preparing a conversation: the actual choice depends on your feature list, the devices you support and your support plan. The cost column lists drivers, not prices.
| Approach | When it fits | Limits and cost drivers |
|---|---|---|
| Mobile website or PWA | Information, forms, an account – no device capabilities needed. | No presence in the stores; notifications and offline behaviour are limited on iOS. |
| One cross-platform codebase | Both platforms need the same features and a single update cycle. | Some integrations still require native work; both platforms must be tested. |
| Separate native apps | Deep device integration or performance-sensitive work is required. | Two codebases and two release cycles – more development and support scope. |
| Cross-platform with native modules | Most features are shared but one part needs a native solution. | Both skill sets are needed; releases must be coordinated across the parts. |
| Modernising an existing app | The app works but is no longer updated or no longer meets store requirements. | An audit comes first; cost depends on the state of the existing codebase. |
How the work runs
- 01
Deciding features and platform
We list which device capabilities are required, how the app behaves without a connection, and which devices and operating-system versions are supported. Only then do we choose the platform, because that decision sets the testing and support scope.
- 02
A first version for testers
We build a working version and distribute it through TestFlight or Google Play internal testing. Real users try it on their own devices, which is how you find what fails in the field rather than in the office.
- 03
Store submission
We prepare listings, icons, screenshots, privacy answers and age ratings, then submit for review. Review timelines and decisions belong to Apple and Google, so we plan for the possibility of rejection and resubmission.
- 04
Updates and handover
After launch, operating-system changes and store requirements have to be tracked. We hand over the code, build environments and documentation; the accounts and signing keys stay under your control.
What drives cost and duration
- Whether one platform or both are built, and how much their features differ.
- The complexity of offline behaviour and synchronisation, especially resolving data conflicts.
- The list of supported devices and operating-system versions – it determines the testing scope.
- Store accounts, privacy declarations and any resubmissions after review.
- Support after launch: operating-system updates and library version changes.
Worth considering before a conversation
- 01Which features genuinely require device capabilities, and which would work in a browser?
- 02How must the app behave without a connection, and what happens when it returns?
- 03Who owns, or will own, the App Store and Google Play accounts?
- 04Which devices and operating-system versions need to be supported?
- 05Who will handle updates after launch when operating-system requirements change?
Let us discuss the scope of an app
Describing the work the app must do, and where connectivity is missing, is enough. Do not send credentials, signing keys or real customer data — an anonymised example is a suitable starting point.