Publishing an iOS app on the App Store takes significantly longer than expected—not due to technical complexity, but because of a chain of steps where each can be done incorrectly, resulting in a reject after 24–48 hours. An app submitted on Friday with a metadata error will return on Monday with a formal rejection under Guideline 2.1 "Performance: App Completeness." We've faced such situations dozens of times, so we prepared this guide based on our experience publishing over 50 projects. According to the App Store Review Guidelines, the app must be complete and stable. A subscription to the Apple Developer Program ($99/year) is the only mandatory payment.
How to Prepare for iOS App Publication
Setting up App Store Connect: create an app record, specify the Bundle ID (must match the one in Xcode), Primary Language, and Category. Without a record, Transporter and Xcode Organizer cannot upload the build.
Screenshots: minimum mandatory sizes for publication are 6.5" (iPhone 14 Pro Max or equivalent) and 5.5" (iPhone 8 Plus). Uploading only one size forces Apple to scale for others, degrading listing visual quality. For iPad, a separate set is required if the app supports iPad.
Privacy: a link to a Privacy Policy is mandatory today. Without it, rejection under Guideline 5.1.1. Also fill out Privacy Nutrition Labels in App Store Connect—what data is collected, for what purpose, whether linked to identity.
Archiving and Upload
# Via Fastlane fastlane pilot upload --ipa ./build/App.ipa # Or via xcodebuild + Transporter xcodebuild archive \ -scheme MyApp \ -archivePath ./build/MyApp.xcarchive \ -configuration Release xcodebuild -exportArchive \ -archivePath ./build/MyApp.xcarchive \ -exportPath ./build/export \ -exportOptionsPlist ExportOptions.plist ExportOptions.plist is a key file. An incorrect method (app-store vs ad-hoc vs development) will create a build but not suitable for upload.
<!-- ExportOptions.plist for App Store --> <?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"> <dict> <key>method</key> <string>app-store</string> <key>teamID</key> <string>YOURTEAMID</string> <key>uploadBitcode</key> <false/> <key>compileBitcode</key> <false/> </dict> </plist> Bitcode is deprecated with recent Xcode versions—Apple removed it. If the project has old settings with ENABLE_BITCODE = YES, archiving will produce warnings.
Using Fastlane reduces release preparation time by a factor of 3–5 compared to manual archiving—especially useful for frequent fixes. On our projects, Fastlane saves $300–$750 per release by cutting manual effort.
| Step | Manual Method | Fastlane |
|---|---|---|
| Archiving | xcodebuild archive | fastlane gym |
| Signing | manual codesign | automatic sign |
| Upload | Transporter | fastlane pilot |
| Time | 20–30 min | 3–5 min |
Why App Store Review Rejects Apps
Review takes from a few hours to 2–3 days. Common reject reasons:
Guideline 2.1 — App Completeness: app crashes, demo account doesn't work, buttons lead nowhere. Test on a real device, not just simulator. Provide a test account in Notes to App Review.
Guideline 4.3 — Spam / Copycat: app too similar to another or has too little functionality. A new app from the same developer duplicating an already published one also triggers 4.3.
Guideline 5.1.2 — Data Use and Sharing: requesting NSCameraUsageDescription but not actually using the camera—rejection. Description must match actual usage.
In-App Purchase: if the app has any paid content or subscriptions, they must use Apple IAP, not third-party payment systems. Attempting to accept payment via Stripe for digital content leads to rejection under Guideline 3.1.1.
| Guideline | Typical Cause | Solution |
|---|---|---|
| 2.1 | App incomplete or crashes | Thorough testing on real devices, providing demo access |
| 4.3 | Copying or spam | Unique functionality, differences from analogs |
| 5.1.2 | Data usage description mismatch | Correct description of NSCameraUsageDescription and other keys |
| 3.1.1 | Bypassing Apple IAP | Use StoreKit 2 for digital goods |
How to appeal a rejection?
Use the Resolution Center in App Store Connect. Explain why the decision is unfair and provide evidence. Apple Developer Relations replies within 1–3 days. Appeals work: formal rejections with proper justification are often overturned.Version Management and Phased Release
After approval: choose between immediate release or Phased Release. Phased Release gradually rolls out an update: 1% → 2% → 5% → 10% → 20% → 50% → 100% of users over 7 days. This allows catching critical bugs before mass update.
You must increment the version and build number with each new upload. CFBundleShortVersionString (visible, e.g., 2.1.0) and CFBundleVersion (build number, only increases). A duplicate build number will cause Transporter to refuse the upload.
What's Included in the Publication Work
- Creating and configuring the App Store Connect record (Bundle ID, rights, categories)
- Preparing screenshots for all required sizes
- Configuring ExportOptions.plist and code signing
- Uploading the build via Fastlane or Transporter
- Supporting the review: answering questions, fixing issues
- Setting up Phased Release and monitoring initial reviews
- Providing documentation and access (App Store Connect, TestFlight)
Process
- Prepare App Store Connect: create record, Privacy Policy, Nutrition Labels, screenshots
- Configure archiving: Signing Config, ExportOptions.plist, verify entitlements
- Upload build via Transporter or Fastlane, fill metadata
- Support through review: respond to reviewer questions, fix issues
Timeline Estimates
Preparation and first submission of a ready app: 1–2 days. Including Apple review (usually 1–3 days): 3–5 business days until publication. If rejected and need fixes: add 1–3 more days.
We have been publishing apps on the App Store for over 5 years and know all the nuances. We guarantee a first-time pass through review if our recommendations are followed. If you need help with publication, we can assess your project and prepare everything for the App Store. Contact us to get started.