Service specification 4 sections All three routes
Mobile App
Development
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.
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.
| 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.
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.
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.
-
01
Scope, before anything is drawn
Every screen listed, every user type named, and a decision on each of the hard questions: offline, logins, payments, notifications and which systems the app reads from. This is the stage where changing your mind is free. Our guide to writing a software specification covers doing this yourself before you ask anyone for a quote.
-
02
Design and the build
Screens designed against real content rather than placeholder text, then built on the route we agreed. The backend is usually Laravel, holding the records the rest of the business already uses, so the app is a view onto your data rather than another island of it.
-
03
Testing on real devices
Simulators miss things that real handsets catch, especially on older Android phones and on poor connections. Testing covers the awkward cases too: no signal, a dead battery mid-task, a permission the user refused, and a phone whose operating system is three versions behind.
-
04
Store submission and after
Both stores review a build and both can reject one. We prepare the listing, the privacy policy and the screenshots, submit it, and deal with the reviewers. Then it needs keeping current, because Apple and Google change their rules and their operating systems every year.
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.
-
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.
-
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.
-
03.3
Accounts, payments and data
Logins, roles and card payments each add rules, and each adds things that have to be tested properly.
-
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.
- Every screen listed
- The route agreed
- Offline and logins decided
- A fixed price against that scope
Common questions
How much does it cost to develop a mobile app in the UK?
How much does it cost to hire a mobile app development company?
Which mobile app development company is the best?
Do I need a native app or will a web app do?
How does an app get into the App Store and Google Play?
Who owns the app once it is built?
What happens after the app launches?
Can the app work with no signal?
Should we start with a smaller first version?
What an app usually talks to: field service management software, customer portal software and IoT software development.
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