XCode 15.3 / XCBuildService Crash - Infinite loop when building iOS Project

Using Swift
,
1

Context

We have a very large codebase in our company 600k+ Lines of Code. The setup is a XcodeProj using Swift Package Manager as the only and main package management tool. We have started a long journey of modularizing our monolithic code by moving features or modules into separate local Swift Packages. The setup we have is an explicit local Swift package for the Contract, Implementation, and Mock.

We have a total of 194 Contract packages, eqaully as many Implementation Packages, and <= 194 Mock packages. A total of almost 582 local Swift Packages.

In our POC phase, we found that creating an explicit package per Category was the best way to maintain our packages because using a single Package with multiple targets created some ambiguous compile messages. We found ourselves having to manaully build each package individually to find out what might have went wrong.

Problem

Currently, as we add more packages and link them to the main XcodeProj Unit Test Target, we get an XcodeBuild crash. Specifically, we see the following XCBCore MacroEvaluationProgram.executeInContext. Full crash log can be found here.

The surprising thing is that, the main project continues to build and run on a simulator and device. Only the Unit Test Target crashes while building. Additionally, this crash was happening on Xcode 15.2, and Xcode 15.3 right now as well.

We have tried cleaning up our UnitTest Target, removing packages, and checking build configuration to update it with the latest configurations. This has temporary resolved our problem (especially removing the packages linked); however, we seem to be hitting the limit of number of packages again. We have tried debugging, finding different solutions, and finding documentation, but there seems nothing out there regarding a limit of number of packages that could be linked or any similar crashes with XCBCore on the line 0x102a4d634 MacroEvaluationProgram.executeInContext(_:withResultBuilder:alwaysEvalAsString:) + 1220. Looking at the crash log, it seems like XCBCore is stuck in a recursive loop on that line finally crashing later on.

Any tips, directions, documentation, or build setting change that can overcome this problem would be appreciated.

Our possible next steps as solutions are the following:

  • Move the monolith completely to a Swift Package, and link everything to that package, and link that final one package to the XcodeProj.
  • Try to revert the usage of multiple separate packages per category, and create one SwiftPackage with multiple targets. This should reduce the number of packages

However, as you can imagine this is a very large amount of work, and it would be blocking us from shipping and running our pipelines for a significant amount of time. That is why, I'm reaching out here to see if anyone in the community maybe has a lead on what could be the root cause and solution.

2 Likes
2

Any updates on this?
We have a pretty similar situation but on Xcode 16/16.1: big project with lots of packages, and crashes while running tests via xcodebuild or Xcode. Full report can be found here.

3

We honestly had to get stingier in creating packages and put a migration plan to start using Tuist. What we also noticed is that we had to clean up a lot of imports and linking of packages.

We also noticed that when engineers were working in the main Xcodeproj on Swift Packages they would have access to importing packages that hadn't necessarily been added to that package's Package.swift file as a dependency. We wrote a script to build each package found in the directory and report the compilation issues to quickly identify faulty packages and fix them.

Additionally, we were creating separate Mock packages and we had many being linked to the main Xcodeproj's Unit Test target. What we did to reduce the overhead of Xcode build figuring out all the dependencies is we merged those packages by creating a MockKit package that had symbolic links to all the mocks packages needed to be linked in the Unit Test target. That gave Xcode build less unknowns to figure out and it stopped crashing giving us some leeway to continue development and add some necessary packages.

TLDR:

  • Run all your packages make sure all of them compile and have the right dependencies
  • Merge packages if possible in a way that makes sense for your project and how engineers are using them.
  • You can merge packages by creating one parent package and creating symbolic links to other packages.
5

This is a very different problem than the one you are mentioning. I remember seeing a Stackoverflow post relating to this and your suggested fix working. However, in this case, unfortunately, it doesn't solve the problem.

6

Thanks for your response!

We also noticed that when engineers were working in the main Xcodeproj on Swift Packages they would have access to importing packages that hadn't necessarily been added to that package's Package.swift file as a dependency

We have already had such a check, so that wasn't our case.
We were able to get rid of the crash by migrating our 'Umbrella' packages products to static libraries instead of dynamic.