Objective-C bridging

[apollographql]

Objective-C bridging

[martijnwalraven]

Although it is private and not well documented, it seems you should be able to use _ObjectiveCBridgeable to bridge Swift structs and Objective-C classes even in the current Swift version (see this post for example).

[martijnwalraven]

Happy to re-open discussion, because actual use cases and proposals are exactly what we need.

@KieranLafferty has been working on an apollo-codegen Objective-C target.

We haven't thought about how this interacts with the runtime and which parts of the Swift code we can reuse however, and mixed language environments seem like a good use case to keep in mind.

I would definitely be in favor of a bridging solution, where we can reuse most of the runtime code and also share a single cache between languages.

Passing dictionaries seems like the easiest option. Using a reflection-based library like Wrap works, but we may be able to do better by having the generated GraphQLMappable types expose a dictionary method (similar to how input objects currently expose graphQLMap).

Of course, typed model classes would be a lot nicer. And if we can have them initialize themselves from the corresponding GraphQLMappable (like the GraphQLNamedFragment in your example) they won't have to contain much logic.

The benefit of this over a stand-alone Objective-C implementation is that result parsing relies on Swift typing magic, so keeping that in Swift and then bridging to Objective-C on demand means we don't have to reimplement this.

I'm also wondering if there is anything we can do to make bridging transparent by using _ObjectiveCBridgeable, similar to how other value types are bridged in Swift 3.

[maxsz]

I only included the dictionary example as a simple, hacky workaround that one can actually use now to have a general way of exposing . I think it's not the right way to go forward. Exposing the dictionary on GraphQLMappable enables or even encourages unsafe usage of the API.

The proposal for ObjectiveCBridgeable is really awesome, very unfortunate that it is currently deferred. But, quoting the authors of the proposal:

For framework and library authors it presents an awful choice:

1. Write mountains of glue code to convert between Swift and Objective-C versions of your types.
2. Write your shiny new framework in Swift, but in an Objective-C style using only @objc types.
3. Write your shiny new framework in Objective-C.

Choice #1 is not practical in the real world with ship dates, resulting in most teams choosing #2 or #3.

I think that their conclusion (choice 1 being impractical) is not completely relevant in our case, as we have the option to generate that code.

[Ewg777]

Happy to re-open discussion, because actual use cases and proposals are exactly what we need.

@KieranLafferty has been working on an apollo-codegen Objective-C target.

@KieranLafferty any update?

[designatednerd]

Just as a heads up: Given that it's been a few years and Swift has finally reached ABI stability (and module stability when 5.1 lands), we've officially decided not to move forward with Objective-C code generation on our end. You're definitely welcome to work on it on your own, but at this point it's just not on the priority list for Apollo directly.

Thanks very much for your patience, and sorry we weren't able to help here. I'm going to close this issue out.