Mobile app development

We quote after a scoping call rather than publishing a figure, because the range is genuinely enormous and driven by a handful of decisions. In rough order of impact: your offline strategy, whether you sell anything inside the app, whether a suitable backend already exists, how many native capabilities you need, how many platforms, and whether a design exists. Two apps described identically in a sentence can differ by a factor of five on those alone.

React Native with Expo for most products: one codebase, real native modules, and over-the-air updates for JavaScript changes, which matters because the review loop is slow. Flutter if you want a highly consistent custom interface and are happy with Dart. Native when the product is the platform experience — sustained background work, heavy animation or graphics, deep OS integration, or needing platform features the day they ship. The decision that usually dominates is maintenance: two native codebases cost roughly twice as much to keep alive, forever.

Substantial builds are split into milestones that each end at an installable build, so the answer is per milestone and set out in the scope before you commit. Beyond the code, allow for store review: it is measured in days rather than hours and it can repeat, so a launch date should be the end of the review window rather than the submission date.

Often, but the honest question first is whether it should be one. Apple’s minimum functionality guideline rejects apps that offer nothing a website cannot, so a straight wrapper is likely to be refused however well it is packaged. What works is a genuine native layer around your product — push, biometrics, offline, native share, camera where the product uses it. If we think your product has no plausible native purpose, we will say so before you pay us.

If you are using a cross-platform framework, the second platform is much cheaper than the first and it is usually worth doing together — the compliance thinking overlaps almost entirely and splitting means doing it twice. If budget forces one, pick from your own analytics rather than from general market share; who your users actually are matters far more than which platform is larger overall.

If you sell digital goods or subscriptions consumed inside the app, the stores require their billing and take a commission. If you sell physical goods or real-world services, store billing does not apply and your own checkout is fine. The rules on linking users out to an external payment page are narrow and specific, and getting them wrong risks removal rather than rejection — which is considerably worse, because removal takes your existing users with it.

You do, and we would insist on it. The Apple Developer and Google Play accounts should be registered to your company with you as the owner, and we work inside them with the access we need. An app published under a contractor’s account is genuinely difficult to move later.

To the degree you choose and pay for, which is a real decision rather than a yes or no. Graceful degradation — the app explains itself, retries, and does not lose what you typed — is included as a baseline because reviewers test on a poor connection. A read-only cache of recent data is moderate. Full offline editing with sync and conflict resolution is a significant piece of work, because deciding what happens when the same record is edited twice is a product question before it is a technical one.

You get a release runbook and crash reporting you can read yourself. The recurring obligation is the stores: both raise their SDK floors annually, and missing one means your app stops accepting updates or stops being offered to new users. A care retainer covers tracking those dates and doing the work before it becomes urgent; without one, you will get a console notice and a deadline instead.

No. We build to a design you have, or to a plain interface assembled from a platform component library, and we say plainly which of those you are getting. Mobile has more states per screen than the web — loading, empty, error, offline, permission denied, small screen, large font — and a design that only covers the happy path still leaves those to be decided.