DEV Community

CoreDataHero
CoreDataHero

Posted on

iOS App Submission Guide, Apple Developer Account Registration, IPA Packaging, etc.

Developers have probably all encountered this situation: the app is developed and ready to launch, but when you start the submission process, you realize there are quite a few things to prepare—certificates, provisioning profiles, screenshots, and privacy policies. Skip any step and you can't submit for review. This iOS app submission guide starts from registering a developer account and walks through the entire process from beginning to end, also mentioning operational differences across different computer environments.

Registering a Developer Account

Before submitting, you need to register an Apple Developer account. Individual developers choose the Individual type, which costs $99 per year and displays your personal name on the App Store. Company accounts also cost $99 per year but require a D-U-N-S number and display the company name. During registration, you fill in credit card information and tax information. Once your registration is approved by Apple, the developer account becomes active. A free Apple ID can only be used for development and on-device debugging; it doesn't have submission permissions and cannot generate Distribution certificates. If you choose the wrong account type, it's troublesome to change later, so decide in advance whether the display name will be personal or company.

Creating an App ID and Generating Certificates

Log in to developer.apple.com to create an App ID (Bundle ID), fill in the unique app identifier, and enable required services such as Push Notifications or Sign in with Apple.

There are two types of certificates: Development certificates are used for on-device debugging, while Distribution certificates are used for release submission. On a Mac, you generate a CSR using Keychain Access, submit it to the developer console, download the .cer file, and import it back into Keychain to export as a .p12. The entire process relies on the macOS environment. If you don't have a Mac, you can use tools like Appuploader to create certificates directly on Windows—open the certificate manager, select the Distribution type, enter a name and P12 password, and they can be generated within minutes. The resulting .p12 file can be exported for team use, so not everyone has to apply for one individually.

A provisioning profile associates certificates, the App ID, and test devices. For App Store submission, select the App Store type; for internal testing, select Ad Hoc. After filling in the Bundle ID, checking the certificates and devices, download and import the profile. Multiple apps can share a single Distribution certificate, but provisioning profiles must be created independently for each app. When adding new test devices, UDIDs can be read automatically, saving the hassle of manual input.

Packaging and Uploading

For native projects, use Xcode's Product → Archive to export an .ipa. This step needs to be done on macOS. Cross-platform projects (Flutter, uni-app, React Native) each have their own packaging commands that compile and output an .ipa, and they can also be compiled on Windows. When packaging, ensure the version number isn't duplicated and the Bundle ID matches the provisioning profile.

There are several ways to upload to App Store Connect: Xcode Organizer and Transporter are limited to macOS, and fastlane relies on xcrun, which also requires a Mac environment. Appuploader can upload IPA directly on Windows and Linux. Select the upload channel, fill in the app-specific password, click upload, and wait for the progress bar to complete and an email confirmation. If the build version doesn't appear, check whether the version number is duplicated or the account permissions are correct.

Preparation Before Submitting for Review

After uploading, fill in the app information in App Store Connect: name, subtitle, description, keywords, and privacy policy URL. Upload screenshots in both 6.5-inch and 5.5-inch sizes; add another set if you support iPad. Screenshots must comply with Apple's guidelines and must not contain unreleased features or sensitive content. If the app involves user login, provide test accounts for reviewers. When using permissions such as location, camera, and contacts, explain the usage in the remarks. These preparation tasks are also an easily overlooked part of the iOS app submission guide—incomplete assets can slow down the review process. After filling in everything, click Submit for Review and wait for Apple's feedback.

Top comments (1)

Collapse
 
crdtcto profile image
Kane Lim

Hello CoreDataHero, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.

Your guide covers the practical submission workflow well, but I would add one architectural improvement: treat App Store delivery as a reproducible CI/CD pipeline rather than a manual certificate and IPA workflow. The biggest operational risk is not packaging itself, but credential drift, signing identity conflicts, expired provisioning profiles, and configuration divergence between environments.

For a production setup, I would isolate signing credentials from application source, use encrypted secrets with strict RBAC, and automate versioning through CI. Fastlane Match or an equivalent signing repository can centralize certificate and profile lifecycle management, while CI runners can validate Bundle ID entitlements, provisioning profile compatibility, code signing identity, build number monotonicity, and export options before producing the artifact.

I would also introduce a preflight validation stage that checks privacy manifests, required entitlements, deployment targets, architectures, App Store metadata, and API environment configuration before upload. This turns many App Store rejection conditions into deterministic build failures instead of surprises during review.

For teams supporting Flutter, React Native, or native modules, artifact reproducibility is especially important. Pinning Xcode, SDK, dependency, and Ruby toolchain versions can eliminate a large class of environment specific failures.

I would like to get to know you better and discuss about your post. Would you please contact me? t_g_@kanelim1997