Skip to main content

Service specification 4 sections All three routes

Mobile App
Development

01

Native, cross-platform or web app

A business app can be built three ways. Native means separate builds for iPhone and Android, written in Swift and Kotlin. Cross-platform means one codebase that ships to both stores. A web app runs in the browser, installs to the home screen and skips the app stores completely.

Why we say all three

Most agencies build one of them and recommend it every time. We build all three, so we have nothing to defend when we tell you which route your project needs.

An app is one type of bespoke software. It usually needs API integration services so it can read the records your business already keeps.

What an app gives you, and what you sign up to

An app is a commitment rather than a feature. It earns its place when people use the thing often.

Store fees are Apple's and Google's own published figures, checked 9 September 2026.
What to weigh The case for an app What you sign up to
How people reach it An icon on the phone, notifications, and it still works with no signal. They have to find it, install it, and then keep it updated.
Getting into the stores Both stores are cheap to join. Apple is $99 a year and Google a one-off $25. Everything you release goes to Apple and Google for review first, and can be refused.
Covering both phones Cross-platform tools let one codebase serve iPhone and Android. You still test on both, and some features still need native work.
Keeping it alive A well-built app runs for years without needing a redesign. Apple and Google change the rules and the operating systems every year.
Whether you need one If people use it most weeks, an app earns its keep. If they use it twice a year, a website does the same job with no install.
Who is in charge You own the code and can take it to another developer. Apple and Google decide what is allowed in their shops, and that can change.

What each route costs you and gives you

The trade is the same every time. More reach into the phone means more work, more review and more upkeep.

Native, Swift and Kotlin

Two codebases, built separately for iPhone and Android.

Best access to the camera, sensors, background location and notifications. Feels fastest. Costs most to build and most to keep current, because everything is done twice.

Cross-platform, one codebase

One codebase compiled for both stores.

Most of the reach of native for less work. A good default for a business app that needs to be in the stores. Occasionally hits something a platform will only allow natively.

Web app or PWA

Runs in the browser and can be installed to the home screen.

No store, no review queue, no approval waiting on anyone. Updates ship the moment you release them. Limited access to phone hardware and no presence in store search.

Doing nothing yet

The idea is real but the scope is not written down.

Often the right call for a month. A written scope makes every quote comparable, and it is the cheapest stage to change your mind in.

02

Which one you actually need

Nearly every company ranking for this search sells app store apps only. So they will all tell you that you need one. Here is the test we actually use.

Start with what the app has to reach

If it needs the camera, the fingerprint or face reader, background location, push notifications or dependable offline use, you are looking at native or cross-platform. Those are the things a browser either cannot do or cannot do reliably enough to build a business on.

Then ask who is going to use it

An app for your own staff can be handed out directly and does not need to win anyone over in a store listing. An app for the public has to be found, downloaded, and then opened again a week later, which is a much harder problem than building it.

If your users are your own team, on your own devices, a web app very often does the whole job. It also updates the moment you release it, with no review queue in the way.

When a web app is the better answer

A lot of what gets asked for as an app is really screens, forms, records and reports for people who are online while they use it. That is a web application, and building it as one is cheaper, quicker to change, and removes two companies from the list of people who can block your release.

We will say so when that is the case. It is not us talking ourselves out of work, because our web application development work covers those too. It is just the cheaper answer, and you would find out eventually.

Have you shipped apps before?

Yes, to both stores. Those clients are under NDA, so this page names none of them and shows no screenshots. We would rather say that plainly than fill the page with stock mockups.

We can name the sectors, if not the clients. That work has covered healthcare, tyre and vehicle repair businesses, and housing development portfolio management. Ask on a call and we will tell you what we can about the shape of each build.

03

What goes into an app build

Four stages. The first one decides the price of the other three, which is why we will not quote without it.

What drives the cost

We do not publish a figure, because an honest one needs the scope first. These are the four things that move it most.

  1. 03.1

    Which route, and how many stores

    Native for both platforms is the most work. One cross-platform codebase is less. A web app is least.

  2. 03.2

    Whether it works offline

    Reading offline is one job. Recording offline, then merging two people's changes safely, is a much bigger one.

  3. 03.3

    Accounts, payments and data

    Logins, roles and card payments each add rules, and each adds things that have to be tested properly.

  4. 03.4

    What it has to talk to

    An app reading one feed is simple. One that syncs with your existing systems needs each of those links built.

How the number gets set
  • Every screen listed
  • The route agreed
  • Offline and logins decided
  • A fixed price against that scope
04

Common questions

How much does it cost to develop a mobile app in the UK?
We do not publish a figure, because an honest one needs the scope first. What actually moves the number is the count of screens, whether it has to work offline, whether it needs a login and an account system, how many systems it reads from, and whether it ships to one store or both. A single-screen app that reads one feed is a different job from one that holds records, syncs and takes payments. Send us what the app has to do and you get a fixed price against that.
How much does it cost to hire a mobile app development company?
Agencies price in different shapes, so compare like with like. Some quote a fixed price for a written scope. Some sell a day rate, where the total depends on how long it takes. Some quote low and charge for changes. Ask which of those you are being given before you compare two numbers. Also ask what is excluded: store submission, testing on real devices, and the work after launch are the three things most often left out of a headline figure.
Which mobile app development company is the best?
There is no single best one, and any company answering that question with its own name is not worth listening to. Judge on fit. A specialist that only builds native apps will recommend a native app. Ask whether the company also builds web apps, because if it does not, it cannot give you a neutral answer about which you need. Then ask to speak to a client whose project was a similar size and shape to yours, not their largest one.
Do I need a native app or will a web app do?
Start with what the app must reach. If it needs the camera, the fingerprint reader, background location, push notifications or reliable offline use, that points to native or cross-platform. If it is mostly screens, forms, records and reports for people who are online, a web app usually does the job and skips the app stores completely. The second case is more common than the search results suggest, because almost everyone ranking for this phrase only sells the first one.
How does an app get into the App Store and Google Play?
Each store has its own developer account, its own review process and its own rules, and both can reject a build. Apple and Google both want a privacy policy, a clear account deletion route where accounts exist, and screenshots and copy for the listing. The accounts should be registered in your company name, not ours, so the app stays yours if you ever move supplier. We handle the submission and the back and forth with the reviewers.
Who owns the app once it is built?
It depends on the build. If we create a new codebase for you, you own that code and its documentation. If the project uses our Zeus Laravel CMS for the backend, Dev Moves keeps ownership of Zeus and licenses it to you, and reusing it lowers the development cost because the core platform already exists. We package the project-specific frontend separately and you own it. The store listings and developer accounts should be in your name, and your data stays yours.
What happens after the app launches?
Apps need more upkeep than websites do. Apple and Google both change their rules and their operating systems every year, and a build that is left alone will eventually stop being accepted or stop working on new phones. So plan for updates rather than treating launch as the end. We can maintain the app, ship those updates and add to it. What is included is set out in the agreement rather than being an open-ended promise.
Can the app work with no signal?
Yes, if it is designed for it from the start. The app holds the data it needs on the device, lets someone carry on working, then syncs when a connection comes back. The hard part is not the storing, it is deciding what happens when two people changed the same record while both were offline. That rule has to be agreed in the scope, because there is no safe default. Retrofitting offline support later is far more work than building it in.
Should we start with a smaller first version?
A minimum viable product is a first release that does one job properly. It is the cheapest way to learn whether people actually use the thing. Choose what stays out while writing the scope, rather than dropping parts halfway through the build. That keeps the price and purpose clear. A small first version still needs proper care over user accounts, stored data and approval from Apple or Google. Small should mean focused, not rushed or unsafe. You can add the next useful part once real use shows what matters.

Every question we get asked, in one place

Next step

Tell us what the app has to do

Describe the job rather than the app, and we will tell you which of the three routes fits and what it would take. If a web app does it for less, we will say that too.

  • Pontefract, West Yorkshire
  • Building for businesses across the UK
  • Reply within 1 working day