Unreal 4.27 plus not working with Xcode 16.4

Development Platform & Builds Mobile
, ,
1

Hi,

We recently updated our Mac to the latest OS (15.6.1) and Xcode to the latest version (16.4 (16F6)). Since doing this, we are unable to build on our projects using Unreal 4.27.

If we try to build on iOS, we get the following build error:

BUILD FAILED: [PC_Path]\UE4\Games\GoatGame\Binaries\Win64\UnrealHeaderTool.target was a build product but no longer exists

Afterwards, if we try to build either iOS or Android, we get another build error:

[PC_Path]/UE4/Engine/Source/Developer/ToolMenus/Public/ToolMenuDelegates.h(34) : Error: Unable to parse delegate declaration; expected 'DECLARE_DYNAMIC_DELEGATE' but found 'DECLARE_DYNAMIC_DELEGATE_OneParam'.

I found this recent thread describing the same issue [Content removed] and I can confirm that the /Engine/Programs/ folder gets deleted for us as well which I believe explains both of the issues.

In that thread, RemoteMac.cs is mentioned. Our RemoteMac.cs matches exactly the 4.27 Plus version here https://github.com/EpicGames/UnrealEngine/blob/4.27-plus/Engine/Source/Programs/UnrealBuildTool/ToolChain/RemoteMac.cs.

Our projects include C++.

The final question from Stéphane in that chat is “Can you confirm what the configured output directory for the remote build is?”. What I can say is:

  • Our builds worked perfectly before updating MacOS and Xcode.
  • The configured output directory is not changed.
  • Our “Remote Server Override Build Path” setting is empty on one of our projects, but set on our other project, both running into this issue.

If you’d still want me to share that output directory here, how do I do find what it is?

I did find this article which could suggest this is actually caused by a change in MacOS rather than Xcode: https://derflounder.wordpress.com/2025/04/06/rsync-replaced-with-openrsync-on-macos-sequoia/

Removing --delete and --delete-excluded from CommonRsyncArguments allows us to still make builds, but I believe that is hiding the issue rather than fixing it.

2

Bumping because this is still blocking us from making any builds.

3

Hi Jimmy,

I just grabbed the latest code from 4.27+ and was able to successfully build editor and launch a template on an iOS device without issue. Running MacOS 15.7.1 + Xcode 16.4. If you are building from source, can you confirm you are on the latest updates to 4.27+?

I was aware of a few issues affecting Remote Builds in 5.4 but I’ll confirm if those issues affect 4.27+ once I get the latest running on Windows and circle back here.

Best regards.

4

Hi Stéphane,

Thank you for having a look. We are on 36d8ab7 for our project. The only changes we are missing are the NDK R28b support, the GetPlaformNDKHostName change, the cherry pick from UnrealMathSSE, and the GooglePAD update. However, all of those look like Android-exclusive changes to me, which make me think these are not related to our issue. That being said, we could apply them to our project to see if they fix things if you think that could fix it.

Some clarification about our workflow:

  • We work on Windows 11 Enterprise machines from which we trigger the build within the Unreal Engine editor using the “Package Project” -> “iOS”.
  • This issue was observed in a Development build.
  • We only have the code compilation run on our Mac Studio. I have included an image of the device info to this message.
  • We have our RemoteServerOverrideBuildPath set to /Volumes/WD_BLACK/BuildFolder. The WD_BLACK is an external drive connected via USB.

If there is any other info that I could share that could help narrow down the problem, or anything you’d like us to try please let me know.

5

Hi Jimmy,

Thanks for the details. We are currently sitting on a workaround involving the removal of the --delete --delete-excluded arguments in mainline (https://github.com/EpicGames/UnrealEngine/commit/222b5261ad56a292326308249d62777620749990\). Does this properly unblock your remote builds under 4.27+ or have you experienced other issues as a result?

Best regards.

6

Hi Stephane,

Thank you for your response. I implemented that change and ran into some more issues. I noticed that afterwards, you also submitted https://github.com/EpicGames/UnrealEngine/commit/a29a13eb7ea6bbb5db28d8d3bfb31e27e3af379a\#diff\-5e2b7d0d06b648c3cbae6ed766c044e6536efe046d9a05b008b3edcb6b4d2474 and https://github.com/EpicGames/UnrealEngine/commit/e8ec6151921e0d645b0e2b7fdc774091aa2c4b1b\#diff\-237fff3f526ad4352f1cf66f56c6bec44ef661d27802dcbab0b45cde226f950a. I implemented the code changes and copied the new AppleWorldwideDeveloperRelationsCA.pem and rsync file in the cwrsync/mac folder into our project. With those changes, we are able to build and sign. However, I am getting 2 errors that were not present before. They are:

ERROR: xattr: rsync: No such xattr: com.apple.quarantine

ERROR: objc[60924]: Class _NoAnimationDelegate is implemented in both /Library/Developer/CoreSimulator/Volumes/iOS_23A343/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 26.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/SwiftUICore.framework/SwiftUICore (0x1462c4130) and /Library/Developer/CoreSimulator/Volumes/iOS_23A343/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 26.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/UIKitCore.framework/UIKitCore (0x14342d198). This may cause spurious casting failures and mysterious crashes. One of the duplicates must be removed or renamed.

Are you seeing these too? Our codebase does not touch com.apple.quarantine nor does it do anything special with the Swift libraries.

Kind regards,

Jimmy Koene

7

Hi Jimmy,

We are actively working on getting remote builds back up and running on Sequoia and latest Xcode’s on mainline. We addressed the benign xattr error message earlier today in RemoteMac.cs and this should get mirrored to Github shortly. We haven’t seen the Swift issue in mainline however. At which link stage is that occurring on 4.27+. We will likely look at backporting to 4.27+ internally so we’ll circle back if it reproduces there.

Best regards.

8

Hi Stéphane,

Thank you for your continued work on this issue. I can confirm that the xattr error is gone with the change you submitted.

What version of Xcode are you using? For another project, we had to update our build machine to use Xcode version 26.0.1 (17A400) which we believe has introduced the error considering the reference to iOS 26.0.simruntime.

Kind regards,

Jimmy Koene

9

Hi Stéphane,

Do you have a status update on getting remote builds back up and running?

I have been doing some of my own investigations on the side to try and get us able to release iOS updates again as quickly as possible and found a couple bits of code on Github that I wonder might need updating.

FIOSTargetSettingsCustomization::OnInstallProvisionClicked still references the old provisioning profile path.

Similarly in, in the iPhonePackager, the RunRPCUtility method in CompileTime.cs references the old path. There is also Config.cs with the method GetProvisionDirectory.

Should those be updated to use the new provisioning profile path?

Kind regards,

Jimmy Koene

10

Hi Jimmy,

Those path changes in IPP are pending but are specific to running legacy Xcode on a Mac host (this is getting phased out) and wouldn’t affect the Windows remote build. I will be dedicating cycles today to the 4.27 backport and will get back to you ASAP.

Best regards.

11

Hi Jimmy,

After back porting the changes to 4.27+ from UE5-main, I can confirm that I was able to successfully package remotely for iOS based on C++ templates. Running Xcode 16.4 on MacOS 15.7.1. Will attempt with Xcode 26.0.1 next and see if we observe the issue you’ve encountered.

Best regards.

12

Hi Jimmy,

The backport or Remote iOS builds is officially backported at: https://github.com/EpicGames/UnrealEngine/commit/e3fdaccdeb1ea08ede92f58021e4922a7b75d58c#diff-0f4dc3a11d2dbb73bc1934d67485832615530a3fc667ad611b1e4567ebec440e.

I didn’t experience the UIKit/SwiftUI name collision after upgrading Xcode from 16.4 to 26.0.1. Does cleaning the remote folder perhaps resolve if there’s some stale data on that end? The default remote folder on Mac is ~/UE4/Builds/$PCNAME/… If the error persists, can you provide a full log?

Best regards.

13

Hi Jimmy,

I can however confirm that when remote building against MacOS 26, changes on Apple’s side to codesign has resulted in Windows side codesigning no longer being functional (error CMD Signature block size is too large for the allocated size). We are investigating this, so recommendation at the moment would be to keep the remote Mac on Sequoia until this is resolved.

Best regards.

14

Hi Stéphane,

Thank you for your responses. There were a couple of small changes I had to make to our code after looking at your submit on 4.27 Plus which I have now applied.

We tried clearing the builds folder on the Mac, but to no avail. Perhaps one difference between our setup and yours is that we use iOS version 16 as our target. I can provide a full log, but then it would have to become a private thread. Should I start a separate thread for the UIKit/SwiftUI issue to avoid other people losing out on the info in this thread?

Thank you for sharing that MacOS 26 is incompatible at the moment. I’m guessing this applies to both 4.27+ and 5? Either way, we’ll stay on Sequoia until this is resolved as you suggest.

Kind regards,

Jimmy Koene

15

Hi Jimmy,

CL 47912951 on the 4.27+ branch now implements support for IPP codesigning of binaries generated on a MacOS 26 remote host.

Best regards.

16

Hi Stéphane,

Apologies for taking this long to get back to you. I was blocked from updating our Mac the last couple of weeks.

I updated MacOS from 15.6.1 to 26.1 and Xcode from 26.0.1 to 26.1.1.

I also copied CL 47912951 into my project. However, when I attempt to build, during the packaging stage, I get the following error:

15:30:24       Opening source executable...
15:30:24       ... Processing one mach object (binary is thin)
15:30:25       ... Initial signature step (7,54 s elapsed so far)
15:30:25       ... Computing hashes (7,57 s elapsed so far)
15:30:25       ... Final signature step (7,64 s elapsed so far)
15:30:25       IPP ERROR: Application exception: System.IO.InvalidDataException: CMS signature blob size is too large for the allocated size, unable to create useful code signing data
15:30:25          at iPhonePackager.CodeSignatureBuilder.PerformSigning() in E:\Dev\P4ZM\UE4\Engine\Source\Programs\IOS\iPhonePackager\CodeSigning.cs:line 1007
15:30:25          at iPhonePackager.CookTime.RepackageIPAFromStub() in E:\Dev\P4ZM\UE4\Engine\Source\Programs\IOS\iPhonePackager\CookTime.cs:line 354
15:30:25          at iPhonePackager.Program.Main(String[] args) in E:\Dev\P4ZM\UE4\Engine\Source\Programs\IOS\iPhonePackager\iPhonePackager.cs:line 969

How would I go about fixing this error?

Kind regards,

Jimmy Koene

17

I managed to find out why I had the error above. When building through TeamCity using the BuildGraph, the iPhonePackager does not get compiled by default. As a result, the changes from Stéphane were not being included in the build process.

Additionally, the _NoAnimationDelegate is automatically fixed by updating to the above versions.

18

Hi Jimmy,

Note that there is an additional CL (48623800) to address a few other issues encountered with MacOS26 signing. IPhonePackager.exe should have been updated as prebuilt in all CLs in 4.27+, so not sure why the changes weren’t making it to you, but glad that a rebuild of the iPhoneProject.csproj resolved the issue on your end.

Best regards.