How a small team ships an iOS app

The failure mode is always the same. A small team builds something good, decides it is nearly done, and then discovers that the distance between a working app and an app on the App Store is measured in days of paperwork, not hours of code. Here is what that distance is actually made of.

The store is the long pole

Before submitting, you need all of the following, and none of it can be generated from the codebase: a name and subtitle that are not already taken, a description, a keyword field, a support URL that resolves over HTTPS, a privacy policy at a public URL, an age rating questionnaire, an export compliance declaration, and a full set of screenshots.

The screenshots are the item most often underestimated. Apple requires them at specific display sizes, and the required set changes when new devices ship — check the current requirement in App Store Connect rather than trusting a blog post from two years ago. If your app is localised, you need a set per language, which means capturing the same flows twice.

Budget a full day for this, twice: once to produce everything, once to redo the half of it you got wrong.

What review actually rejects

Most first-time rejections cluster into a handful of guidelines, and all of them are avoidable if you know about them before you build:

• Guideline 2.1, App Completeness — by far the most common. Crashes on the reviewer's device, placeholder content, broken links, or a login wall with no demo account supplied in the review notes.
• Guideline 4.2, Minimum Functionality — the app does too little, or is essentially a wrapper around a website. A thin first version is fine; a repackaged web page is not.
• Guideline 3.1.1, In-App Purchase — digital content and subscriptions must go through Apple's in-app purchase system. Sending users to an external payment page for digital goods will be rejected.
• Guideline 5.1.1, Data Collection and Storage — the privacy policy must exist and match reality, permission prompts must explain why you need access, and if users can create an account in the app they must be able to delete it from the app too.
• Guideline 2.3, Accurate Metadata — screenshots must show the actual app, and the description must not promise features that are not there.

The demo account one deserves emphasis because it is pure self-inflicted delay. If any part of your app sits behind a login, put working credentials in the App Review notes field. Reviewers do not sign up.

The privacy questionnaire is a design document

App Store Connect asks you to declare, per data type, whether you collect it, whether it is linked to the user's identity, and whether it is used for tracking. This becomes the privacy label on your store listing.

Filling it in honestly is harder than it sounds, because it forces you to know exactly what every SDK in your project sends. Analytics libraries in particular often collect more than teams assume. The useful move is to answer the questionnaire early — during development, not at submission — because the answers frequently change what you are willing to ship.

TestFlight before you think you are ready

A build running on your own device through Xcode is not the same as the build users get. Distribution builds are compiled differently, and a surprising number of bugs only appear there: missing assets, permission strings you forgot to localise, code that worked because of a debug-only condition.

Push a TestFlight build early and repeatedly, well before launch. Install it on a device you do not develop on, ideally one belonging to someone who has never seen the app. The first thirty seconds of a stranger using your onboarding will tell you more than a week of self-testing.

Scope discipline: one loop that works

The version that ships should do one thing completely rather than five things partially. Not because minimalism is a virtue, but because review, support, screenshots, and your own explanation of the app all get harder with each additional surface.

The practical test: can you describe what the app does in one sentence, without the word 'and'? If not, something in it is waiting for version two.

A realistic sequence

1. 01Week one: reserve the app name in App Store Connect. Names are first come, first served, and discovering yours is taken at submission is a bad day.
2. 02During the build: publish the privacy policy and support page to real URLs. They are required and they are trivial to forget.
3. 03Two weeks before launch: fill in the App Privacy questionnaire. Fix whatever it reveals.
4. 04Ten days before: first TestFlight build to people outside the team.
5. 05One week before: produce screenshots for every required size and every language. Then produce them again.
6. 06Submit. Most reviews complete within a day or two, but a first submission from a new developer account can take longer, and a rejection resets the clock.

After launch is not the end

Each update goes through review again, so the cost of shipping a fix is never zero. This argues for a slightly longer first release cycle and a slightly shorter second one: get the foundations right, then iterate on a working pipeline. The studios that ship consistently are the ones that treated the first submission as a process to build, not an obstacle to clear.