Unwanted presentation behavior

[chaudharyvikram]

Description

I’ve implemented TCA in a large-scale project with over 100 screens to navigate between. For navigation, I followed the official documentation. However, when I added more than 35 cases to the Path enum (specifically in the home screen’s reducer), the app started crashing at runtime when opening the Home tab — but only on real devices, not in the simulator.

To confirm the issue, I created a demo with more than 35 screens, and it worked fine. But even when using a random set of 35+ cases in the main project, the crash persisted on device. After some investigation, I tried replacing the enum with a struct for the path. That resolved the crash, but introduced a new issue — screens started presenting and dismissing in a loop until the app was terminated.

This behavior seems to stem from delegation actions triggered from the presented screens. These actions send messages back to the reducer that originally pushed the screen, which then refreshes the entire navigation path. To avoid this stack refresh, I tried applying .id to the view, which did prevent the refresh — but at the cost of breaking the default present/dismiss animations, and the navigation stack still refreshes 2–3 times in some cases.

I’ve attached both the code and a video that shows the behavior.

Could you please review and let me know if I’ve implemented something incorrectly or misunderstood part of the architecture?

https://share.icloud.com/photos/057FgD4tr_P5LxxLgR1acS_LA

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

Presenting and dismissing screens should animate correctly and behave predictably.
• Sending actions from a presented screen back to its presenter should not reset or refresh the entire navigation path.
• Applying .id() should prevent unnecessary reinitialization or path refreshes without affecting transition animations.

Actual behavior

The app crashes on real devices when the Path enum contains more than 35 cases, particularly when opening the Home tab.
• The issue does not reproduce on the simulator or in isolated demo projects, even with the same number of cases.
• Switching to a struct for navigation path avoids the crash, but causes screens to get stuck in a presentation/dismissal loop.
• This loop is triggered when delegation actions are sent from a presented screen back to the presenting reducer, causing the entire path to refresh.
• Adding .id() to preserve view identity prevents the navigation reset but disables present/dismiss animations and does not fully prevent 2–3 redundant refreshes of the navigation stack.

https://share.icloud.com/photos/057FgD4tr_P5LxxLgR1acS_LA

Reproducing project

TCANavigationStructure 3.zip

The Composable Architecture version information

1.20.2

Destination operating system

iOS 18.5

Xcode version information

Xcode 16.4

Swift Compiler version information

<decode: bad range for [%@] got [offs:398 len:784 within:0]>
<decode: bad range for [%@] got [offs:398 len:784 within:0]>
<decode: bad range for [%@] got [offs:462 len:784 within:0]>
<decode: bad range for [%@] got [offs:462 len:784 within:0]>
<decode: bad range for [%@] got [offs:430 len:784 within:0]>
<decode: bad range for [%@] got [offs:430 len:784 within:0]>
<decode: bad range for [%@] got [offs:410 len:784 within:0]>
<decode: bad range for [%@] got [offs:430 len:784 within:0]>
<decode: bad range for [%@] got [offs:410 len:784 within:0]>
<decode: bad range for [%@] got [offs:430 len:784 within:0]>

[mbrandonw]

Hi @chaudharyvikram, this project is using a mixture of old an new tools that are not compatible with each other. On the one hand you are using @Observable state and @Bindable stores, but then also for some reason you are using WithViewStore and NavigationStackStore, which have been deprecated for over a year.

There are also purple runtime warnings explaining exactly what is wrong:

🟣 Store+Observation.swift:92 Scoping from uncached StoreOf is not compatible with observation.

This can happen for one of two reasons:

• A parent view scopes on a store using transform functions, which has been deprecated, instead of with key paths and case paths. Read the migration guide for 1.5 to update these scopes: https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/migratingto1.5

• A parent feature is using deprecated navigation APIs, such as 'IfLetStore', 'SwitchStore', 'ForEachStore', or any navigation view modifiers taking stores instead of bindings. Read the migration guide for 1.7 to update those APIs: https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/migratingto1.7

In particular, this second bullet point is your situation. You are using old navigation APIs.

I have modernized your demo and now it works just fine:

TCANavigationStructure.zip

Since this isn't an issue with the library I am going to convert it to a discussion. Please feel free to continue the conversation over there!

[chaudharyvikram]

Hi @mbrandonw
Thanks for your quick reply.

I’ve already tried using the latest structure as shown in the demo project. However, when I add more than 35 reducers/cases to the Path enum, it results in a runtime crash — but only on a physical device. The crash goes away if I comment out or remove enough cases to bring the count down to 35 or fewer. I’m unable to share the full source code, but I’ve attached a screen recording that demonstrates the issue.

https://share.icloud.com/photos/03bNRPd5WZhifTtASd1yOv0ig

[mbrandonw]

Hi @chaudharyvikram, it sounds like you are running into stack overflow problems. There are things you can do to mitigate it, such as boxing things in references. There is also a long standing bug in Swift that causes it to use more stack space than necessary for large switches, and though it sounds weird, a way to work around is like so:

case .action:
  return {
    // Reducer work in here
  }()

But also, you just may be meeting the limitations of Swift in general. Is it really necessary to have 100+ features integrated together into one single feature? TCA's feature composing tools are powerful, but that doesn't mean you can necessarily compose hundreds of features together and not expect any consequences.

I think if you really do have so many different features capable of being pushed onto the stack then you might need to de-integrate them. That is, you will not compose all of their reducers together, and instead you will navigate to child feature by creating an isolated store to just that feature. Then you will need to find ways to communicate from the child feature back to the parent, but that's just how things work in vanilla SwiftUI too.

[chaudharyvikram]

Thanks @mbrandonw

I'll try to divide all compostables in module wise. Will present base screen of each module and then handle navigation for that particular module in that module only. This will reduce cases in Main feature and I think it will not cause any problem.