Since Unreal Engine 5.7, after updating XCode and the IOS SDK, I can’t pack for IOS at all anymore.
Our team is using a Mac mini M4 (ARM64).
I was able to launch applications for IOS 18 in UE5.6.
The project DOES work, compile, build and run for Windows and Mac. The only failure is on IOS specifically.
The myriad of CPP compilation errors range from inculpating GENERATED_BODY to claiming there are missing .h files and missing modules, as if the engine forgot itself.
I have tried, after a full reset of the Mac, to use modern and legacy XCode in Unreal Engine, with and without Rosetta, installing the Metal toolchain, and every time I had the exact same amount of errors, no improvements or more mistakes.
Compiling from the IOS workspace yielded the exact same errors as well, around 380 of them.
Also seems like the IOS detection system in Unreal Engine 5.7 only works if launched with Rosetta.
Is there a known fix? A new workflow? Is this a compatibility issue that’ll be looked into as time passes?
I’m experiencing probably the same issue on UE 5.7 for iOS packaging after upgrading my project from 5.6.1 to 5.72 and 5.7.3 now, used Intel Mac running macOS Sequoia 15.7.2 & Mac mini M4 and multiple xcode versions 16.1, 16.4 and 26.1 with same multiple errors. After comparing build logs between 5.6 and 5.7, I discovered that UE 5.7 is skipping the engine PCH compilation for iOS
The build log in 5.7 compilation steps shows this PCH been compiled :
The engine PCH for iOS only is completely skipped from the compilation steps when build for iOS only, while in 5.6 does not skip.
For me this affects even a new C++ empty projects**.** If you create a new C++ Actor class that uses UStaticMeshComponent* or UWorld* without explicitly including their headers (which was fine in 5.6 because they came through the engine PCH), you’ll get missing header errors in 5.7 and if you add explicit includes to your .cpp files for any engine types you’re using , include “Components/StaticMeshComponent.h” , include “Engine/World.h”, …etc , project compiles with success. As i understand ,this might be consistent with Epic’s IWYU (Include What You Use) direction(bad habit of me not including those headers), but the iOS-specific PCH skips in 5.7 appears to be an unintended regression since all other platforms when building still include those missing Shared PCH normally. So if you confirm that we have the same issue for iOS only , as workaround need to track those errors and add those missing headers or wait for a fix if this not the default behavior from now on.
As you mention @DavellisJnR , we are moving towards an IWYU direction. In large projects it makes a sizeable impact in compile times.
This means we might remove a header that was not really needed in an engine header file, but a file in your project might still need it, and it worked until now because that other engine header file was using it but now it does not.
The include order feature I mention above is meant to be path way for upgrading. With that, projects that depend on the old include order should compile but throw a deprecation warning, allowing you to identify the affected files and do the required clean up by including the header files you project files need.
could you explain why this happens for iOS only ? And how/where could we equalize behavior strictness for other platforms ? We want to keep up with latest engine development so the workaround of setting 5_6 include order sounds rather like a step back.
We’ve fixed all the include issues reported by iOS, but the problem with this for cross platform development is that devs working on platforms not affected by this(win64) will possibly keep breaking build for iOS devs.
I don’t know the specific of this particular case, but in general, some includes might have been added in the past to one of the IOS platform headers, and now it was removed.
To give an example, when you interact with FPlatformTime , the API is the same for Windows and IOS, but under the hood two different PlatformTime implementations are used. In iOS it will be FApplePlatformTime , which has its own set of includes.
Things get more tricky when a file in your project was including other headers that were including FApplePlatformTime and your code depended in a header in FApplePlatformTime that was removed.
This is not something it can happen only in IOS, it can happen in any platform.
The workaround of setting the include order to an older version should not be permanent. It is a pathway to allow you to compile your project and tackle the header deprecation warnings. Once all warnings are addressed, then the include order should be set to the default.
This is something that needs to be considered only in engine version upgrades.
If you are working on the same engine version, as long you include the headers that are needed (IWYU) you should not have issues.
If that is not done, having a CIS system where you build your project for all your target platforms periodically is the best way to catch these issues.
But the best solution is follow IWYU (Include what you use). This also helps to not make your compile times worse.