应用开发指南：成本、时间与常见问题

Start with whether you need an app

The most expensive app decision is made before any code exists: building one at all.

An app has to be found in a store, installed, granted permissions, and then kept on a home screen that its owner periodically tidies. That is a lot of friction to overcome. It is worth overcoming when the app offers something a website cannot:

• Offline capability — field staff, delivery drivers, anywhere with unreliable signal
• Push notifications — genuinely useful ones, not marketing broadcasts
• Device hardware — camera pipelines, Bluetooth peripherals, background location
• High-frequency use — something opened most days, where saving three seconds compounds

If none of those apply, a fast, well-built mobile website will reach more people for less money. We tell clients this regularly, and it is usually the most valuable thing said in a first call.

What an app actually costs in the UK

Published "app cost calculators" are marketing tools. Here are the ranges we quote against, for a UK agency doing the work properly:

Scope	Typical range
Single platform, focused feature set	£6,000 – £12,000
Cross-platform, iOS and Android	£8,800 – £18,000
With payments, live data or offline sync	£14,000 – £28,000
Ongoing maintenance, per year	15–20% of build cost

That last row is the one most budgets omit, and it is not optional. iOS and Android each ship a major version every year. Google raises its target API requirement annually and delists apps that fall behind. An app with no maintenance budget has a working life of roughly two years.

Anything quoted below about £3,200 is either a white-label template, or a fixed price that will be renegotiated once the awkward parts surface.

Native or cross-platform

This is the decision that most affects cost, so it is worth being clear about the trade-off rather than treating it as a matter of taste.

Cross-platform (Flutter, React Native) means one codebase producing both apps. You save roughly 30–40% on build and considerably more over time, because there is one set of features to keep in sync rather than two. For the large majority of business apps — booking, ordering, dashboards, internal tools — the user cannot tell.

Native (Swift, Kotlin) means two codebases and two sets of platform expertise. It is the right answer when the app leans hard on the device: sustained camera processing, background location tracking, ARKit, or animation complex enough that a rendering layer in between becomes visible.

The secondary question is who maintains it. If your team already writes React, React Native lets them share skills and some code with your web app, which frequently outweighs Flutter's technical edge. If you have no in-house mobile capability at all, Flutter is the safer technical bet. Either way, the hiring market you will recruit into matters more than the benchmark.

Where budgets quietly disappear

Five things account for most overruns we see on projects that arrive from elsewhere.

1. Offline behaviour treated as an edge case

"It needs to work offline" sounds like a feature. It is an architecture. Retrofitting local storage and conflict resolution into an app built around live API calls is close to a rewrite. Decide this in week one.

2. Push notifications added at the end

Notifications require server infrastructure, permission flows, segmentation, and deep links that open the correct screen. Bolted on at the end they become "send everyone the same message", which trains users to disable them — losing the retention lever the app was built for.

3. Store review not planned for

First submissions to Apple are frequently rejected. Not for anything dramatic: privacy strings, unclear subscription terms, missing account deletion, iPad presentation on a universal app. A schedule with no allowance for one or two review rounds is a schedule that will slip publicly.

4. Backend scoped as an afterthought

Most apps are a front end for a service. If that service does not exist, you are commissioning two projects. Where the backend already exists, its API is often shaped for a website and needs reworking for mobile — chattier endpoints, pagination, and payloads sized for a mobile connection.

5. Testing on one flagship device

This is mostly an Android problem, and a large one. An app that performs well on a recent flagship can be unusable on the mid-range handset a substantial share of UK users carry. Add manufacturer battery managers that kill background processes, and "notifications stopped working" becomes your most common support ticket.

A realistic timeline

For a cross-platform business app:

1. Scope and design — 3 to 4 weeks. Feature list, flows, and interface design reviewed on real devices.
2. Core build — 8 to 12 weeks in two-week cycles, each ending with an installable build.
3. Beta — 2 weeks with real users on TestFlight and Play internal testing.
4. Store submission — 1 to 3 weeks including likely review round-trips.
5. Post-launch — 30 days of fixes, then maintenance.

Roughly four to five months. Compressing it usually means removing the beta, which is exactly the part that catches the problems your users would otherwise report publicly in store reviews.

What to ask any agency before signing

• Who owns the code, and do we get the repository?
• Are the developer accounts registered to us or to you?
• What happens if Apple rejects the submission — is that billed?
• What is the maintenance cost per year, in writing?
• Which specific devices will you test on?
• What happens to the app if we stop working together?

The answers to those six questions tell you more than any portfolio. If any of them produce hesitation, that is your answer.

Next steps

If you are weighing up an app, the useful first conversation is not about features — it is about whether the app is the right shape for the problem. We are happy to have that conversation and to tell you if the answer is a website.