Is it possible to dynamically build graphQL queries for iOS?

Hello everyone!

I have a situation at work, which resulted with a following question: Is it possible to build a graphQL query dynamically in Swift/Xcode, and does apollographql support this?

In my understanding, the Apollo codegen script runs in the build phase (of an Xcode project), and this script (in order to compile the API.swift file) needs to have all the queries already there, defined statically, before it runs. Am I right on this? For me it seems like building a graphQL query dynamically isn’t possible (on iOS).

Please someone correct me if I’m wrong on this. Thank you very much! Any answers are highly appreciated!


1 Like

Hi, I have the very same question but for Android/Kotlin.

1 Like

Hi! Not in the Apollo iOS SDK, no. You are correct that we assume you already have the queries (though obviously not the parameters for those queries) at compile time.

There’s a couple other OSS projects out there that would let you do build queries programatically, the one that immediately pops to mind is Graphaello, but their entire way of interacting with GraphQL servers is different from ours, as they’ve chosen different trade-offs than we have.

Hope that helps!

Just double-checked and the Android/Kotlin SDK also does not support this. Again, there are a few other libraries that do, it sounds like the largest one is Netflix’s DGS.

1 Like

Thank you for the answer! I really hope it would be possible for me to dodge this dynamic queries, I’m really liking the Apollo library and I hope I won’t be force to move to something else. Thanks again!

Thanks a lot for the answer! I understand it’s not natively supported by the library, but is it technically still possible, more as a hack? So, the query classes are being automatically generated in API.swift file based on the static query files.

What happens if I theoretically do the following:

  1. I manually create a query class for a query I would like to be dynamic
  2. I don’t create a static query file for it, of course, and the script in the build phase won’t create the class for it in the API.swift file (which isn’t needed because I manually created it in step 1)
  3. I manually inject the actual query as a string value in my query class instance from step 1

That way API.swift wouldn’t clash with the manually created query class and my manually created query class instance would hold the actual query string which I would manually / dynamically generate and inject.

I am just thinking out loud, and I am sure my potential approach has some holes in it, but are there other limitations (that I am currently not aware of) that would prevent such attempt as a possibility?

Sorry for too much text, but it is pretty important to me and my team to know this. Any comment/feedback on this is very appreciated! Thanks a lot!

I mean, that’s possible, but honestly there’s enough stuff going on in the generated code and query construction that I strongly suspect it’s going to be difficult to get it to work with the rest of the system.

Frankly, if you want to make dynamic queries, it’s better to use a different library to do so. That (theoretically) shouldn’t prevent you from also using Apollo to handle your non-dynamic queries, but our setup definitely went with the choice of “assume the developer knows what information they need to ask for at compile time.”

Thank you very much for the answer. I appreciate it a lot.