Mobile Applications

A mobile app makes sense when people use a product often, on the move, or need phone features: notifications, the camera, location or working offline. We build cross-platform apps for iOS and Android that share one codebase and connect to the systems your company already uses.

01Native or cross-platform

The first decision is about technology. A native app is built separately for iOS (Swift) and Android (Kotlin). It gives full access to the operating system, but it means two codebases to write and maintain. A cross-platform approach lets you write most of the app once and release it on both platforms.

We mostly work with two cross-platform technologies:

• React Native renders native interface components, with the logic written in TypeScript. It works well for apps that should look and feel native.
• Capacitor runs a web application inside a native shell with access to device features. It is a good choice when a company already has a web application and wants to reuse its code.

For most business apps, a cross-platform approach is enough. We consider a native app when the project needs deep access to operating system features or very demanding graphics. We compare both approaches in more detail in our article on native or hybrid development, and write about Capacitor itself in a separate post.

02What a project looks like

We work in seven stages: discovery, strategy, design, development, testing, deployment and scaling. We start with the users: who uses the app, in what situations, and what they need on their phone and what they do not. A mobile app should not be a copy of the whole system. It works better when it focuses on a few tasks people do often and quickly.

Then we design the interface for a small screen, one-thumb use and divided attention. We test prototypes on real devices before development starts. Development is iterative, and new builds are shared for testing through TestFlight and Google Play testing tracks, so the team on the client side can try them on their own phones.

03Offline, sync and backend

Apps used in the field have to work without a signal too. We design them offline-first: data is stored locally on the device and synchronised with the server once the connection is back. The hardest part is conflicts, when the same data was changed in two places, so we agree the rules for resolving them at the design stage.

A mobile app almost always needs a backend: user accounts, data, push notifications and integrations with other systems. If the company already has a web application with a good API, the mobile app can use it. If not, we build the backend together with the app, just as we do for custom web applications.

04Release and further development

We prepare the app for release in the App Store and Google Play: descriptions, screenshots, privacy settings and the requirements of both stores. We take it through the review process and respond to reviewers' feedback.

After release we handle updates, compatibility with new iOS and Android versions, crash monitoring and new features. It is worth planning for this in the budget from the start, because the stores change their requirements regularly. We write about splitting costs between a first version and a full product in our article on the cost of building a mobile app.

Want to find out whether your company needs a mobile app, and which technology to build it with? Tell us who will use it and for what, and we will suggest where to start.