Shipping an app by yourself means you're the developer, the tester wrangler, the copywriter and the person reading App Review emails at midnight. Things fall through the gaps because there's nobody else to catch them.
The checklist below is for a first iPhone release. Most of it applies to updates too.
A few weeks out
Get the app on TestFlight early and invite people who aren't your friends. Friends tend to go easy on you. Strangers are more likely to say where they got stuck.
Set up crash reporting before the beta, so the first crashes don't go unseen. Read every crash, even the ones you can't reproduce yet.
Keep a running list of tester feedback, with who said it and on which device. Bugs that only happen on older iPhones or older iOS versions are common and easy to miss on your own phone.
Decide what has to work for release and what can wait for the first update. Write both lists down. When a tester finds something, you'll know which list it belongs on, and you won't keep moving the launch for small stuff.
Make sure your privacy policy and support pages exist, load, and say what the app actually does. Apple asks for both, and a dead link is an easy way to get rejected.
The listing
People decide in a few seconds, mostly from the name, the subtitle and the first two or three screenshots.
- Use the subtitle to say what the app does in plain words.
- Show the app doing its main job in the first screenshot.
- Write the description for a person, not for keywords.
- Fill in the App Privacy details honestly. They show on your listing.
Check the screenshots against the build you're submitting. It's easy to change the onboarding and forget the screenshots still show the old one. Once the version is submitted, the screenshots go with it, so fix them before you submit.
Submitting for review
Write review notes like you're explaining the app to someone smart who's never seen it. If there's a login, give them a demo account. If a feature is hard to find, tell them where it is.
Expect at least one rejection on a first app. Read it slowly, fix what it asks for and reply with what you changed. Review can take a while, so don't promise anyone a launch date until you're approved.
Choose manual release, so the app goes live when you're awake and ready to answer emails and the first reviews.
Release day
Before you tell anyone, open the App Store and find your app the way a stranger would. Check that it's live where you expect it to be and that the link you plan to share works.
Then tell people. Start with the places you already belong to: a forum, a Slack group, a newsletter, a few friends who'll actually try it. A post from someone people recognize does better than ten posts from a stranger.
The first week
Read every review and every email. Reply to the ones you can. Write down what people asked for, and how many times. The third request for the same thing is worth more than one loud one.
Watch the crash reports closely. A crash that only shows up at scale is the most common surprise of week one.
Pick the one or two fixes that matter most and ship a small update. People notice when an app gets better quickly.
Where Nave fits
Launch information arrives in pieces from everywhere: a TestFlight comment, a rejection email, an idea in the shower. It's easy to deal with each piece and lose the thread of the whole launch.
Say each piece out loud as it lands. By release day the thread reads like a log of the whole launch, and the open actions work as your checklist. Here's an invented launch, start to finish.
