This episode covers app distribution: uploading iOS apps to the App Store, beta testing with TestFlight, deploying to macOS, watchOS, and tvOS, plus the correct code signing, notarization, and release management process from archive to production.

All your hard work culminates here: the app reaches users' hands. Episode 20 covers deployment and app distribution — from archive, to beta testing with TestFlight, to uploading to the App Store and distributing to macOS, watchOS, and tvOS.
Clean distribution isn't just about pressing the Upload button. Behind it are correct code signing, notarization for user security, and release management that makes rollbacks and gradual releases easy.
The distribution artifact is produced through an archive (episode 18). Before archiving, make sure the version number and build number are updated — both must increment on every release:
xcodebuild archive \
-scheme Aplikasi \
-archivePath ./build/Aplikasi.xcarchive \
-configuration Release \
-allowProvisioningUpdatesxcodebuild archive ... -allowProvisioningUpdates produces a .xcarchive containing the app along with its metadata and symbols. This archive is the starting point for every distribution path — App Store, TestFlight, or ad-hoc.
From the archive, the app is exported to a distribution format and then uploaded:
xcodebuild -exportArchive \
-archivePath ./build/Aplikasi.xcarchive \
-exportPath ./export \
-exportOptionsPlist exportOptions.plistxcodebuild -exportArchive -exportOptionsPlist ... turns the archive into an .ipa according to the options in exportOptions.plist — for example uploadBitcode and method set to app-store. Upload to App Store Connect is done through Xcode Organizer or Fastlane.
TestFlight is Apple's beta testing service. Uploaded builds can be distributed to external and internal testers:
TestFlight builds also provide crash data and tester feedback. Use this phase to validate on real devices before the general release.
Fastlane simplifies this step — episode 18 introduced the beta lane:
bundle exec fastlane betabundle exec fastlane beta runs the lane that builds, signs, and uploads the build to TestFlight. This automation means every commit on a given branch produces a fresh beta build with no manual intervention.
For macOS apps, Apple requires notarization: the app must be checked by Apple before users can run it outside the App Store. The process is run with notarytool:
xcrun notarytool submit Aplikasi.dmg \
--keychain-profile "notary-profile" \
--waitxcrun notarytool submit Aplikasi.dmg --wait submits the app for Apple's automated security check and waits for the result. Once approved, stapler attaches the receipt so the app runs without an "unidentified developer" warning.
Deploying to watchOS and tvOS follows the same path — App Store Connect accepts builds for all three platforms, with differences:
Design a pipeline that handles several targets from the start — for example, one Fastlane lane per platform, or one lane with parameters.
Healthy release practices include:
Every build submitted to the App Store goes through review. To smooth the process:
Warning
Use phased release for new builds. If crashes or complaints appear in the first wave, you can pause the release before the impact spreads — control that a simultaneous release doesn't have.
Key takeaways:
In the next episode, episode 21, we'll cover observability and production support — crash reporting and analytics in Swift apps, logging, telemetry, and performance monitoring, health checks and user feedback loops, plus incident response and release rollback. Your apps become clear in production!