Hive
GitHub issue · Open
We have a local Swift package called LocalMacros in our repository which defines a series of macro plugins. This package is then pulled into our Tuist project however when making modifications to the macro plugin implementation, we find that the macro plugin is not being rebuild which is causing a frustrating developer experience because other engineers on the team find themselves facing obscure compiler errors until they perform a clean and build.
tuist install && tuist generateliteral in some wayN/A
15.4.1 (24E263)
4.43.2
16.4.0
Investigate, reproduce, or fix this item in an isolated repository. Each Flight preserves its outcome and agent session.
Start a Flight and preserve its objective, outcome, and session here.
L
Something interesting is that there are two LocalMacrosMacros binaries in DerivedData:
If I check with strings on each binary after updating the macro but not cleaning the project, the one in Debug-iphonesimulator has the correct changes in it, but the one in Debug does not.
So it seems that the binary is being rebuilt, just not correctly?
D
Hi @liamnichols! I’m Dosu and I’m helping the tuist team.
You’re right—what you’re seeing is that the macro binary is being rebuilt for the simulator (Debug-iphonesimulator), but not for the generic Debug directory, which is likely used for macOS or other destinations. This behavior comes from how Xcode and SwiftPM handle local package builds and up-to-date checks. Tuist sets up the build phases and copies macro executables as expected, but it relies on Xcode/SPM to decide when to rebuild local packages, including macros. There isn’t a custom invalidation or rebuild mechanism for local packages in Tuist, so if Xcode/SPM misses a change, a clean build is required to force a rebuild of the macro binary ref.
This is a known pain point and is essentially a limitation or bug in Xcode/SPM’s incremental build logic, not something Tuist can directly control ref. If you consistently see this, the only reliable workaround is to clean before building when you change macro code. Some users have found that removing custom SDK flags (like -sdk iphonesimulator) can help Xcode pick up changes more reliably, but results may vary ref.
If you haven’t already, make sure your macros and plugins are declared using the correct types in your Tuist manifest and that your project setup matches the recommended integration. But ultimately, the need for a clean build after macro changes is a limitation of the current Xcode/SPM toolchain.
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
P
@liamnichols I did some debugging here. With the standard macro graph “App > Macro framework > Macro executable”, Xcode is unable to invalidate Macro framework and App when the executable changes, and because of that changes don’t show up incrementally. I’d have expected Xcode to detect that and re-trigger the compilation of the Swift files that depend on the macro, but that’s unfortunately not the case.
I’m afraid we won’t be able to solve this without a hack. Xcode’s probably handling this scenario for the SwiftPM’s integration, but they haven’t thought about supporting it across the board. Have you considered having example targets where people can iterate on the macros cleaning when changing the files? It’s a bit annoying, I know, but until we can figure something out or Xcode handles that gracefully, it will alleviate the pain a bit.
Also… if you have ideas having the context now, you can try to play with build settings and phases until you find the right setup that works incrementally. If you find it, I can happily incorporate that into Tuist.
