Crash in Apollo iOS SDK (1.21.0 & 1.23.0) when using deeply nested input objects in Release builds

[robertcnst]

Summary

We are experiencing a crash in Apollo iOS SDK when executing a query with a deeply nested input parameter ($filterGroup: FilterGroupOne).
The issue only occurs in Release builds, not in Debug.

There seems to be a mismatch between Apollo’s type expectations and Swift’s compiler optimizations (-O) when dealing with deeply nested recursive input objects.

Workarounds exist, but an official fix or guidance would be highly valuable.

Version

Reproducible in 1.21.0 and 1.23.0

Steps to reproduce the behavior

GraphQL schema:

type Query {
  searchTransactions(input: TransactionsSearch): SearchTransactionsResult!
}

input TransactionsSearch {
  ...
  filterGroup: FilterGroupOne
}

input FilterGroupOne {
  conditional: String
  expressions: [FilterGroupOrExpressionOne!]
}

input FilterGroupOrExpressionOne {
  property: String
  operator: String
  values: [Any!]
  conditional: String
  expressions: [FilterGroupOrExpressionTwo!]
}

input FilterGroupOrExpressionTwo {
  property: String
  operator: String
  values: [Any!]
  conditional: String
  expressions: [FilterGroupThree!]
}

input FilterGroupThree {
  property: String
  operator: String
  values: [Any!]!
}

Query:

query SearchTransactions(
  ...
  $filterGroup: FilterGroupOne
) {
  searchTransactions(input: { 
      ...
      filterGroup: $filterGroup 
  }) {
    transactions {
      ...
    }
  }
}

Investigation findings

✅ Works fine in Debug builds (-Onone)
❌ Crashes in Release builds (-O)
✅ Removing $filterGroup parameter from input prevents the crash (but it's needed for our use case)
✅ Forcing ApolloAPI target to use -Onone also prevents the crash (even in Release)

Root cause (our investigation)

Deep recursive input type structure (FilterGroupOne → FilterGroupOrExpressionOne → FilterGroupOrExpressionTwo → FilterGroupThree).
Swift compiler optimization (-O / whole-module) aggressively erases nested optionals and scalars.
Apollo’s generated code expects DataDict, but instead encounters Optional<AnyHashable>.

Crash sequence

1. Query with $filterGroup is sent successfully.
2. Backend returns valid data.
3. Apollo tries to parse the response.
4. We try to access data.searchTransactions
5. var searchTransactions: SearchTransactions { __data["searchTransactions"] } produces the crash - type mismatch (expected DataDict, got Optional<AnyHashable>) → fatal error.

Environment

Apollo iOS SDK: 1.21.0 & 1.23.0 (tried to update but the crash still persists)
iOS: 18+
Xcode: 16.4.0

Build configs:
Debug → Works (-Onone)
Release → Crashes (-O)

Logs

ApolloAPI/DataDict.swift:204: Fatal error: SearchTransactions expected DataDict for entity, got Optional<AnyHashable>.

Anything else?

No response

[calvincestari]

Thanks for creating the issue @robertcnst. Are you able to reproduce this issue in a standalone project using a similar schema layout (deeply nested input objects) and faked response data? I think that's going to be the quickest route to finding a solution.

[calvincestari]

Workarounds exist, but an official fix or guidance would be highly valuable.

What are the workarounds you've found? You mentioned the following two but they're not really workarounds since you cannot ship to production using either.

Removing $filterGroup parameter from input prevents the crash (but it's needed for our use case)
Forcing ApolloAPI target to use -Onone also prevents the crash (even in Release)

[robertcnst]

Hey @calvincestari, thanks for getting back to me!

On your first point - I’ll work on a PoC today to try and reproduce this issue in a standalone project.

Regarding your second comment - "they’re not really workarounds since you cannot ship to production using either" - I was actually planning to ship the second option (forcing the ApolloAPI target to use -Onone). Could you clarify why you think that wouldn’t be possible? Any details, insights, or past experiences with this kind of setup would be really helpful.

Thanks again!

[calvincestari]

Regarding your second comment - "they’re not really workarounds since you cannot ship to production using either" - I was actually planning to ship the second option (forcing the ApolloAPI target to use -Onone). Could you clarify why you think that wouldn’t be possible? Any details, insights, or past experiences with this kind of setup would be really helpful.

I suppose it's a more subjective decision that is relevant to the org and product being shipped. While disabling the compiler optimization won't prevent you from shipping a Release build there are hidden 'costs' to doing so: larger binary, slower runtime performance, debug markers, etc. So if those are tenable for your org/product then yes it can be a workaround.

[robertcnst]

Thanks for the input, @calvincestari! 🙏

One thing I forgot to mention is that I’m using Tuist (https://tuist.dev/). After switching Apollo’s integration from .staticFramework to .framework, I started seeing a new crash in RequestChainNetworkTransport (screenshot attached).

[calvincestari]

We use Tuist in apollo-ios-dev too, I don't think that should be an issue.

After switching Apollo’s integration from .staticFramework to .framework, I started seeing a new crash in RequestChainNetworkTransport (screenshot attached).

I'm pretty sure that is related to the change in linking; static vs. dynamic. Is there a specific reason you changed? We've found that in most cases it's better to just let SPM/Xcode decide how to handle the linking of dependencies.

[robertcnst]

Is there a specific reason you changed?

Not necessarily - we’re just exploring different approaches to narrow down what might be causing the crash, and this was one of the checks.

Unfortunately, I couldn’t reproduce the crash using the same schema and query in a standalone project. One key difference between that setup and the app I’m working on is the use of Tuist.

@calvincestari - would it be possible to have a more direct conversation about this (Slack or something else)? That would be super helpful!

Thank you! 🙏

[robertcnst]

Hello @calvincestari, I wanna share with you the latest findings on this issue:

• raw data: __data["searchTransactions"] contained AnyHashable(DataDict)
• the AnyHashable.base contained the actual DataDict object
• key Finding: Two different ApolloAPI.DataDict types with different memory addresses:
• (0x10d290e70) - the actual object
• (0x1251fd488) - the type being cast to
• this indicated multiple copies of the same type loaded at runtime

Framework linking investigation

• Apollo: Dynamic Frameworks (.framework): Created mangled name errors and protocol conformance issues
• Apollo: Static Frameworks (.staticFramework): Both Apollo and ApolloAPI static caused type duplication across modules
• Hybrid solution: Apollo as .staticFramework + ApolloAPI as .framework resolved both issues

It looks like the crash is not reproducible anymore when Apollo is linked as .staticFramework and ApolloAPI as .framework.

You said that you are also using Tuist - I am curious on how you link Apollo & ApolloAPI and if you see any potential issue with this "hybrid" solution.

Thank you!

[AnthonyMDev]

It does make sense to me that ApolloAPI should be linked dynamically. It's being linked to Apollo, but also to your generated models and to your application code (which each could live in separate targets), that's probably causing this issues.

I wonder if using mergable libraries would give us the best of both worlds. That's a project setting you need to set though, not something we can configure in the package itself.

[calvincestari]

Hi @robertcnst,

You said that you are also using Tuist - I am curious on how you link Apollo & ApolloAPI

That's correct - we do use Tuist, you can see the way we build that up here, but I think our usage of it and the targets we build end up being quite different to what a production end-user app might need. We also do not specify static vs dynamic in our configuration; we simply leave it up to Tuist/SPM/Xcode to figure out. Granted that if we encountered linking type errors we'd probably need to get more specific on how they're linked.

if you see any potential issue with this "hybrid" solution.

The hybrid solution seems to make sense as @AnthonyMDev has mentioned. It's subjective to each project's targets/modules though. As long as you've resolved the runtime crash and any build time errors I'd trust the compiler here.

[rishabhtpdl]

Any solution for this problem? We are also facing this crash. #3582 (comment)

[AnthonyMDev]

It looks like the crash is not reproducible anymore when Apollo is linked as .staticFramework and ApolloAPI as .framework.

This is the current workaround. We haven't had the time to dig into this too much more yet. Can you verify if that works for you.