Request to clear derived data when switch from build for test to build for run

[dvshelley]

Summary

Since we migrated from Apollo 0.xx to 1.xx, we have regularly been getting an error of this style. Is this a problem with our code or an issue with 1.xx?

Doing a build clean gets past the problem. But that is obnoxious as our build times are long.

Version

Apollo 1.12.2

Steps to reproduce the behavior

Build and run to the sim.
Build for test and run unit tests.
Build and run for debugging - get error.

Logs

No response

Anything else?

No response

[BobaFetters]

@dvshelley How is your code generation configured/how are you running it (CLI or SwiftScripting)?

[dvshelley]

@BobaFetters We use apollo-ios-cli to do our code generation. Does SwiftScripting do slightly different code output?

[BobaFetters]

@dvshelley The output from cli and scripting would be the same, are you running the cli commands for generating your ocde through a build step/run script in Xcode? I know this was the recommended way to handle code generation pre-1.0 but thats no longer the recommended way to do it, if thats how you have it set up it could cause the issue you are seeing.

[dvshelley]

@BobaFetters No, we only generate code when we have updated the graphql files. We do that from the command line as needed. We would prefer not to add a new build phase. Our build times are long enough already.

[BobaFetters]

@dvshelley Ok that's good that is the way we recommend handling the code generation. Would it be possible for you to provide a small sample project that demonstrates the issue? This definitely isn't an expected behavior and a reproduction case would help us in tracking down the issue.

[AnthonyMDev]

We're not really sure if there is anything we can do about this. It seems that it is likely just something to do with Xcode and the way DerivedData and compiled sources are cached (which has always been a bit wonky with Xcode).

It sounds like you are doing everything the way we recommend. If you are able to give us a reproduction case, we can try looking into it more, but I'm not optimistic about us coming up with a solution for this even then. I'm going to close this for now, and if you provide a reproduction case we can consider re-opening.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.

[dvshelley]

It looks like we were able to fix the issue by changing our project dependencies. Some of our internal frameworks needed a direct reference to Apollo.