Hey y’all,
My iOS failed and I cannot determine cause.
The only errors I can find in the full log build are:
I tried a clean build, and the Unity export itself is working.
The full log is attached.
(I do not have a mac unfortunately.)
Thank you for your insight
Same thing for me as well:
15447: ▸ Running script ‘Run Script’
15448: ▸ Running script ‘Process symbols’
15449: ▸ ** ARCHIVE FAILED **
15450: ▸ The following build commands failed:
15451: ▸ PhaseScriptExecution Process\ symbols /BUILD_PATH/Library/Developer/Xcode/DerivedData/Unity-iPhone-fhncfgsfzjqpskbfucfmhmkmsvnv/Build/Intermediates.noindex/ArchiveIntermediates/Unity-iPhone/IntermediateBuildFilesPath/Unity-iPhone.build/Release-iphoneos/Unity-iPhone.build/Script-FC894680ABC3B786C304894D.sh
What version of unity are you using
This was on 2019.x
I exported and imported the project into a new 2018.4 project. Everything built fine now.
At this stage I believe this is likely caused by 2019.1.3f1, if you are using the target “latest 2019.1 version” then you will have been automatically moved on to this newer Unity version recently which has caused these unexpected build failures.
If you just want the builds to start working immediately, switching your build targets to specifically run against 2019.1.2f1 should prevent this issue. You can also try running against the 2019.2 beta since I have not seen this issue happen there but that comes with all the normal risks you would expect from a beta release.
If you want to help us resolve this, try updating your local Unity version to 2019.1.3f1. Commit any changes which happen as a result of opening the project in this updated version then see if your project builds successfully in UCB with the updated assets - and post here if this fixed it! I’ll be doing this myself along with a few other experiments but as always the more data points I have access to the quicker this can be fixed.
Please also be sure to post here or submit a support ticket if you are experiencing this issue when running in UCB on versions OTHER than 2019.1.3f1 since it would be useful to identify if there are any other cases of this occurring.
Hey victorw, I am getting the same error here. I’m only given the ‘Always Use Latest 2019.1’ option in the drop down. How can I select a more specific 2019 version?
Other more specific Unity versions are available to select when configuring a Build Target (Cloud Build → Config → Basic Info in developer dashboard). You will have to scroll down the list though since the “Always Use Latest” targets are all at the top.
(We’re hoping to add an additional option in future which would ensure that UCB always attempts to use exactly the same version as you are running locally, but this is a lot more complex than it sounds…)
Victor, thank you very much for updating us on this.
Just to add, I think your theory is correct because the build started failing after May 22.
I can confirm switching the build target to an earlier version of unity (in my case 2019.1.0f2) resolved this IOS cloud build issue.
@victorw Actually there seems to be a bug on the webpage, the “Unity version” dropdown is not scrollable for me. I can briefly see the scrollbar when opening the popup, but it immediately disappears, and scrolling only results in scrolling the page behind.
This is with Chrome Version 74.0.3729.169 (Official Build) (64-bit) on macOS High Sierra 10.13.6.
Edit: Works fine in Safari
@steego Yes, this is the behaviour I am seeing also. Opening the cloud build dashboard from safari rather than chrome (v74.0.3729.169) let me scroll and select 2019.1.2f.
My iOS build is now working again, hoorar!
I concur, upgraded my Unity IDE to 2019.1.3f1 just before May 22 and every build AFTER May 22 causes this issue.
After setting the “Unity version” explicitly to 2019.1.3f1 within the UCB basic info config page, I am reattempting the build now, to see if anything changes.
Most likely nothing will change there - the always use latest target is already set to 2019.1.3f1. I was hoping that updating locally before committing might resolve this issue but that doesn’t sound likely if you had already updated locally. Hopefully you can still work around this issue by targeting 2019.1.2f1 in UCB though.
You were right, the build just finished and surprise… surprise, it failed.
I’ll give this a shot now and report back on that build. Thanks for the tip.
Just as a longshot and not sure it will work, but have you tried the iOS CloudKit instructions on this post from Phil, your errors seem consistent with what CloudKit users sometimes see under Xcode 10.x runs. It just involves making 2 tiny text files and 1 directory in your asset folder as per that post.
I think I might have found a fix for this issue but I’m currently not able to replicate this issue for myself so I can’t tell whether or not my change would fix anything. Can someone please post or message me their Packages/manifest.json? Also as Alex said it would be good to confirm that the issue is not resolved by following the Xcode 10 fastlane config steps outlined here .
Attempted to set my UCB version to 2019.1.2f1 and attempted a clean rebuild, but as expected it failed.
This time however I saw some additional error messages popup:
1438: ❌; ld: symbol(s) not found for architecture armv7
1439: ❌; clang: error: linker command failed with exit code 1 (use -v to see invocation)
1440: publishing finished successfully.
1441: Finished: FAILURE```
Not sure if this means anything, but something different I noticed.Yup if anyone can try adding these 2 tiny text files and ucb dir to your repo Asset’s folder to see if that helps with your iOS builds, and let me know:
Filename: “Assets/ucb_xcode_fastlane.json”
Content: { "gymfile": "Assets/ucb/Gymfile" }
Dir+Filename: “Assets/ucb/Gymfile”
Content: xcargs '-UseModernBuildSystem=NO'
Did what you said, but the build is STILL failing. Attached is the text file for the full build log.
4573123–425509–failedbuild.txt (1.21 MB)
thanks for doing that, sometimes it is worth a shot putting Xcode in Legacy Build mode when dealing FastLane iOS issues, but not this time, looking over your log now. It may be the issue that Victor mentioned instead. I Will check in with him on that.
Wish I had found this thread 3 days ago. One of the most frustrating build fails I have come across seeing as though the full log was useless in highlighting the problem.