How to Actually Get Your App on the App Store
The parts every tutorial skips, demystified. Plus: why Ocho got rejected twice before going live.
Submitting your app to the App Store sounds like the finish line. You have built the thing, you have the screenshots, you have the name. You press submit and you wait.
Then you get an email from Apple saying your app is rejected.
If that happens to you, you are not doing it wrong. It happened to me, twice, before Ocho went live on May 29, 2026. And both rejections were for things that had nothing to do with the quality of the app. They were paperwork mistakes. Things no tutorial warned me about, because the tutorials show you the exciting parts and quietly skip the bureaucratic ones.
This post names every one of those traps and tells you how to walk through them without getting stopped.
Where this sits in the whole journey
This series walks the entire path from “I have an idea” to “my app is live and earning,” in six steps:
Validate - is the idea worth building?
Design - make something you’re proud of, without a designer
Build - ship it with AI agents directing the code
Ship - get it on the App Store (you are here)
Money - get people to actually pay
Growth - your first 1,000 users
You made it to step four. This is where the work shifts from building to bureaucracy. The good news is that bureaucracy has rules, and rules can be followed.
What Apple is actually doing when they review your app
Apple reviews every app before it goes live. A human reads your submission, taps through your app, and checks it against a published set of guidelines. The review usually takes one to three days for a first submission.
Most founders assume rejection means something is broken in the code. Usually it doesn’t. The most common rejections for first-time founders are in the admin layer: the information you gave the reviewer was incomplete, or one of the fields in App Store Connect, Apple’s submission web portal, was filled in wrong.
App Store Connect is where you build your app’s product page: the name, the description, the screenshots, the pricing, the privacy answers. It’s also where you submit the app for review. Think of it as the form you file before the examiner opens the door.
The two things that tripped up Ocho
Ocho got rejected twice, and neither rejection touched a line of code.
The first was under Guideline 2.1, which Apple calls “App Review Information.” This section has a notes field where you are supposed to tell the reviewer how to use your app. If your app requires an account, you write the demo username and password here. If it doesn’t require an account, you write that explicitly. I left the field empty. The reviewer couldn’t get in, flagged it as “information needed,” and sent it back.
Fix: write a short paragraph in the notes field explaining what the app does, who it’s for, and how to start using it. If no login is needed, say so plainly: “No account is required. The app launches directly to the main screen.”
The second was under Guideline 2.3.2, which covers promoted in-app purchases. Ocho has a subscription. When you promote an in-app purchase on the App Store, Apple requires a dedicated 1024 x 1024 promotional image that shows what that specific purchase is. I had uploaded the app icon instead. That counts as a violation because the image is supposed to represent the purchase, not the app. Rejected again.
Fix: create a unique image for every in-app purchase or subscription you plan to promote. It can be simple: a clean background, the name of the offer, one line about the benefit. It just cannot be a copy of your app icon.
Those two fixes took about two hours. Ocho went live the next day.
Banded, my IELTS flashcard app that lets you import a word list and start drilling immediately, launched in the same week with zero rejections. The difference was preparation, specifically filling in the App Review Information notes field before submitting.
The other parts Apple checks that most tutorials skip
Beyond the review notes and the in-app purchase images, here are the other fields that catch first-time founders off guard:
Privacy policy URL - Apple requires a live, publicly accessible privacy policy before you can submit any app. It doesn’t have to be long or written by a lawyer. It does have to exist at a real URL that anyone can open.
App Privacy labels - Inside App Store Connect there is a section called App Privacy where you declare what data your app collects, why you collect it, and whether it is linked to the user’s identity. If you use any third-party analytics tool or payment processor, that tool’s data practices count too. Fill this in honestly based on what your app actually does.
Age rating questionnaire - App Store Connect asks you a short questionnaire about whether your app contains certain types of content. Answer it for your actual app. The answers determine which age group can see and download your app.
Export compliance - Apple asks whether your app uses encryption. Most apps do, even if you didn’t write any encryption yourself (HTTPS is encryption). There is a standard exemption for apps that use only standard HTTPS. You answer one question, tick the exemption box, and you are done. It takes thirty seconds once you know it exists.
Build upload - You cannot submit to the App Store from your phone or a browser. You need to build the app in Xcode, archive it, and upload it to App Store Connect using Xcode or a command-line tool. Your AI agent or developer handles this step. What you need to know is that the build has to be uploaded and listed in App Store Connect before you can submit the version for review.
App Review Information notes - as described above: short paragraph, demo credentials or “no login needed,” done.
That is the full list of the things that stop submissions. None of them are hard. They are all just invisible until you hit them.
The honest part
The App Store process was designed for professional development teams who have done this many times. The documentation exists, but it assumes you already know what “provisioning profile” means and why “bundle ID” cannot be changed after your first upload.
You don’t need to know all of that before you start. You need to know the fields that trip people up, fill them in with care, and not rush the submission. The reviewers are doing their job. Your job is to make their job easy.
If you do get rejected, read the rejection email completely. Apple names the specific guideline. Look it up on the App Review Guidelines page. The fix is almost always smaller than the rejection email makes it sound.
The full step-by-step playbook below turns this into a pre-submission checklist you can work through in one sitting before you ever press submit. It covers every field, the exact notes format that keeps Guideline 2.1 from triggering, the promotional image spec, the privacy labels worksheet, and the three founder-only decisions you have to make before Apple lets your app go live.
