The Server Side, Designed for a Phone Rather Than a Browser

Either. Where a backend already exists we prefer to keep it and add a thin mobile-facing layer in front of it, so the app gets endpoints shaped for a screen without your existing systems being rewritten. Where there is nothing yet, we build the backend alongside the app so the two are designed together rather than negotiated across a boundary. What we will not do is quietly leave your app talking to something nobody owns: whichever route we take, the deployment, the environment configuration and the credentials end up documented and in your accounts.

For a first version with fairly simple data, a managed platform such as Firebase or Supabase gets you authentication, storage, push and a database in days rather than weeks, and there is no infrastructure to run. That is a genuine advantage and we use them where they fit. They become uncomfortable when your data is strongly relational, when reporting gets complicated, when the pricing model punishes a read pattern you cannot easily change, or when procurement asks questions about data location and control. The middle route is common and works well: a managed platform for authentication, push and file storage, with your own API for the business logic that is actually yours.

That depends on a decision made at design time rather than on anything that can be added later. In an offline-first design the app keeps its own database on the device, reads every screen from that, writes changes locally first and syncs in the background, so losing signal changes nothing visible except a sync indicator. In a simpler design the app caches recent data so it can still show something, but new work needs a connection. Offline-first costs more to build and is the right answer whenever people use the app somewhere with unreliable coverage or would lose real work if a request failed.

No, and any design that assumes otherwise will eventually cost you. Both Apple and Google describe their push services as best effort. Messages can be dropped when a device has been offline for a long time, delayed by power-saving behaviour, silently discarded when the user has turned the category off, and on some Android handsets blocked by aggressive manufacturer battery management. So push is a prompt, never a transport: the actual state always lives on the server, the app reconciles when it opens, and anything important also appears somewhere in the app rather than only in a notification the person may never see.

They keep using whatever version they installed, sometimes for years, and your API has to keep serving them. That is why we treat every API change as additive by default: new fields are added, existing ones are never removed or given a different meaning, and the app is written to tolerate fields it does not recognise. Where a genuine breaking change is unavoidable, a new version runs alongside the old one and we look at the real version distribution before retiring anything. We also build in a minimum-supported-version check from day one, so in the rare case where an old build must stop, it shows a clear update screen instead of failing in a confusing way.

In the platform secure storage — the keychain on iOS and the keystore-backed equivalent on Android — never in ordinary application preferences or a plain file, and never written into logs. The app holds a short-lived access token used for requests and a longer-lived refresh token used only to obtain new ones, so a leaked access token expires quickly. Refresh tokens rotate on use, and a reused one is treated as a compromise and revoked server-side. Where the app is protected by biometrics, that unlocks the local session rather than authenticating against the server, because the whole point is that it has to work with no connection.

Sometimes, and it is always worth checking before spending money. The problems usually appear in three places. A web API tends to be chatty, because on a browser ten small requests over a fixed connection cost little, whereas on a phone each one wakes the radio and is paid for in battery and data. It often assumes cookies and a browser session rather than tokens. And it frequently returns whole objects when a list screen needs four fields, which on a mobile connection is noticeable. The usual answer is not to rebuild anything but to put a small mobile-facing layer in front of it that batches, trims and paginates for the screens the app actually has.