What it really takes to ship to the App Store

If you have decided you genuinely need a native app, the code is the part that behaves most predictably. What catches people out is everything around it — and almost all of it is administrative rather than technical, which is why it rarely appears in a developer's estimate.

Accounts, and whose name they are in

Both stores require developer accounts, and they should be in your company name, not your developer's.

This sounds like a detail until you change developers and discover your app lives in somebody else's account, with their bank details attached to it, and moving it requires their cooperation. Set it up correctly on day one. It is nearly free then and genuinely painful later — we have seen businesses rebuild an app from scratch rather than untangle it.

Review is a real gate, and you do not control it

Apple reviews every submission, and Google reviews more lightly. Reviews are usually quick, but rejections happen for reasons that have nothing to do with quality: a missing privacy disclosure, a login the reviewer cannot get past, a feature the platform considers a duplicate of its own, a screenshot that does not match the app.

Plan for a rejection and a resubmission in your first release, rather than promising a launch date you do not control. If the launch is tied to an event, submit two weeks earlier than feels necessary.

The most common avoidable rejection is the demo account. If your app requires a login, the reviewer needs working credentials that reach every part of it. Half of first-time rejections are this.

Privacy disclosures are not paperwork

You must declare what data the app collects and why, and the declaration has to match what the app actually does.

Analytics and advertising libraries collect more than most owners realise, and a third-party SDK added for one small feature can quietly change your disclosure obligations. Ask your developer for the list of libraries and what each one transmits, before submission rather than after a rejection. Getting this wrong is both a rejection risk and, in several jurisdictions, a legal one.

The treadmill after launch

Apps do not sit still. Operating systems update annually and eventually stop accepting builds made against older versions. Signing certificates expire. Devices change shape. Libraries are abandoned.

An app nobody maintains stops working within about two years. It rarely fails loudly — it fails on the newest phones first, which means your most valuable customers are the ones who hit it, and you find out from a review rather than a monitor.

Budget maintenance from the start. An app you cannot afford to keep is worse than one you never shipped, because customers found it and it let them down with your name on it.

The version number problem nobody warns you about

Once an app is live, every fix reaches customers through the store. That is a slower loop than the web, and it changes how you have to build.

A bug found on a Friday is not fixed on a Friday. It is fixed, submitted, reviewed, released, and then downloaded — and a meaningful share of your users will not update for weeks, some never. So at any moment you are supporting several versions of your own app at once, all talking to the same server.

The practical consequence: anything the app talks to has to keep working for old versions, which constrains how you change your own systems long after the app itself is finished. This is the cost that surprises people most, because it is not on any invoice — it shows up as every future change taking longer.

A remote configuration switch, decided once at the start, is worth a great deal here. It lets you turn a broken feature off without a release, which converts a two-week emergency into an afternoon.

Nobody will find it by accident

The store listing is not a marketing channel for a local business, and planning as if it were is the most common way an app disappoints.

People find apps because they were already told to. A card on the table, a line on the receipt, a message after a booking, a member of staff saying "we have an app, it saves you the queue". Every business with a genuinely used app is doing one of those, deliberately and repeatedly.

So budget for the asking, not only for the building. If there is no plan for how a customer hears about it, the download numbers will be roughly the number of people who work there — and that is the outcome regardless of how good the app is.

Android is a different set of problems

People assume Google Play is the easy one. It is easier in some ways and worse in others, and the differences change what you should build first.

Review is usually faster and less adversarial, so a rejection costs days rather than a fortnight. Against that, Android runs on an enormous range of devices — different screen shapes, different manufacturers, different versions of the operating system — and something that looks correct on the one phone in your office can be visibly broken on a three-year-old handset your customers actually carry. Testing is genuinely wider work than on iPhone.

Google also enforces its own moving requirements: apps have to target a recent version of Android within a set window, or they stop being offered to new users. That is the same treadmill described above, on a different timetable, and it catches people who assumed one submission covered both stores forever.

If the budget only stretches to doing one properly, pick the platform your customers are actually on rather than the one you carry — and for most local businesses that is a question your existing website analytics can already answer.

What to have ready before you submit

Developer accounts in your company name, with billing attached to the company. A working demo account for reviewers. Screenshots at the sizes each store requires, matching what the app actually looks like. A privacy policy at a stable URL. Support contact details somebody monitors. An app icon that reads at small sizes. And a decision about who receives the review emails, because they arrive whether or not anyone is watching.

None of that is difficult. All of it takes longer than expected the first time, and every item on it has held up a launch for somebody.