It happened before and shall happen again: xcrun PackageApplication doesn’t work anymore.
The whole process isn’t meant for contractors
Let’s face it, Xcode is getting better at the coding part, but the signature / IPA generation is “streamlined” for the App Store, which in turn is under a lot of assumptions that I’ve mentioned here in the past. Since the last time, the heavy push for storyboards (oh, the tasty git conflicts), and the weird quirks of swift haven’t really improved things. Dev tools should be as flexible as possible, because they are meant for devs.
Anyways, 8.3 broke the “easy” IPA generation that everyone was using. It was especially important for Hudson/Jenkins continuous integration and beta deliveries. No, relying on the Organizer’s UI doesn’t work, because more often than not, you want automation, and Xcode is less and less automatable.
PackageApplication is gone
It worked for a while, then you had to remove a part of the entitlement checking, but now it’s not there anymore. So… no more Hudson builds?
Fret not! The one-liner may be gone, but we have a heavily convoluted multi-step export process in place that does the same!
(Imaginary tech support person)
The idea is to replicate the UI process:
- generate an archive
- click export an IPA
- select a bunch of signature and type options
- rename all the things it exported (you usually want the build number/version right)
Believe it or not, some of these are actual
xcodebuild commands. But the argument list is… errrrr, weird, if you’re used to Linux and server stuff. So, no, in the following, it’s not a mistake that there’s only one dash. You have been warned.
There are two pieces to the export thing : a plist containing what you would type/click in the UI options at the end of the process, and a script that chains all the necessary actions together. I tried to piece together various sources into a coherent whole, but it’s a dev tool and your mileage may vary. Also, because it’s intended as a Hudson build script, it takes the version number as argument and outputs what I would upload to the beta server in
Outfiles. Again, adapt it to your workflows.
< !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>development</string> <key>teamID</key> <string>TEAM_ID</string> <key>uploadBitcode</key> <true></true> <key>uploadSymbols</key> <true></true> </dict> </plist>
Remember to use the correct
TEAM_ID in there.
The script (takes the version as first argument, may break if none is provided):
#!/bin/bash APP_NAME="Insert app name here" SCHEME_NAME="Insert scheme name here" CONFIGURATION="Insert configuration name here" ARCHIVE_DIRECTORY=Archives OUT_PATH=Outfiles #change as needed SDK=iphoneos10.3 echo "Cleaning previous build" #clean xcodebuild -sdk "$SDK" \ -scheme "$SCHEME_NAME" \ -configuration "$CONFIGURATION" clean echo "Creating Archive" #archive xcodebuild -sdk "$SDK" \ -scheme "$SCHEME_NAME" \ -configuration "$CONFIGURATION" \ -archivePath "$ARCHIVE_DIRECTORY/$APP_NAME-$1.xcarchive" \ archive echo "Creating IPA" #export ipa xcodebuild -exportArchive \ -archivePath "$ARCHIVE_DIRECTORY/$APP_NAME-$1.xcarchive" \ -exportPath "$OUT_PATH/" \ -exportOptionsPlist exportIPA.plist #name files and dSYMs mv "$OUT_PATH/$APP_NAME.ipa" "$OUT_PATH/$APP_NAME-$1.ipa" cp -rf "$ARCHIVE_DIRECTORY/$APP_NAME-$1.xcarchive/dSYMs/$APP_NAME.app.dSYM" "$OUT_PATH/$APP_NAME-$1.dSYM" cd "$OUT_PATH" zip -r "$APP_NAME-$1.dSYM.zip" "$APP_NAME-$1.dSYM" rm -rf "$APP_NAME-$1.dSYM" cd .. #optionally # rm -rf Archives
As usual, use with wisdom ;)
It’s not that the system is bad, per se. It actually makes a lot of sense to have commands that mirror the GUI. But the issue is, for a long long long long time, automation hasn’t been about simulating clicks. Since you don’t have the UI, it makes even more sense to have shortcuts in addition the GUI counterparts