iOS build issues should be resolved (and Unity 2019.1.4f1 now available)

As you might be aware, 2019.1.3f1 experienced a lot of build failures recently which could be worked around by switching your Unity target version to 2019.1.2f1. Fortunately I can report that I tracked down what I believe to have been the main cause of these issues and iOS build failures should now be back to normal.

This means that you can go back to targeting 2019.1.3f1 if you want, or return to targeting "Always Use Latest 2019.1" versions - which now targets 2019.1.4f1. We have recently had several unexpected breakages from releasing new Unity versions however. We have a few features coming soon to make it easier to detect and avoid breakages introduced by new Unity versions. We'll also be making our testing suite for new Unity version releases more extensive and automatic.

If you are still experiencing iOS build issues in 2019.1.4f1 then please feel free to post here or open a support ticket - and if you were previously experiencing issues which went away when switching down to 2019.1.2f1 then it would be good to know if these are now resolved in 2019.1.4f1. Tracking down the replication for this issue was very tricky - although I believe that the majority of new iOS issues should be resolved now, I definitely want to keep a close eye on things and make sure that this has worked for all of our customers.

 

It would be nice to have a quick way to see what latest version of Unity will be used in a build, e.g. I just verified in the dashboard that my Latest 2019.1x build will indeed use 2019.1.4 by clicking the Edit button on a config and pulling up the version popup. I don't know of any easier way to do that (except just starting a build and seeing what shows up in the log).

 

Yep, that's one of the major things we're currently looking at adding to help users determine what's going on with the "always use latest" versions. We're also looking at an alternative config option which would attempt to lock your Unity version to always use the exact same version you are running locally.

In the long term things should just go back to normal where we very rarely experience breakages due to minor/point releases. As you might be aware though Unity is currently going through a large set of major refactors in several areas. Mostly this is being done to improve stability and performance in the long term but it's been generating a few short term issues recently as things shift over.

 

Thanks for the quick reply! My use case typically is I want to start a build as soon as I know there’s a new Latest on UCB, maybe even before I update locally so I know beforehand if there are any issues.

 

I'm currently looking into a few cases where my fix isn't working the same in production as it did when I was running this in our internal testing environment - I'm hoping that between this fix and the release of 2019.1.4f1 things should still be improved on this front but I may have been too soon to declare that the issues "should be fixed"

 

Hi there, I was having issues with building for iOS using 2019.1.3f1 but this issue went away when switching back to building with 2019.1.2f1 as suggested in other posts.

I have now tried building with 2019.1.4f1 but it still won't build correctly, 2019.1.2f1 however still builds without any issues. (I am using local version 2019.1.4f1).

19451: ** ARCHIVE FAILED **
19452: The following build commands failed:
19453: PhaseScriptExecution Process\ symbols /BUILD_PATH/Library/Developer/Xcode/DerivedData/Unity-iPhone-cgefkcbbbagkeyeecpnyrnwuwoqa/Build/Intermediates.noindex/ArchiveIntermediates/Unity-iPhone/IntermediateBuildFilesPath/Unity-iPhone.build/Release-iphoneos/Unity-iPhone.build/Script-A212493586CB60A457B0E1CD.sh
19454: (1 failure)
19455: Exit status: 65


And also...

19477: ▸ time="2019-05-31T00:59:10Z" level=fatal msg="Please provide an auth token with USYM_UPLOAD_AUTH_TOKEN environment variable"
19478: ▸ Command PhaseScriptExecution failed with a nonzero exit code

 

I was having issues for iOS building with 2019.1.3 and am having the same issue with 2019.1.4.
Still getting `Exit status: 65` error.

 

We are seeing the same as as above with 2019.1.4 as well

 

I can also confirm that the building for iOS is NOT working with 2019.1.4f1.

2019.1.2 works, but builds take a very long time (like 30min to over 1hour). Other platforms build in 7-15 minutes.

 

I'm also still getting errors with iOS build on both 2019.1.3 and 2019.1.4, with 2019.1.2 succeeding.

Spoiler

Code (csharp):

1.  
2. 13652: ** ARCHIVE FAILED **
3. 13653: The following build commands failed:
4. 13654: PhaseScriptExecution Process\ symbols /BUILD_PATH/Library/Developer/Xcode/DerivedData/Unity-iPhone-dejchgrghvxdagejbiekjfhbhlto/Build/Intermediates.noindex/ArchiveIntermediates/Unity-iPhone/IntermediateBuildFilesPath/Unity-iPhone.build/Release-iphoneos/Unity-iPhone.build/Script-7ABC4DC18A736FB0802C4DAE.sh
5. 13655: (1 failure)
6. 13656: Exit status: 65
7.  
8. ...
9.  
10. 13677: ▸     /bin/sh -c /BUILD_PATH/Library/Developer/Xcode/DerivedData/Unity-iPhone-dejchgrghvxdagejbiekjfhbhlto/Build/Intermediates.noindex/ArchiveIntermediates/Unity-iPhone/IntermediateBuildFilesPath/Unity-iPhone.build/Release-iphoneos/Unity-iPhone.build/Script-7ABC4DC18A736FB0802C4DAE.sh
11. 13678: ▸ time="2019-05-31T11:06:01Z" level=fatal msg="Please provide an auth token with USYM_UPLOAD_AUTH_TOKEN environment variable"
12. 13679: ▸ Command PhaseScriptExecution failed with a nonzero exit code
13.  

 

There was a configuration issue in our production service which interfered with the fix I deployed - I just deployed a hotfix to bypass that code and so far all my test builds are succeeding.

I'm a bit reluctant to call it "fixed" since that backfired on me last time but it's looking good so far.

 

I've just completed a build using 2019.1.4f1 and can confirm that it's all working as expected now.

Thanks so much for getting this sorted so quickly!!

 

Hi, I know that this is out of topic for Cloud Build, but Unity 2019.1.5f1 makes build error (USYM_UPLOAD_AUTH_TOKEN) when I run batchmode for building iOS player. I think the issue is related to this thread. Any ideas?

 

I'm also having same issue on iOS Player Build, both on 2019.1.4f1 and 2019.1.5f1.

 

@Kichang-Kim (EDIT: deleted my bad advice, see fatswallow_bside for the correct answer.) That said, if you could report this bug along with detailed replication steps through the editor (Help -> Report a Bug) then that would be a great help for identifying why this is happening and resolving it once and for all. I have already mentioned this issue to the Game Performance Reporting team but having more reliable and detailed replication steps is always useful for fixing strange bugs like these.

@fatswallow_bside are you also experiencing this issue locally when running in batchmode, or is it happening in UCB?

 

I'm running it in Batchmode, and I just resolved it by giving -username and -password option on command line. It looks like "Unity not installed by Unity Hub" is somehow failing to fetch userid/password, thus USYM_UPLOAD_AUTH_TOKEN value is not provided.

 

Yeah sorry, that's the correct advice and it should work just fine - ignore what I said! The confusing part (which is presumably an editor bug) is that USYM_UPLOAD_AUTH_TOKEN is expected for iOS builds even when you are not using Game Performance Reporting. But yes using the -username and -password options is the correct way to resolve it.

 

Hi,
I'm having this exact issue but I'm not using Unity Cloud Build.
I have a username and password in the command line and that's not fixing the issue on Unity 2019.1.3f1, would you have a fastlane (that's what we use in our CI) fix or other clues as to why it's not working ?

Thanks!

 

I saw in other threads people talking about the CrashReporting being a possible cause for this ? If that issue come from Unity Services we will be forced to disable it on all our projects until it's fixed.
Also tested on 2019.1.5f1 and it's not working either.
It seems like it's not coming from the CI or fastlane but really from some env variable that should have been set.
Any help on this issue would be life saving, thanks!

 

My bad advice which I deleted was to define the env variable

USYM_UPLOAD_AUTH_TOKEN

to be an arbitrary string. Switching to an arbitrary string will of course break crash reporting but it should allow builds to go through successfully. Unfortunately I can't be much more help than that, the username and password is the correct approach for customer use and should be working - reporting a bug is your best bet for getting this resolved properly.

 

What I don't get is why it would work on 19.1.2 and not the other versions with the exact same build pipeline. Is USYM_UPLOAD_AUTH_TOKEN a new thing ?
I may have a clue on why it's not working (switching bash env between the Unity build and the XCode build) and, in my opinion, the XCode build should not rely on env variables set only once after a build is triggered. The risks are high that that env variable would be lost during the archiving (which I think is what's happening to our project).

 

Don't want to be an entitled user just waiting and not searching solutions by myself so I looked again at my logs and tried to diff them: like always it's the user's fault. It appears we were using the wrong username / password for that specific project so it wasn't working at all.

Conclusion:
- having -username in the command line is the workaround for that issue
- there is no real environment variable issue since the token is saved inside the .xcodeproj generated

Still, I feel like the Unity build should fail if the token can't be fetched since it will prevent the XCode project to be archived.

 

HI, it seems I'm experiencing the same issue in UCB. I've tried to rebuild it with 2018.3.4, Latest 2018.4, 2019.1.2f1, Latest 2019.2 fro the last 3 days. No success still the same error:
19139: ▸ ** ARCHIVE FAILED **
19140: ▸ The following build commands failed:
19141: ▸ PhaseScriptExecution Run\ Script\ ChashHunter /BUILD_PATH/Library/Developer/Xcode/DerivedData/Unity-iPhone-hedyoqmyceuzkigsxxuqawzeokep/Build/Intermediates.noindex/ArchiveIntermediates/Unity-iPhone/IntermediateBuildFilesPath/Unity-iPhone.build/Release-iphoneos/Unity-iPhone.build/Script-4B034A21BD535A12F39C7830.sh

other than that there are no errors in the log. Appreciate any help in this issue.

 

@plujak Unfortunately I didn't mean that we resolved all iOS issues, though that certainly would be nice! The issue you're experiencing is something unrelated to this thread since there's no mention of USYM_UPLOAD_AUTH_TOKEN - I see you've had a successful build since posting here though so it looks like you've resolved this by yourself.

When you're struggling to investigate an issue like this where you can't even find which log lines might correspond to your issue it's generally going to be best to submit a support ticket. The forums are a valuable resource full of other helpful developers but it's hard to be helpful when there's no specific error to look at (that error you posted effectively just means "xcode failed")

 

still issue still occurs on 2019.3.2f1. It would be nice that such issues would be fixed in the builder / engine instead of requiring everyone apply local fix. Or fix such involve nothing to do with the actual building like putting your username and password command line which in CI systems lead to security issues for your username and password be stored in place that is difficult to secure.

So please apply correct fix and don't circle around the issue.

 

I'm locking this thread since this bug has been fixed for close to a year as far as it relates to UCB and this is not going to be a useful place to discuss issues that are not related to UCB - I am not a diagnostics developer and no diagnostics developers ever look at this forum.

You should post in the Cloud Diagnostics forum or use Help -> Report a Bug in the Editor to bring issues direct to the attention of the diagnostics team. Since this issue appears to be a regression and I have not seen any recent bug reports for this issue I would strongly suggest reporting this as a bug.