Mobile apps

The first question about a mobile app is usually whether you need one. It is worth asking properly, because the honest answer is often no — and a studio that never says so is not advising you, it is selling to you.

Do you actually need an app?

An app earns its place when it needs something the browser cannot give you: working offline, push notifications people will actually allow, camera or sensor access, background activity, or a home-screen habit you have evidence people want.

If what you need is a good mobile experience, that is a responsive website, and it will cost less, ship sooner, be findable in search, and never wait on an App Store review. A surprising number of app briefs are website briefs that have been sitting in a drawer too long.

We will tell you which one you have. Sometimes the answer is a fast mobile web product now and an app in eighteen months once you know what people do with it.

What we build

Cross-platform, usually. React Native with Expo covers the large majority of products properly, and one codebase for two platforms is a real budget difference rather than a compromise. The motion and gesture work is where cross-platform apps usually feel cheap, and it is precisely where we spend attention.

Native where it is warranted. Swift or Kotlin when the product leans hard on platform capability — heavy media, tight hardware integration, background work that has to behave — or when performance requirements make the tradeoff obvious.

The parts nobody demos. Offline-first data and sync, which is most of the real engineering in a mobile product. Auth and session handling. Deep links. Push. Crash reporting and release channels. An app that is beautiful and loses a user’s work is not a good app.

Design for the thumb

Mobile design is not desktop design at a smaller width. Reachability, gesture conflicts, the keyboard covering the field someone is typing into, what happens on a 5-inch screen and on a tablet, one-handed use on a bus.

Motion matters more here than anywhere, because it is doing navigational work rather than decoration — telling you where a screen came from and where it went. It also has to survive being seen fifty times a day, which is a much harder test than a marketing site’s once. The three questions we apply are in motion that earns its place, and they are stricter on mobile than on the web.

Getting it into the stores

Launch is a project of its own, and it is the part most first-time app owners under-budget.

Developer accounts, certificates and provisioning. Store listings, screenshots and copy — which are search surfaces in their own right, and get treated as an afterthought roughly always. Privacy labels and data disclosures, which are now enforced and will get you rejected. Review, which takes as long as it takes.

Then TestFlight and internal tracks, so the next release does not go straight to everyone. We set up the pipeline as part of the build, because the second release is where a badly-set-up project starts hurting.

After launch

An app is never finished in the way a marketing site can be. The OSes ship a major version every year and deprecate things; libraries age; a certificate expires at an inconvenient moment. Budget something ongoing even if it is small — an unmaintained app does not stay still, it degrades until one day it will not build.

We also instrument from day one. Which screens people reach, where they stop, what crashes and how often. Shipping a mobile product with no analytics means your only feedback is a one-star review.

What it costs

Two platforms is not two projects if it is cross-platform, but it is never exactly one either — store review, device testing and platform quirks are real. The biggest cost drivers are the same as anywhere: how many kinds of user there are, how much of it talks to systems you do not control, and how much has to work with no network. The full reasoning is in what a web app actually costs to build.

When we are the wrong choice

If you need a very large native team for a product with millions of users and platform-specific ambitions on both sides, you want a bigger specialist shop. If you want the cheapest possible wrapper around your existing website, that is not a product, and the stores increasingly reject it anyway.

We are worth it when the app has a real reason to exist and someone needs to own both how it looks and how it behaves.

Tell us what you have in mind — including if you are not sure it should be an app.