Android Running Apollo 2 and Apollo 3 Side by Side


We started our Apollo 3 migration pretty early on and at that stage at least, we were under the belief that it wouldn’t be possible to run 2 and 3 together for any sort of A/B testing or limited migration purposes. A lot has changes since starting to slowly work on this and evaluate it during alpha and with all of those changes I’m now seeing this in the migration documentation:

This change avoids dependency conflicts as encouraged in Java Interoperability Policy for Major Version Updates. It also allows to run version 2 and version 3 side by side if needed.

We’re at the stage where we’ve migrated but there are some questions about risk and if we can no go back and consider running 2 and 3 together to mitigate risk.

I don’t see many details on the possibilities here is how 2 and 3 can be run together. If there is any further documentation on this I would love to read up on it. The question I have now, is it the case that the same request could be A/B tested with auto generated files from both 2 and 3 or would it be a scenario where you can migrate some requests but not others? It seems like if you could do the later you should probably also be able to do the former. But knowing what the options are is all I really need at this point in time for us to evaluate if we want to work backwards a little and have both running together.


Hi :wave: Thanks for reaching out!

Since the package names are different (apollo3 vs apollo), you can run 2.x and 3.x side by side indeed. I’d say the main use case is for libraries. If you depend on a library that uses 2.x, you can, as an app developer, start using v3.x without waiting for the library to update.

If you want to A/B test the same request for 2.x vs 3.x inside your app, that’s possible but it will be troublesome. You’ll need to:

  • generate both the 2.x and 3.x models for this request.
  • a common model to use in your UI
  • mappers for 2.x and 3.x to that common model
  • etc…

It’s all doable but that’ll be some work and code duplication. I’d suggest you start by migrating a small query and then go from there and migrate more and more queries progressively. Although 3.x cannot use the generated models from 2.x, they are mostly source compatible so updating your code to use 3.x models should require too many changes.

Hope this helps

1 Like

I had a lot of issues with the OkHttpClient transitive dependency. I had to replace the HttpEngine to make it work properly. My setup is a bit custom as I use maven though.

1 Like

Meant to respond a while ago but just wanted to say thank you for the response. This was my finding but just wanted to confirm. We decided just to make the switch for the reasons you stated. We were basically already there but some questions were asked about if it would be worth trying to A/B test. Really appreciate the insight :smile:

Nice! Thanks for the update :slight_smile: