Every Question We Get Asked About Building an App

The test is what the app leans on. If it is mostly screens, forms, lists, search and API calls — a booking app, a marketplace, a content app, an internal tool — cross-platform with React Native or Flutter usually wins, because one codebase covering both stores is meaningfully cheaper to build and far cheaper to maintain for years afterwards. Native Swift or Kotlin earns its extra cost when the hardware is the point: sustained camera work, Bluetooth peripherals, background location, heavy custom animation, large offline datasets, or platform features you want the week the OS ships. We build both, so the recommendation is not decided by what we would rather sell you.

Starting with one platform is often the smarter move, and the question is where your users actually are rather than which platform is bigger globally. If you are testing an idea, one platform gets you real feedback for roughly two-thirds of the cost, and the second platform becomes a decision you make with evidence instead of a guess. Two situations argue for both at once: a consumer app where telling half your audience “not yet” kills the launch, and a cross-platform build where the marginal cost of the second store is small enough that splitting it makes little sense. We will tell you which case you are in.

Sometimes it would, and we will say so. A responsive website is the better answer when the thing people do is occasional, when discovery happens through search, and when there is no reason for an icon to sit on a home screen — nobody installs an app to read your menu once. An app earns its place when you need repeat use and a home-screen habit, push notifications people actually want, camera or sensor access, meaningful offline behaviour, biometric sign-in, or performance a browser cannot reach. Asking someone to install software is a real request, and it has to be repaid in something the web genuinely cannot do.

Yes. We take paid advisory work: reviewing an existing codebase and giving you a written verdict, sanity-checking a quote you have received from someone else, reviewing an app before you acquire the company that owns it, or working out whether your idea should be one app or two. It is charged as a fixed-price piece with a written output at the end, and the output is genuinely yours to act on however you like — including hiring a different studio. If the honest conclusion is that the current team should carry on, that is what the document will say.

Both are mature and both ship real products, so this is rarely the decision that makes or breaks a project. React Native fits when your team already lives in JavaScript or TypeScript, when you are sharing logic with a web product, or when you depend on libraries with strong React Native support. Flutter fits when you want a highly custom, identical visual design on both platforms and tight control over rendering, because it draws its own widgets rather than wrapping the platform ones. The real question is who will maintain the app in three years, so we weight the answer towards whichever your future developers are more likely to know.

Yes, end to end, and it is part of the build rather than an extra. That covers setting up the developer accounts in your company name, signing certificates and provisioning, the store listings and their descriptions, screenshots at the required device sizes, age ratings, the privacy and data-safety declarations both stores now require, export compliance answers, a demo account for the reviewer, and responding to review feedback until the app is live. Handing a client a binary and wishing them luck is where a lot of first submissions die.

We fix it and resubmit, and it is not billed to you when the rejection relates to work we did. Rejections are normal rather than catastrophic — the common causes are a permission string that does not explain why the app needs access, a reviewer unable to get past a sign-in wall, a subscription screen missing a required disclosure, metadata promising something the build does not do, or a crash on the reviewer’s device. Because we design around that list from the start, the rejections we do see are usually answered with a clarifying note or a metadata change rather than with new code.

You do, from the first week. We create both accounts in your company name with you as the legal account holder, and we are added as a member with the access needed to do the work. Apple and Google bill you directly on their own renewal cycles. The reason this matters is that an agency-owned account makes your app an asset on somebody else’s balance sheet: if the relationship ends badly you can lose your listing, your reviews, your ratings history and your ability to ship an update, all at once. We remove that risk by never creating it.

Yes, and that is usually the better option if you already have one, because your existing account may carry reviews, ratings history and a user base worth keeping. We ask to be added as a member with a defined role rather than being handed the account holder credentials — you keep the two-factor authentication on your own device, you can see exactly what we have access to, and you can remove it in one click. If your account is currently held by a previous agency, we can walk you through getting the app transferred into an account you control before anything else starts.

Phased, wherever the platform allows it. On Android we start a release at a small percentage of users and step it up while watching the crash-free rate and the vitals, and we can halt a rollout mid-way if something is wrong — which is the closest thing mobile has to an undo button. iOS offers a phased release for updates over a number of days, and we use it. This matters more on mobile than anywhere else: a bad web deploy is reversed in minutes, whereas a bad app release is already installed on people’s phones and can only be corrected by shipping another build and waiting for them to take it.

Usually nothing you did. Both platforms ship a major OS release every year that retires APIs, changes permissions and alters how screens are drawn. New handsets arrive with new sizes and aspect ratios that your layout was never tested against. Signing certificates, provisioning profiles and push keys expire on dates nobody wrote down. Store policies change with compliance deadlines attached, and Google raises the minimum target API level each year. Third-party libraries get abandoned or publish breaking versions. An app left completely alone typically starts failing for real users somewhere between twelve and eighteen months in.

No, it is never a condition of the build, and a small app with a patient audience can reasonably be looked at once or twice a year instead. What we will not do is let you believe an app is finished at launch. If you skip a plan, budget for a compatibility release around each annual OS launch, keep a calendar entry for every certificate and key expiry, and watch your crash reports. If none of that is going to happen in practice, a retainer is cheaper than the emergency it prevents — the support plans page sets out the bands and what each covers.

Every change, however small, has to go through a new build and a store review before a single user sees it, and then those users have to actually install it. That is the structural difference between mobile and the web, and it shapes everything: fixes get batched into planned releases rather than shipped one at a time, anything configurable is made remotely adjustable so it can be changed without a release, and the app is built to stay compatible with older versions of your backend, because a meaningful share of your users will still be on last month’s build for months.

You own it. The repository is in your organisation from the first commit, the developer accounts are in your company name from week one, and full intellectual property in everything built for you transfers on final payment. If we stop working together, there is nothing for us to hand back because you already hold it — we do a handover instead: a written state-of-the-app note, the build and release documentation, confirmation of where the signing keys live, a list of every third-party service and what it costs, and our access removed once you are ready. No hostage-taking, no exit fee.