Errors converting xcarchive to IPA - single-bundle archive + missing plist method values

Question

I'm trying to convert my xcarchive to an IPA (XCode 7.1.1). The following command

xcodebuild 
    -exportArchive -archivePath foo.xcarchive -exportPath . -exportFormat IPA

Fails with the error

the archive at path 'foo.xcarchive' is not a single-bundle archive

Since the above command is technically deprecated, I also tried the new form:

xcodebuild 
    -exportArchive -archivePath foo.xcarchive -exportPath . 
    -exportOptionsPlist ipa.plist

Where the ipa.plist is as follows:

<?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</string>
</dict>
</plist>

Which then resulted in the error:

error: exportArchive: exportOptionsPlist error for key 'method': expected one of {}, but found app-store

Now, trying to debug this I opened the xcarchive folder and inspected its structure. I noticed that I have a folder on the same level as Products\Applications\foo.app so I deleted it and tried again to no avail (same results). I then proceeded to delete files from within foo.app until I remained with nothing but the DWARF binary - still no cigar (same result), though that could have been due to the fact that I messed up the app signature by deleting files manually.

Collapse

Are you sure the archive has been correctly found? Try to use absolute paths everywhere. – Autotoxin

@Autotoxin I'm sure because when I ended up deleting the .app itself inside the archive the error changed, so I know it's looking in the right place. – Collapse

Answer 1

The problem was that one of our post-build steps left a stray folder in the TARGET_BUILD_DIR. This caused the generated xcarchive to be formatted as the dreaded generic archive. My attempts to delete the folder after the fact from the xcarchive itself were doomed to fail since the xcarchive has been flagged generic at the moment of its creation (as evidenced by some missing Info.plist fields). Once I made sure TARGET_BUILD_DIR contained only the .app after all the build phases were said and done, the generated xcarchive was formatted properly as an iOS app archive. That xcarchive, in turn, was easily exported to a proper IPA via xcodebuild -exportArchive -exportPlistOptions, which is the officially supported Apple recommendation that takes care of all the problematic SWIFT support folders and the like.

Collapse

Hi, I am trying to solve the same problem, can you please tell me, how and where did you changed the TARGET_BUILD_DIR? My problem seems pretty similar, I have reduced Info.plist and in folder Products I have 2 folders -> Applications (which I want) and Users/... with some exported headers and libs, which I don't want. Thank you really much for your help! – Broccoli

Answer 2

Apple got back to me with a solution. As of Xcode 7 we should use xcodebuild instead of PackageApplication to produce the .ipa file.

xcodebuild has a new -exportArchive option to create an .ipa that works more like Xcode Organizer.

So we should now:

1. build an archive with xcodebuild archive

2. create the .ipa with xcodebuild -exportArchive

We now build the archive like this:

xcodebuild -workspace myApp.xcworkspace -scheme myApp -sdk iphoneos -configuration AppStoreDistribution archive -archivePath $PWD/build/myApp.xcarchive

We now export the .ipa like this:

xcodebuild -exportArchive -archivePath $PWD/build/myApp.xcarchive -exportOptionsPlist exportOptions.plist -exportPath $PWD/build

These two command create the files build/myApp.xcarchive and build/myApp.ipa

Note that xcodebuild -exportArchive requires a -exportOptionsPlist argument that points to a .plist file with export options. For a complete list of what you can put in that plist, run xcodebuild -help. The minimal contents of the file looks like this:

<?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</string>
    <key>teamID</key>
    <string>YOUR_TEN_CHARACTER_TEAM_ID</string>
</dict>
</plist>

Loria

Have you read the question? This is exactly what I'm doing. The export command doesn't work, and I'm trying to figure out why. It seems it's due to multiple folders being created in the Product/Applications folder and an info.plist that's missing some values in the root. – Collapse

Answer 3

Since the way you are creating an IPA is deprecated, you should do the following instead:

xcodebuild -scheme "Foo" -configuration Release clean build CODE_SIGN_IDENTITY="iPhone Distribution: Foo Corporation" -derivedDataPath "/path/to/some/folder/"

xcrun -sdk iphoneos PackageApplication "/path/to/some/folder/Build/Products/Release-iphoneos/foo.app" -o "/path/to/some/folder/foo.ipa"

Make sure you replace "Foo" with your schema name, and "iPhone Distribution: Foo Corporation" with your signing identity. And "/path/to/some/folder/" should be some build folder.

Mandragora

xcodebuild -exportFormat is deprecated, yes, but PackageApplication is deprecated too :) It creates packages that are rejected from the App Store due to a deprecated plist value (CFBundleResourceSpecification, #32763788), and in the case of swift use, missing SwiftSupport folder (encyclopediaofdaniel.com/blog/xcarchive-to-ipa). The officially supported way is xcodebuild -exportOptionsPlist but unfortunately I can't get it to work so I'm using workarounds... – Collapse

The workarounds being: (1) modify PackageApplication manually (as detailed in link) (2) Copy SwiftSupport folder using a somewhat hacky script (github.com/bq/ipa-packager). – Collapse

And just to clarify - the xcarchive itself does not suffer from the issues I mentioned above (CFBundleResourceSpecification, SwiftSupport) but it doesn't do me much good as long as I can't produce a proper IPA from it. – Collapse

Answer 4

Try using absolute paths as parameters to xcodebuild options rather than relative paths.

So something like this:

xcodebuild -exportArchive -archivePath "$PWD/foo.xcarchive" \
-exportPath "$PWD" -exportOptionsPlist "$PWD/ipa.plist"

As long as your .xcarchive is intact and signed correctly, that should work. This is what I'm using in my build system.

Issuable

it's not it, it seems there is a problem in the xcarchive that has to do with an invalid plist file and multiple folders in the Product/Applications path. – Collapse

Answer 5

I got some similar strange errors from XCode 7.2 when building for the simulator on the command line. You could try to either add -sdk iphoneos to your xcodebuild command (in order to skip simulator builds), or add something like -destination 'platform=iOS Simulator,name=iPhone 6,OS=latest' if you're building for the simulator.

Washedup

I can't use -sdk iphoneos because I have a watch target that uses the Watch OS. – Collapse

Answer 6

I recently switched to using the fastlane gym tool to build and create ipa files... I had a problem where one command line worked for making ad-hoc builds and I needed a different config to make app store builds and couldn't resolve it. The fastlane stuff pretty much worked out of the box.

https://github.com/fastlane/gym

Arethaarethusa

I actually need the xcarchive - can gym do that? – Collapse

I think it does... The site says: "All archives are stored and accessible in the Xcode Organizer". – Arethaarethusa

I've awarded you the bounty since this is the most appropriate answer, though it is unlikely I will go this route due to past experience with "xcodebuild wrappers" - it's just a matter of time until they break with a new xcode release and/or certain build features you're using.I also doubt gym will solve my problem here, which is probably due to some folder generated in the target directory in one of our build phases. – Collapse

Thanks! I think the fastlane tools are getting some momentum, so they stand a good chance of passing the test of time. There's a bunch of other useful stuff there for other annoying processes too, like provisioning profiles, and automating screen shot generation. Hope you have success in your quest! – Arethaarethusa

Thanks, but that's what they said about xctool, and when we moved to XCode 7 we eventually had to drop it... We'll stick with xcodebuild and xcpretty for now :) – Collapse

The gym thing is useful, but I agree with you it'd be nicer to just use Apple native commands. You can use gym output to decipher what xcodebuild invocations it's doing underneath though. It's all about calling xcrun and xcodebuild – Crystacrystal

Answer 7

The archive at path foo.xcarchive is not a single-bundle archive.

About this error:

1. check edit scheme -> Build
2. untick other targets, including Analyze, Test, Run, Profile, Archive
3. xcodebuild the archive
4. export the archive again

Vinnie