03 · Build
Mobile app development
We are a web-first studio, and we will tell you when you do not need an app. A large share of the mobile apps businesses commission would have been better as a fast, well-designed mobile web experience – cheaper to build, cheaper to run, and with no install step between you and the user.
When an app is genuinely the right answer, we build it: usually as a companion to a web platform we also build and maintain, sharing the same APIs, the same design system and the same team.
When an app is actually justified
There is a short list of reasons that hold up. If none of them applies, the honest recommendation is to invest the budget in the web product instead.
- The product needs to work offline or with unreliable connectivity – field work, logistics, warehouses, remote sites.
- It requires device capabilities the web cannot reach reliably on both platforms.
- Reliable push notification is core to the product, not a marketing preference.
- Usage is daily and habitual, where a home-screen presence changes real behaviour.
- Distribution through the app stores is a commercial requirement.
- Performance demands are beyond what a mobile browser can deliver for the interaction involved.
What we build
Companion apps
A mobile client for a web platform: the same accounts, the same data, the same API, and the subset of functionality that genuinely belongs on a phone.
Field and operations apps
Apps for people working away from a desk – inspections, deliveries, service calls, stock counts – with offline capability and synchronisation that survives a bad connection.
Cross-platform apps
One codebase across iOS and Android where the interface is largely shared, which is the majority of business applications. Lower build and maintenance cost than two native codebases.
Native apps
Platform-native builds where performance, deep OS integration or platform-specific interaction genuinely require it.
Diagram
How we approach mobile
-
Challenge the requirement first The first conversation is whether an app is the right answer at all. That is not a sales tactic – apps carry permanent costs in store compliance, OS upgrades and dual-platform testing, and those costs should be entered deliberately.
-
Scope to what belongs on a phone A mobile app is not a smaller version of the whole platform. It should do the two or three things people genuinely need in that context, done well.
-
Design for offline as a normal state Where connectivity is unreliable, offline is the default assumption. Local storage, queued operations and conflict resolution are designed in, not bolted on.
-
Share the platform, not just the brand The app runs against the same APIs and the same design tokens as the web product, so features do not diverge and fixes do not have to be made twice.
-
Plan the release lifecycle Store submission, review timelines, staged rollout, forced upgrade paths and OS version support are agreed before the first release, because they constrain everything afterwards.
What you receive
- Production apps for the agreed platforms
- Source code in your repository with a documented build process
- Store listings prepared and submitted under your developer accounts
- Crash reporting and usage analytics
- Offline behaviour and synchronisation documentation
- Release and update process documentation
- Defined maintenance arrangement covering OS and store policy changes
How this runs
Every engagement follows the same sequence, with a defined output at each stage and nothing proceeding on an assumption that has not been written down. Build work sits inside that process rather than alongside it.
Common questions
Would a progressive web app be enough for us?
Frequently, yes – and we will say so. A PWA gives installability, offline capability and push on Android without store distribution or app review, at a fraction of the cost. The main gaps are iOS push reliability, some device APIs, and store presence as a commercial requirement.
Do you maintain apps you did not build?
Case by case. We start with a technical review of the codebase, dependency health and store compliance, then give you an honest assessment of maintenance cost versus rebuild cost.
What does an app cost to keep running?
Budget for annual OS updates on both platforms, store policy changes, dependency and security updates, and device testing. It is a recurring commitment rather than a one-off build cost, and we set that expectation before you commit.
Related services
Considering a mobile app?
Tell us what it would do and who for. If a mobile web experience would serve you better, we will say that first.
Or email hello@applystudio.com – we reply within one business day.