Changing enum on schema from required to optional breaks builds

[wow-such-amazing]

Summary

Hello Apollo Team!

Recently our backend team released a change to make a property optional on the input type instead of it being required. This is considered as a non-breaking change schema-wise as we lift of one the requirements.

However, such change is not compatible with the generated code that we have. One could argue that we should update the app to support new schema. However that's an unexpected extra work. Plus in our case this breaks our build pipeline because during the build we fetch the schema to ensure we always use a correct one. Again, one could argue that this is unnecessary, but overall this doesn't discard the underlying problem in my opinion.

Version

1.15.1

Steps to reproduce the behavior

Schema before:

AddressInput {
  type: AddressEnum!
}

Schema after:

AddressInput {
  type: AddressEnum
}

As you can see, property became optional. And because of that we have this build error that type can't be resolved:

To make it work we need to re-write the code as the following:

From what I know this doesn't raise an issue for Android builds and for Frontend builds in our team.

Logs

No response

Anything else?

No response

[AnthonyMDev]

Hi @wow-such-amazing, thanks for the input here! We've thought a lot about this issue in the past, and haven't really been able to come up with any sort of solution that fixes this. Swift enums are kind of difficult to work with, and while GraphQLNullable is great for ensuring correctness and expressivity of your nulls, it exposes some awkward cases like this.

In my mind, backwards compatibility requires that existing applications out in production won't break when a schema change occurs. Which is currently the case. But I don't think there is a way to prevent you from needing to change your code when recompiling against the updated schema.

You're right, this probably isn't an issue for the other teams. Unfortunately, that is due to the nature of enums in Swift. We tried to make this work as well as possible. We used the ExpressibleBy___Literal protocols, so that if your input value was a String, or an Int, it would just work. But for custom types like Enums, there is just no way to make this happen in Swift.

I wish there was a better answer for you. We've had to weigh many trade offs when designing Apollo iOS, and this is one of the concession we knew we had to make when designing the way to deal with null input values. GraphQLNullable isn't perfect, but we still feel it's an improvement on what we had in Apollo iOS 0.x, which was doubly nested optionals (AddressEnum??) that didn't make it clear why you would set the input to nil or .some(nil) and also had a bunch of odd syntactic quirks that were far less explicit and expressive.

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

[wow-such-amazing]

Hey @AnthonyMDev, thanks for the reply! I understand the reasoning and personally I don't have a strong opinion which approach is better, but wanted to double check with you since such issues block our backend team sometimes to release changes on the schema. Thanks again for the swift answer and clarification 🙏