ExportOptions.plist generator and checker
Choose how the archive should leave your Mac and get an ExportOptions.plist that xcodebuild accepts, with the archive and export commands to go with it. Or paste the file your build server uses and see what xcodebuild will stop on, what it quietly ignores, and which old names to update. Nothing is uploaded.
Keys, types and defaults are from xcodebuild -help in Xcode 27.1, checked on 2026-10-31. Which methods each archive accepts, and which can upload, were checked by exporting real iOS and Mac archives.
ExportOptions.plist
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>method</key> <string>app-store-connect</string> <key>destination</key> <string>export</string> <key>signingStyle</key> <string>automatic</string> <key>uploadSymbols</key> <true/> <key>manageAppVersionAndBuildNumber</key> <true/> </dict> </plist>
Save it next to your project and pass it with -exportOptionsPlist. Keys that do not apply to the chosen method are left out.
Commands
1. Archive
xcodebuild archive \ -scheme YourScheme \ -destination 'generic/platform=iOS' \ -archivePath build/YourApp.xcarchive
2. Export
xcodebuild -exportArchive \ -archivePath build/YourApp.xcarchive \ -exportPath build/export \ -exportOptionsPlist ExportOptions.plist \ -allowProvisioningUpdates
All 18 keys xcodebuild reads
- method string
- How the archive is exported. Defaults to debugging.
- destination string
- export writes files to -exportPath; upload sends the build to Apple. Defaults to export.
- teamID string
- The developer team for this export. Defaults to the archive's team.
- signingStyle string
- manual, or managed by Xcode. Defaults to the style the archive was signed with.
- signingCertificate string
- Manual signing only: certificate name, SHA-1 hash or a name that picks the newest installed one.
- provisioningProfiles dict
- Manual signing only: bundle identifier → profile name or UUID, for the app and each extension.
- installerSigningCertificate string
- Mac packages only: the installer certificate, such as Mac Installer Distribution.
- uploadSymbols boolean
- App Store exports: include symbols. Defaults to YES.
- manageAppVersionAndBuildNumber boolean
- App Store exports: Xcode manages the build number when uploading. Defaults to YES.
- testFlightInternalTestingOnly boolean
- App Store exports: the build can only go to internal TestFlight testers.
- generateAppStoreInformation boolean
- App Store exports: write App Store information for iTMSTransporter. Defaults to NO.
- stripSwiftSymbols boolean
- Strip symbols from Swift libraries in the .ipa. Defaults to YES.
- iCloudContainerEnvironment string
- Development or Production for CloudKit. Defaults to the one that matches the signing.
- distributionBundleIdentifier string
- Export only the target with this bundle identifier. Defaults to the top-level one.
- thinning string
- Outside the App Store: <none>, <thin-for-all-variants>, or a device such as iPhone7,1.
- manifest dict
- Outside the App Store: appURL, displayImageURL and fullSizeImageURL for installing over the web.
- embedOnDemandResourcesAssetPacksInBundle boolean
- Outside the App Store: put on-demand resources inside the app.
- onDemandResourcesAssetPacksBaseURL string
- Outside the App Store: where on-demand resource packs are hosted.
How it works
- •Every key comes from the list xcodebuild -help prints in Xcode 27.1, with its type and default.
- •We exported real iOS and Mac archives with the files this page writes, and with broken ones, to see what xcodebuild really does. A wrong value type stops the export. An unknown or misspelled key is ignored without a word. iOS archives take app-store-connect, release-testing, enterprise, debugging and validation; Mac archives take app-store-connect, developer-id, debugging, mac-application and validation.
- •Only keys that apply to the chosen method and signing are written, so the file says what it does. App Store switches are written even at their defaults.
- •The checker reads a pasted or dropped file, flags old method names (app-store, ad-hoc, development), bitcode keys, keys in the wrong case, upload with a method that cannot upload, manual-signing keys that will be ignored, and keys that only apply to the other kind of export.
What it does not do
- •It cannot see your keychain or developer account. Whether the certificate and profiles exist is checked by xcodebuild when it signs.
- •It does not read binary plists. Convert with plutil -convert xml1 first.
- •Commands use placeholder paths and environment variables; change YourScheme and the paths to match your project.
Questions
- What is ExportOptions.plist?
- The property list that xcodebuild -exportArchive -exportOptionsPlist reads to turn an .xcarchive into an .ipa, a Mac app or a package, or to upload it. It sets the distribution method, signing, and a few options such as symbols and the build number.
- What replaced app-store, ad-hoc and development?
- app-store-connect, release-testing and debugging. Xcode still accepts the old names for iOS archives, but a Mac archive refuses ad-hoc.
- Can xcodebuild upload straight to App Store Connect?
- Yes. Set method to app-store-connect and destination to upload, and run the export with -allowProvisioningUpdates. On a build server, sign in with an App Store Connect API key using -authenticationKeyPath, -authenticationKeyID and -authenticationKeyIssuerID.
- Why does my export fail with “Failed to decode … Expected to decode Bool”?
- A value has the wrong type, for example <string>YES</string> where xcodebuild wants <true/>. Paste the file into the checker to see which key.
- Do I still need compileBitcode or uploadBitcode?
- No. Xcode 14 removed bitcode, and current xcodebuild ignores both keys. Delete them.
- Where can I find the ExportOptions.plist Xcode used?
- When you distribute an iOS app from the Organizer and export it to a folder, Xcode writes ExportOptions.plist next to the .ipa. It is a good starting point for a build server.