/ Shipping
What it actually takes to ship an iOS app end to end
The build is the part everyone plans for. The other eighty percent is the part that decides whether it ever reaches a phone.
8 min read
Decide what it is before you open an editor
The most expensive hours in an app are the ones spent building something whose purpose is still being negotiated. Before any code, we write the single sentence: who this is for and what it does for them.
If that sentence needs an 'and' to feel complete, the scope is wrong. Cut until it does not.
Build the spine first
Get one complete path working before anything is polished — launch, do the core action, see the result, close, reopen and find it still there. Persistence, state, and navigation are where the real problems live, and they are much cheaper to find early.
Only once that spine holds do we spend a day on type, motion, and the empty states. Polishing a path that is going to be rebuilt is a way of feeling productive without being productive.
The store listing is part of the product
Most people decide in the App Store, not in the app. The title, the subtitle, the first two screenshots, and the first line of the description carry more weight than any feature added in week six.
Screenshots should show the app doing its job with plausible content. A screenshot full of placeholder text tells an accurate story about how finished the app is.
- A subtitle that says the job, not the category
- Screenshots in the order someone would actually experience the app
- A description whose first sentence works alone
- Keywords chosen from what a person would type, not what a marketer would write
Privacy and data disclosures
Privacy answers have to match the code. If the app talks to a model provider, that is a disclosure. If it stores anything on a server, that is a disclosure. Getting this wrong is both a review problem and a trust problem.
This is also a design constraint worth using. Ghosted runs its presence detection on the device, and that decision made the privacy story short — which is exactly why it is worth saying out loud.
Review is a conversation
A review rejection is usually a request for context rather than a verdict. Reviewers work fast and cannot infer intent, so the notes field should tell them how to reach the feature, what a test account is, and why an unusual permission exists.
Answering thoroughly the first time is far cheaper than an appeal cycle. Assume the reviewer has thirty seconds and no prior knowledge.
Day one is not the finish line
Before launch there must be a support address a human reads, crash and error reporting that reaches you unprompted, and a way to ship a fix quickly.
An app without those is not shipped. It is abandoned in public.
Building something this applies to?
We take on a small number of outside builds each year — websites, apps, automations, and internal systems. Or look at what we build and operate.
Start a project