Why a mobile app takes longer than you were told

Someone has quoted you six weeks. Someone else has said five months. Both of them looked at the same brief, and the gap is not that one is greedy and the other is padding — it is that they are describing different objects.

A production mobile application is not a set of screens. It is a set of screens, plus everything that has to be true for a stranger to install it and have it work. That second part is most of the work, and it is invisible in a brief.

Where the months actually go

You are building two apps. iOS and Android share your React Native code and disagree about everything else: permission dialogs, push notification behaviour, background execution, keyboard handling, back navigation, safe areas, and what happens when the system decides to reclaim memory. Cross-platform means one codebase, not one implementation. Budget for testing both properly, on real devices, because simulators lie in specific and well-documented ways.

The store is a party you have to be invited to. App Store review is days, not minutes, and a rejection costs a round trip. You need screenshots at required sizes, a privacy manifest that accurately describes your data collection, a support URL, an age rating, and — if you use any sensitive permission — a written justification a human being will read. First submissions are rejected routinely, for reasons nobody thinks about at brief stage.

Push notifications are infrastructure. "Send the user a notification" means a server, credentials for both Apple and Google, a device token you store and refresh, handling for the token going stale, a decision about what happens when delivery fails, and a plan for what the notification says when the device is locked. It is a subsystem, and it is often mistaken for a feature.

Offline is a product decision disguised as a technical one. Phones lose signal. What should your app do — block, queue, or lie optimistically and reconcile later? Every one of those is a different data model. Deciding late means rewriting the layer everything else sits on.

Auth is never just a login screen. Sign-up, sign-in, sign-out, password reset, session expiry, token refresh, biometric unlock, account deletion, and — if you support Apple sign-in — the requirement to offer it at all. Apple also requires an in-app way to delete an account, which reaches into every table you have.

Releasing is a process, not an afterthought. Signing certificates, provisioning profiles, build pipelines, a beta distribution channel, crash reporting, and some way to know whether the version people are running is the version you think it is. Set up once, then exercised on every release for the life of the product.

So what is the six weeks describing?

Usually one of three things. A prototype — real screens, fake data, not installable by strangers. A single-platform build, where "we'll do Android later" is doing a lot of load-bearing work. Or a genuinely small app: one screen, one API, no auth, no notifications, no offline story. Those exist, and six weeks may be right.

The useful question is not "how long" but "how long until what". Ask any quote to name what is installable, by whom, on which platforms, with which of the above included. The estimates will stop disagreeing, because they will finally be describing the same thing.

What to do with this

If the timeline matters more than the scope, cut the scope — deliberately, in writing, with the cut things named. A focused first version that ships in three months and gets used beats a complete one that arrives in nine and is wrong, and you will only learn which parts were wrong from people using it.

What does not work is keeping the scope and compressing the estimate. The work does not go away. It moves to after launch, where it is more expensive and has your users in it.