1.18.0 - Missing argument for parameter 'implementingObjects'

[rudyfremont]

Summary

I have compilation error with the latest SDK version (1.18.0) for Interface - No issue with the 1.17.0 version

Version

1.18.0

Steps to reproduce the behavior

just try to compile generated files

Logs

Anything else?

No response

[BobaFetters]

Have you regenerated your code yet? There are some minor changes in the structure of some of the generated code to support the "Reduce generated schema types" feature. This new property on Interface being on of them.

[rudyfremont]

Oops, I thought I'd done it but it looks like my CLI hasn't been updated correctly
Now the generated files are modified and the code compiles!
Sorry :)

[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.

[cameroncooke]

Isn't this considered a breaking change and should be versioned accordingly? I've run into the same issue for a minor point release update for Apollo.

[BobaFetters]

@cameroncooke Changes in the generated code wouldn't be considered breaking since they don't require manual code changes by the user, and code generation should always be be run when updating versions so that the generated code is created from a version of the codegen library matching the apollo-ios version.

[cameroncooke]

That makes a ton of assumptions. We're using SPM packages and can't run code gen like you would a build phase in an Xcode Project setup. SPM updates are automatic based on semantic versioning.

[BobaFetters]

There are definitely some things that would be nice to have in SPM, like being able to run a script etc when a package updates, unfortunately that's not available, however other users have built SPM plugins to run codegen like running a build phase in Xcode, there is some discussion around that here. We do have open issue for building more official support for this but the features and work necessary to do that aren't currently high on our priority list. Depending on your workflow a build plugin may or may not be ideal, there are different ways this can be handled though, and can also depend on if you are using the CLI tool for codegen or scripting the codegen in Swift.

The root of things though like I mentioned is the generated code need to match the version of apollo-ios in use, it is possible that mismatched versions could function correctly, but its highly dependent on changes that may happen in either library that could be invisible to the user but still affect overall functionality. This is less an assumption and more a requirement of the library, and if you run a version of the codegen CLI tool that doesnt match your apollo-ios version you will see an error that you are using a mismatched version.

[cameroncooke]

That’s good to know tbh we never knew this and assumed there would be source comparability between generated code and major versions of Apollo client. We also adopted Apollo for iOS from version 0.7.0 which had constant breaking changes so we were not in a position to setup scripts and automatic as it was too unstable between updates. Might be we have to fix versions in SPM for now but will take a look at your recommended and discussions around this. That’s very help. Thank you. Cameron.

…

On Thu, 27 Feb 2025 at 16:37, Zach FettersMoore ***@***.***> wrote: There are definitely some things that would be nice to have in SPM, like being able to run a script etc when a package updates, unfortunately that's not available, however other users have built SPM plugins to run codegen like running a build phase in Xcode, there is some discussion around that here <#3267>. We do have open issue for building more official support for this but the features and work necessary to do that aren't currently high on our priority list. Depending on your workflow a build plugin may or may not be ideal, there are different ways this can be handled though, and can also depend on if you are using the CLI tool for codegen or scripting the codegen in Swift. The root of things though like I mentioned is the generated code need to match the version of apollo-ios in use, it is possible that mismatched versions could function correctly, but its highly dependent on changes that may happen in either library that could be invisible to the user but still affect overall functionality. — Reply to this email directly, view it on GitHub <#3515 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEZ6SNJ63PZG77M52Y6VJ32R45LLAVCNFSM6AAAAABXOXDWOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBYGUYDKNRXHE> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: BobaFetters]*BobaFetters* left a comment (apollographql/apollo-ios#3515) <#3515 (comment)> There are definitely some things that would be nice to have in SPM, like being able to run a script etc when a package updates, unfortunately that's not available, however other users have built SPM plugins to run codegen like running a build phase in Xcode, there is some discussion around that here <#3267>. We do have open issue for building more official support for this but the features and work necessary to do that aren't currently high on our priority list. Depending on your workflow a build plugin may or may not be ideal, there are different ways this can be handled though, and can also depend on if you are using the CLI tool for codegen or scripting the codegen in Swift. The root of things though like I mentioned is the generated code need to match the version of apollo-ios in use, it is possible that mismatched versions could function correctly, but its highly dependent on changes that may happen in either library that could be invisible to the user but still affect overall functionality. — Reply to this email directly, view it on GitHub <#3515 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEZ6SNJ63PZG77M52Y6VJ32R45LLAVCNFSM6AAAAABXOXDWOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBYGUYDKNRXHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cameroncooke]

Out of interest can I draw attention to this:

This feature request makes sense if you're upgrading directly from the legacy (0.x) versions where it was recommended to have a build step in your project that would run code generation as part of each build. We no longer make that recommendation in 1.0; it's not necessary for code generation to be run with each build because the schema/operation files do not typically change between each build. It's worth noting though that you can still achieve the same build step by using the new CLI tool.

#3267 (comment)

Are you no saying this no longer holds true, it's kind of confusing tbh.

[calvincestari]

Are you no saying this no longer holds true, it's kind of confusing tbh.

tl;dr - there is nuance to this.

I wrote that comment and I believe it's still valid. It is still our recommendation that a code generation build step is typically not needed and would result in unnecessary build time. Each project is different though so chose the path that best suits your needs.

As mentioned above we do not view this specific issue as a breaking change. I agree it is confusing though and we could have done a better job of highlighting the need to rerun code generation in this release. We'll consider that going forward.

[cameroncooke]

Thanks for the reply. Yes that would be much appreciated in future. Thanks so much. Cameron.

…

On Tue, 4 Mar 2025 at 17:00, Calvin Cestari ***@***.***> wrote: Are you no saying this no longer holds true, it's kind of confusing tbh. tl;dr - there is nuance to this. I wrote that comment and I believe it's still valid. It is still our recommendation that a code generation build step is *typically* not needed and would result in unnecessary build time. Each project is different though so chose the path that best suits your needs. As mentioned above we do not view this specific issue as a breaking change. I agree it is confusing though and we could have done a better job of highlighting the need to rerun code generation in this release. We'll consider that going forward. — Reply to this email directly, view it on GitHub <#3515 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEZ6SMID7XFNGVNZJR6T2T2SXLZ7AVCNFSM6AAAAABXOXDWOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJYGM2DCNJXGY> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: calvincestari]*calvincestari* left a comment (apollographql/apollo-ios#3515) <#3515 (comment)> Are you no saying this no longer holds true, it's kind of confusing tbh. tl;dr - there is nuance to this. I wrote that comment and I believe it's still valid. It is still our recommendation that a code generation build step is *typically* not needed and would result in unnecessary build time. Each project is different though so chose the path that best suits your needs. As mentioned above we do not view this specific issue as a breaking change. I agree it is confusing though and we could have done a better job of highlighting the need to rerun code generation in this release. We'll consider that going forward. — Reply to this email directly, view it on GitHub <#3515 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEZ6SMID7XFNGVNZJR6T2T2SXLZ7AVCNFSM6AAAAABXOXDWOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJYGM2DCNJXGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>