What a mobile app costs

What drives cost in a mobile app project is not the number of screens. Below is what you are actually paying for, and where projects most often stall.

First answer this: do you really need an app?

For some businesses a mobile app is the wrong tool. If a user opens it a few times a year, they will not install it, and if they do, they will delete it.

Three things justify an app:

• Frequent use. If someone opens it several times a week, an app makes sense.
• Device capability. Camera, location, notifications, offline operation.
• Field use. Teams working where connectivity is poor.

If none of those apply, a mobile-friendly website is usually both cheaper and more effective. Asking this question up front beats spending six months on an app nobody installs.

One codebase or two separate apps?

iOS and Android used to be written separately, which meant two teams and two budgets. Today most business apps can ship to both platforms from a single codebase, which roughly halves the cost.

There are still cases where separate builds are warranted: heavy graphics processing, deeply platform-specific hardware access, games. A typical business app is none of those.

What actually drives the cost

Accounts and authentication. Sign-up, sign-in, password reset, email verification, account deletion. It looks simple and takes more of the project than anyone expects.

Offline operation. If the app has to work without a connection, you need a layer that stores data on the device and syncs when connectivity returns. That is significant work on its own, and usually mandatory for field teams.

Subscriptions and purchases. In-app purchase, trial periods, cancellation and refund flows. One of the hardest things to add later. Stores also take a commission on these sales, and that rate affects your business model.

Notifications. The infrastructure, the permission flow, and the logic for which notification goes out when. A badly designed notification is a leading reason apps get deleted.

An admin panel. Who updates the content in the app? If the panel is forgotten, every small change needs a developer, and that becomes the most expensive line item over time.

Store submission. Privacy forms, account deletion flows, screenshots, description copy, review responses. It rarely gets budgeted, but it is real work.

The costs that do not appear in quotes

These are usually missing from proposals but they get paid anyway.

• Developer accounts. Apple and Google both charge an annual fee.
• Servers and databases. The app does not run alone; there is a service behind it.
• Notification and email services. They start charging as usage grows.
• Crash reporting. You cannot fix what you cannot see failing.

The three most common review rejections

No account deletion flow. If a user can create an account, they must be able to delete it from inside the app. Apple requires this and rejects apps that lack it.

Incomplete privacy declaration. Which data is collected and what it is used for must be declared fully in the store form.

Empty or demo content. The review team actually uses the app. An empty app gets rejected for insufficient content.

All three are non-issues if planned up front, and cost weeks if discovered at the end.

How the process runs

Scope. Deciding what is not in the first release. On mobile the most expensive mistake is cramming everything into version one.

Flow design. One-handed use, thumb reach, platform conventions. iOS and Android users are accustomed to different gestures, and both deserve to be designed for in their own language.

Development. Every two weeks a test build lands on your phone and you try it on a real device. Plenty of things that look fine in a simulator behave differently on real hardware.

Store preparation. Forms, images, copy. Screenshots are the most-viewed asset in a store listing and directly affect installs.

Staged rollout. Release to a fraction of users, watch the crash reports, then widen. Both stores support this and there is no reason not to use it.

After launch

On mobile, launch is not the end. Operating system updates, store policy changes, and device diversity all require ongoing maintenance.

Apple and Google ship a new version every year, and the app has to stay compatible. Apps that go unmaintained for long periods can be removed from the stores.

A practical approach: put a share of the development cost into the first-year budget as maintenance. Without that allowance, apps typically stop working properly within a year.

What actually stretches the timeline

In most projects it is not code that takes the time, it is pending decisions. Design approvals, content delivery, store account setup, and payment provider applications are the usual waiting items.

Starting those early saves more time than trying to develop faster.

---

We built the Kas Hafızam app this way; the case study walks through the process. To discuss your own project, see mobile app development.