Two weeks ago, I helped a colleague who just started iOS development review his first app submission project. I found that he was completely confused about certificates and provisioning profiles—he couldn't tell the difference between Development and Distribution, nor did he know how to choose between App Store and Ad Hoc profiles. This isn't just his problem; people new to iOS publishing often get confused by these concepts the first few times. This guide breaks down the core knowledge and concepts of each step in the app publishing process.
Developer Account
Before publishing, you need to register an Apple Developer account. A personal account costs $99 per year and displays your personal name on the App Store. A company account also costs $99 per year, requires a D-U-N-S number, and displays the company name. An enterprise account costs $299 per year and is only for internal distribution, not for App Store publishing. A free Apple ID can only be used for real-device debugging and development certificates; it doesn't have publishing permissions. It's troublesome to change the account type after registration, so decide on the display name before submitting. The tax information provided during registration must be genuine; the account becomes active only after approval.
Certificate Types
In the iOS signing system, there are two types of certificates: Development certificates are used for real-device debugging, and Distribution certificates are used for publishing to the App Store. One certificate can be shared among multiple apps, and its validity period follows the annual fee of the developer account. On a Mac, you generate a CSR using Keychain and submit it to the developer portal to download the .cer, then export the .p12 for backup. If you don't have a Mac, tools like Appuploader can create Distribution certificates directly on Windows. The P12 password for the certificate must be recorded separately; if you forget it, you can only regenerate it.
In this guide, the matching relationship between certificates and provisioning profiles is the most common pitfall. Simply put: for App Store publishing, use a Distribution certificate with an App Store profile; for internal testing, use Development or Distribution with an Ad Hoc profile.
Provisioning Profiles
A provisioning profile associates certificates, App IDs, and test devices. There are three types: Development for development and debugging, Ad Hoc for internal testing distribution (up to 100 devices), and App Store for publishing to the App Store. Multiple apps can share the same Distribution certificate, but each app needs its own provisioning profile. When adding new test devices, UDIDs can be automatically read and imported. Selecting the wrong type during archiving will directly cause upload failure, so confirm which type you need before configuring.
Archiving and Uploading
For native projects, in Xcode, go to Product → Archive to export the .ipa. Cross-platform projects (Flutter, uni-app, React Native) each have their own build commands to compile and output the .ipa. When archiving, make sure the Bundle ID matches the provisioning profile and that the version number (CFBundleVersion) is not the same as any previously submitted.
There are several ways to upload: Xcode Organizer and Transporter can only be used on a Mac. fastlane is suitable for teams with a Mac CI for automated releases, but it requires configuring Fastfile and Appfile. Appuploader allows direct IPA upload on Windows and Linux; you can switch channels, enter your password, and upload. It also provides a command-line version for CI integration. After uploading to App Store Connect, wait 5-15 minutes for processing. If the build version doesn't appear, first check whether the version number is duplicated.
Preparing for Submission
After uploading, fill in the app information in App Store Connect: name, subtitle, description, keywords, and privacy policy URL. Upload screenshots in two sizes: 6.5-inch and 5.5-inch. If the app supports iPad, add another set. Screenshots must comply with Apple's guidelines and must not contain unreleased features. Explain the purpose of user permissions in the notes. Provide a test account if login is required. After confirming everything, click Submit for Review and wait for feedback from the Apple Review team.
Top comments (0)