The New Build System detects a cycle in dependencies between targets.
The steps of a build often involve high level targets, such as application targets, depending on lower-level targets, such as framework or library targets. The lower level targets are built first, so that the high level targets can link, embed, or otherwise use their products.
If targets have mutual dependencies on each other, a cycle is formed, and it is not correct to build either target first. These mutual dependencies may be direct, or they may be part of a chain that involves other intermediate targets. In either case a build may produce unreliable results.
The New Build System detects dependency cycles and produces a build error explaining the cycle that it detected. If you get this error, you should change the structure of the targets or source code to eliminate the cycle.
Note: To change the build system, go to Choose the build system.
If your project contains a dependency cycle due to the dependencies between targets, the build fails with an error similar to:
error: Cycle in dependencies between targets 'B' and 'A'; building could produce unreliable results.
Cycle path: B → C → A → B
Cycle details:
→ Target 'B' has target dependency on Target 'C'
→ Target 'C' has target dependency on Target 'A'
→ Target 'A' has target dependency on Target 'B'
In this case, target A needs to be built in order to build target B, but target A also depends on target B.
In addition to dependencies explicitly declared in the "Target Dependencies" build phase, target dependencies are created implicitly when one target links against the framework or library product produced by another target. The target dependencies listed in this diagnostic may be explicit dependencies or implicit dependencies.
Follow these steps to fix this problem.
If the build still fails, restructure the project's source code or targets so the dependencies are no longer circular.
If you disable parallel builds, the build system builds all the targets in a fixed order, based on how targets have been ordered in all “Target Dependencies” build phases and in the scheme's "Build" action. If this order produces a dependency cycle, the build fails with an error similar to:
error: Cycle in dependencies between targets 'A' and 'B'; building could produce unreliable results.
Cycle path: B → A → C → B
Cycle details:
Target build order preserved because “Parallelize Build” is off
→ Target 'B' has link command with output '/Users/user/Library/Developer/Xcode/DerivedData/A-crxjtmxdssvpmxbeissnxefqwqtp/Build/Products/Debug/B.framework/Versions/A/B'
○ Target 'B' has compile command with input '/Users/user/Library/Developer/Xcode/DerivedData/A-crxjtmxdssvpmxbeissnxefqwqtp/Build/Intermediates.noindex/A.build/Debug/A.build/DerivedSources/File.m'
○ That command depends on command in Target 'A': script phase “Generate File.m”
→ Target 'A' has target dependency on Target 'C' due to target order in a “Target Dependencies” build phase or the scheme
→ Target 'C' has target dependency on Target 'B' due to target order in a “Target Dependencies” build phase or the scheme
In this case, target B depends on a file generated by target A, but the order configured in the project requires target B to be built before target A.
Follow these steps to fix this problem.
First enable parallel builds (enable the “Parallelize Build“ checkbox in the scheme).
If the build fails again, explicitly add the required target dependencies.
If the build still fails, reorder the targets in the scheme's Build action or reorder the dependent targets.
Targets which are required early in the build should be listed before the targets which depend on them.
Targets in your project may generate source files or resources which are needed to build other targets, but in an order that conflicts with the order determined by other dependencies. In that case, your build fails with an error similar to:
error: Cycle in dependencies between targets 'A' and 'B'; building could produce unreliable results.
Cycle path: A → B → A
Cycle details:
→ Target 'A' has target dependency on Target 'B'
→ Target 'B' has compile command with input '/Users/user/Library/Developer/Xcode/DerivedData/A-fwfactyalkdlasagytkmozogzans/Build/Intermediates.noindex/A.build/Debug/A.build/DerivedSources/File.m'
○ That command depends on command in Target 'A': script phase “Generate File.m”
In this case, target A depends on target B, but target B also needs a source file that is generated by target A.
Follow these steps to fix this problem.
In the Target Dependencies build phase, verify whether the conflicting target dependencies are necessary.
If the given target doesn't need any of the products (for example, frameworks) of another target, delete the target dependency.
If all of the explicit target dependencies are necessary to build your project, restructure your project's source code or targets so your dependencies are no longer circular.
To allow fast and correct incremental builds, every build after the initial build uses information discovered during the prior builds to learn about additional dependencies in your source code, such as included headers or imported modules. This may lead to dependency cycles which are only discovered after the first successful build and which make subsequent builds fail with an error similar to:
error: Cycle in dependencies between targets 'A' and 'B'; building could produce unreliable results.
Cycle path: A → B → A
Cycle details:
→ Target 'A' has link command with output '/Users/user/Library/Developer/Xcode/DerivedData/A-exhexvayjuazkmeqbiuraugfrmyy/Build/Products/Debug/A.framework/Versions/A/A'
○ Target 'A' has compile command with input '/Users/user/Desktop/A/A/File.m'
→ Target 'B' has write command with output /Users/user/Library/Developer/Xcode/DerivedData/A-exhexvayjuazkmeqbiuraugfrmyy/Build/Intermediates.noindex/A.build/Debug/B.build/module.modulemap
○ Target 'B' has target dependency on Target 'A'
In this case, File.m
is being compiled as part of target A and it includes the module B, but there is also an explicit target dependency from target B to target A.
Note: If the Enable Modules build setting is on, any import of headers from a module will import the whole module. This is why the cycle diagnostic lists the write command for the modulemap as a potential element in the cycle.
Follow these steps to fix this problem.
Verify whether the conflicting target dependencies are necessary.
If the given target doesn't need any of the products (for example, frameworks) of another target, delete the target dependency.
Check the import statements of files being compiled by commands that are listed as part of the cycle.
It might be possible that some import statements are unnecessary and removing them will resolve the dependency cycle.
If the problem still persists, restructure your project's source code or targets so the dependencies are no longer circular.