iOS Build Failing (2019.3.0f1 / Xcode 11.2.1)

We’re seeing an odd failure in our logs for 2019.3 builds; the Player export succeeds, but during the IPA generation process, we see this failure:

6552: error: exportArchive: IPA processing failed
6553: Error Domain=IDEFoundationErrorDomain Code=1 “IPA processing failed” UserInfo={NSLocalizedDescription=IPA processing failed}

Everything else in the log indicates things moving along smoothly, and we can safely build the player on a local computer with the same setup, so we’re pretty confident the code is in good shape at this point.

1 Like

Any chance someone can look into this? Still an issue.

@victorw This continues to be an issue for us – seems to be an issue with fastlane and/or something after the build export process.

6515: ▸ Touching wearableunity.app
6516: ▸ Signing /BUILD_PATH/Library/Developer/Xcode/DerivedData/Unity-iPhone-bzkmasgwdeteggapnathfwwqajew/Build/Intermediates.noindex/ArchiveIntermediates/Unity-iPhone/InstallationBuildProductsLocation/APPLICATION_PATH/wearableunity.app
6517: ▸ Touching wearableunity.app.dSYM
6518: ▸ Archive Succeeded
6519: Generated plist file with the following values:
6520: ▸ -----------------------------------------
6521: ▸ {
6522: ▸   "method": "development",
6523: ▸   "uploadSymbols": false,
6524: ▸   "provisioningProfiles": {
6525: ▸     "com.zapdot.demo.wearableunity": "[REDACTED]"
6526: ▸   },
6527: ▸   "signingStyle": "manual",
6528: ▸   "teamID": "73H2ZK62U7"
6529: ▸ }
6530: ▸ -----------------------------------------
6531: RVM detected, forcing to use system ruby
6532: Now using system ruby.
6533: error: exportArchive: IPA processing failed
6534: Error Domain=IDEFoundationErrorDomain Code=1 "IPA processing failed" UserInfo={NSLocalizedDescription=IPA processing failed}
6535: ** EXPORT FAILED **
6536: Exit status: 70
6537: +---------------+-------------------------------+
6538: |               Build environment               |
6539: +---------------+-------------------------------+
6540: | xcode_path    | /APPLICATION_PATH/Xcode11_2_1.app |
6541: | gym_version   | 2.135.2                       |
6542: | export_method | development                   |
6543: | sdk           | iPhoneOS13.2.sdk              |
6544: +---------------+-------------------------------+
6545: ▸     cd /BUILD_PATH/zapdot-inc.aura-plugin.demo-ucb-ios-20193/Unity/temp20191216-3139-1s61ra5
6546: ▸     export PATH="/APPLICATION_PATH/Xcode11_2_1.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/APPLICATION_PATH/Xcode11_2_1.app/Contents/Developer/usr/bin:/BUILD_PATH/.rvm/gems/ruby-2.4.2/bin:/BUILD_PATH/.rvm/gems/ruby-2.4.2@global/bin:/BUILD_PATH/.rvm/rubies/ruby-2.4.2/bin:/BUILD_PATH/.rvm/bin:/BUILD_PATH/.nvm/versions/node/v10.16.3/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/UNITY_PATH/Unity/p4/macos:/usr/local/bin:/UNITY_PATH/Unity/p4/macos:/UNITY_PATH/Unity/android/sdk_29_0_0:/UNITY_PATH/Unity/p4/macos/:/UNITY_PATH/Unity/p4/windows/"
6547: ▸     /usr/bin/touch -c /BUILD_PATH/Library/Developer/Xcode/DerivedData/Unity-iPhone-bzkmasgwdeteggapnathfwwqajew/Build/Intermediates.noindex/ArchiveIntermediates/Unity-iPhone/BuildProductsPath/Release-iphoneos/wearableunity.app.dSYM
6548: ▸ ** ARCHIVE SUCCEEDED **

Have you submitted a support ticket for this?

I have not! I always wondered if the desired vector for reporting these issues was the forums or something else. I’ll absolutely do this.

Edit: Ticket #756018

Thanks!

Forums are useful since other users might be encountering the same issue and might even know how to resolve it. If you’re pretty sure that your issue is unique and you just need someone at Unity to stare at your logs then support tickets are preferable. The support ticket gives us a lot of extra information that we need and it attracts the attention of our support engineers who are more experienced with this kind of investigation.

1 Like

I had the same issue on the same versions of Unity and Xcode where archive succeeded but export failed with an “IPA processing” error like the one reported above.

In my case it was insufficient hard disk space. As soon as I freed up some space I was able to export the build successfully. If that is the case, a more meaningful error would have been appropriate.

Just wanted to report back on this one, in case anyone else runs into this issue.

It turned out that this started failing on 2019.3 exports when you use PBXProject to set a build property for the ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES key to True.

Oddly enough, this only causes an issue for 2019.3, and does not cause any issues with project exports in 2017.4, 2018.1, 2018.2, 2018.3, 2018.4, 2019.1, and 2019.2.

1 Like

the issue is claimed as fixed for 2019.3 but still having issues with 2019.3.1f1 and 2019.3.2f1

Thanks for posting the issue tracker link - I talked to the mobile team and confirmed that the milestone was set incorrectly for that issue tracker resolution (it is actually only fixed in 2020.1 currently). I’ve now requested a backport for this issue to be resolved in 2019.3.

If anyone does want to try out 2020.1 in the meantime then please let me know. I’ve just put the latest 2020.1 alpha into testing so we can hopefully enable it soon for anyone who wants to have alpha access configured.

This is also blocking us completely from upgrading to 2019. We cannot upgrade to 2020 since we use cloud build and some other things would break with 2020.

Ive been looking at each update to 2019.3 but as of 2019.3.5 this is not resolved(atleast in the changelog)… Can we please get an update on this?

Ran into this same error via a cloud build target to 2019.3.5 , will update on any solutions I stumble upon

Has this problem been solved on 2019.4?

Hello??? Any news??

@victorw

This was fixed in 2019.3.12f1 and as far as I know it is still fixed in 2019.4

Thanks for the reply.

Ill try that.

still have the same problem in Unity 2020.1.16f1 , Unity 2020.1.17f1

can someone help please ?

Today we decide to migrate our project to 2020.2.0, it was 2019.4.0 before and things work fine. Now I have to google pages trying to find out a solution. But never mind, since every time we upgrade our project to a new version, nightmare comes, we are used to it.

My team is running into this issue using 2020.1.14f1. Our builds were working fine until a few weeks ago but we are all scratching our heads now. Is there general information that can be given to understand why this might be happening?

Check full logs, might be a clue there.