Publishing on the App Store is more procedural than difficult, but Apple’s review is genuinely stricter than Google’s and first-submission rejections are common. Knowing where the process bites saves weeks.
Before anything else
You need a Mac. Xcode runs only on macOS, and while cross-platform frameworks let you write code anywhere, building, signing and submitting requires a Mac somewhere in the chain. Cloud build services exist as a workaround, but plan for this rather than discovering it late.
Step 1: The developer account
Enrol in the Apple Developer Program, which carries an annual fee, as an individual or an organisation.
Choose carefully. An individual account publishes under your personal name, visible to every user. An organisation account publishes under a company name but requires a legal entity and a D-U-N-S number, which takes time to obtain. Switching later is possible but awkward.
Organisation verification commonly takes one to two weeks. Start it before your app is finished.
Step 2: Identifiers, certificates and profiles
The signing chain is where most first-timers lose a day. You need a bundle identifier naming your app, a distribution certificate identifying you as publisher, and a provisioning profile tying them together.
Modern Xcode automates most of this if you enable managed signing. Turn it on unless you have a specific reason not to.
Step 3: Create the App Store Connect record
Create a new app record using the bundle identifier, an app name, a primary language and an SKU.
The name is worth thinking about. It must be unique across the store and carries real weight in store search. Names are claimable, so create the record early to reserve one you have settled on.
Step 4: The listing
Prepare before uploading, because incomplete metadata blocks submission:
- Subtitle — short, and indexed for search
- Description — not indexed for search, unlike Google Play
- Keywords field — limited characters, comma separated, no spaces. This is where your search terms go. Do not waste it on your app name or category name.
- Screenshots for required device sizes
- App icon at full resolution
- Privacy policy URL — mandatory and must resolve to a real page
- Support URL
- Age rating questionnaire
- App privacy details — a full declaration of data collected and how it is used
That privacy declaration is not paperwork. It must match your app’s actual behaviour, including data collected by third-party SDKs. Analytics and advertising libraries collect on your behalf and you are responsible for declaring it.
Step 5: Build and upload
Archive in Xcode and upload. Processing takes minutes to hours.
Test through TestFlight before submitting. Internal testing reaches your team quickly; external testing reaches wider testers and requires its own brief review. Skipping TestFlight is a false economy — it is the cheapest place to find the crash that would otherwise cause rejection.
Step 6: Submit for review
Review times are typically measured in days but vary, lengthening around major platform releases and holidays.
Provide a demo account if any part of the app sits behind a login. Reviewers who cannot access your app reject it, and this is among the most common avoidable rejections. Include credentials and confirm they work.
Why apps get rejected
- Incomplete or crashing builds. Test on a real device, not only the simulator.
- Broken or missing demo credentials.
- Insufficient functionality. Apps that are essentially a website wrapper, or offer little beyond a browser, are routinely rejected.
- Payment routing. Digital goods consumed in-app generally must use Apple’s in-app purchase system. This area is under active regulatory change in several jurisdictions, so check current guidelines rather than assuming.
- Privacy problems. Missing policy, inaccurate declarations, permissions requested without explanation.
- Metadata issues. Screenshots not reflecting the app, mentions of other platforms, placeholder text.
- Design ignoring platform conventions in ways that confuse navigation.
Rejections come with a specific reason in Resolution Center. Most are resolved in one round. An appeals process exists but is slower than complying.
Step 7: Release
Choose manual release, automatic on approval, or scheduled. Manual is the sensible default — it lets you coordinate a launch rather than having the app appear at an unpredictable hour.
Use phased release for updates once you have real users; it limits the damage if something is wrong.
After launch
Watch crash reports and reviews closely in the first week. Respond to reviews — it is visible to browsers and measurably improves ratings. And treat the keywords field as something to iterate on; it is the cheapest lever on store visibility and almost nobody revisits it.