Performance Issues with High-Frequency .onAppear Actions in Sectioned Layout

[topkim993]

Hi there,

We're using TCA quite extensively and generally very satisfied with the architecture. However, we've recently run into a performance issue in a view that requires rendering multiple sections (order-independent), each containing a number of items.

Each item triggers an impression log when it appears. While our actual implementation has a more elaborate impression tracking system, we've simplified the reproduction case to just use .onAppear.

We've attached a minimal project that replicates the issue.

From what we can tell, the problem seems related to a high frequency of .onAppear actions, especially in sections that contain many small items. In contrast, sections with fewer large items don’t exhibit the same kind of lag.

As the number of .onAppear calls increases while scrolling, we start to see hitching and frame drops.

Questions:

• Is there a recommended way to optimize .onAppear actions in TCA, especially when they are triggered at high frequency due to many small items appearing on scroll?

• Also, does having a computed property for id in enum-based SectionFeature.State pose a performance risk?

  • We've seen mentions that computed id properties might be less efficient than storing it directly—do you have any insight or benchmarks related to this?

public var id: UUID {
    switch self {
    case let .aSection(state): return state.id
    }
}

Thanks in advance!

Download Example Project

Pure SwiftUI	TCA

[mbrandonw]

Hi @topkim993, thanks for opening this discussion.

While your project does show a stark difference in vanilla SwiftUI and TCA, there are a few important caveats to note:

• You are pinning to exactly 1.16.1 of TCA for some reason, but 1.20.2 is the newest version of TCA.
• Did you run in RELEASE or is your gif a DEBUG build?
• And finally, and most important, the vanilla SwiftUI and TCA versions of your feature are not an "apples to apples" comparison.

The last point is very important, and it comes up a lot when trying to compare TCA to vanilla SwiftUI, so I'd like to explain a bit more.

There are a number of important differences between the vanilla SwiftUI version of your feature and the TCA one.

• The vanilla SwiftUI version of your feature has none of the capabilities that the TCA version has. It has no effect management, it has no parent-child communication mechanisms, it has no navigation tools built into it (such as @Dependency(\.dismiss), child feature cancellation, etc...), it doesn't handle async effect re-entrancy, and most importantly, it is very difficult to test. So, if you want an actual apples-to-apples comparison you would need to recreate many of the tools that TCA gives you and then see how the performance differs.

• The TCA version of the feature has been enhanced with enum state but the vanilla SwiftUI version does not have this functionality. This is another example of a tool that TCA gives that vanilla SwiftUI does not. We allow one to model their domains as concisely as possible using enums, and the library does extra work to make sure that effects are torn down when switching between cases of the enum. And that's great that TCA provides these tools, but you would need to recreate all of that in vanilla SwiftUI for a more fair comparison.

• The feature you provided as an example is quite pathological, and I don’t think any TCA app out there should be structured like this. This kind of demo is often presented to us as a way to push TCA to the extremes and show a problem, but in reality it is almost never the case that an app has an expansive grid of hundreds of visible cells where each cell has complex and nuanced logic and side effects. Instead, typically grids like this have just a whole bunch of static content and there is absolutely no need whatsoever to dedicate an entire TCA reducer and Store to each cell. And so if you removed the store from each cell, things would be just as performance as vanilla SwiftUI.

  However, if you really do feel that you need an entire TCA reducer and Store for each cell of the grid, then there are ways to accomplish this. You just can’t have everything integrated together in one single reducer because that creates a complex feature with infinite communication between parent and child (and again, if you were to recreate this tool in vanilla SwiftUI you would come across similar problems). The trick is to use isolated stores. In this situation you do not integrate features together at each layer, and instead you create the store in the view (without scoping) and hold onto the store in a @StateObject. This has the same performance as vanilla SwiftUI, but with the benefit that each feature is built in TCA, it’s just that the features are not integrated together.

  I have an example of this with your code below:

  Expand code

  // MARK: - ContentView
  
  struct TCAContentView: View {
    static let store = Store(
      initialState: HomeFeature.State(
        id: UUID(),
        text: "Home",
        container: ContainerFeature.State(
          id: UUID(),
          items: []
        )
      ),
      reducer: {
        HomeFeature()
      }
    )
  
    var body: some View {
      HomeView(
        store: Self.store
      )
    }
  }
  
  struct HomeView: View {
    let store: StoreOf<HomeFeature>
  
    var body: some View {
      VStack {
        Text(store.text)
        ContainerView(
          store: store.scope(state: \.container, action: \.container)
        )
      }
      .onAppear {
        store.send(.onAppear)
      }
    }
  }
  
  struct ASectionView: View {
    @StateObject var store: StoreOf<ASectionFeature>
    init(item: ASectionFeature.State) {
      _store = StateObject(
        wrappedValue: Store(initialState: item) {
          ASectionFeature()
        }
      )
    }
  
    var body: some View {
      VStack(alignment: .leading) {
        Text(store.text)
        ScrollView(.horizontal) {
          LazyHStack {
            ForEach(store.items) { item in
              ItemView(item: item)
            }
          }
        }
      }
    }
  }
  
  struct ItemView: View {
    @StateObject var store: StoreOf<ItemFeature>
    init(item: ItemFeature.State) {
      _store = StateObject(
        wrappedValue: Store(initialState: item) {
          ItemFeature()
        }
      )
    }
  
    var body: some View {
      Text(store.text)
        .onAppear {
          store.send(.onAppear)
        }
    }
  }
  
  // MARK: - HomeFeature
  
  @Reducer
  struct HomeFeature {
    @ObservableState
    struct State: Equatable, Identifiable {
      let id: UUID
      let text: String
      var container: ContainerFeature.State
    }
  
    enum Action {
      case onAppear
      case setContainerItems(IdentifiedArrayOf<ASectionFeature.State>)
      case container(ContainerFeature.Action)
    }
  
    var body: some Reducer<State, Action> {
      Scope(state: \.container, action: \.container) {
        ContainerFeature()
      }
      Reduce { state, action in
        switch action {
        case .onAppear:
          return .run { send in
            let items: IdentifiedArrayOf<ASectionFeature.State> = .init(
              uniqueElements: (0..<300).map { sectionIndex in
  
                  ASectionFeature.State(
                    id: UUID(),
                    text: "A\(sectionIndex)",
                    items: IdentifiedArrayOf(
                      uniqueElements: (0..<20).map { itemIndex in
                        ItemFeature.State(
                          id: UUID(),
                          text: "B\(itemIndex)"
                        )
                      }
                    )
                )
              }
            )
            await send(.setContainerItems(items))
          }
  
        case .setContainerItems(let items):
          state.container.items = items
          return .none
        case .container:
          return .none
        }
      }
    }
  }
  
  // MARK: - ContainerFeature
  
  @Reducer
  struct ContainerFeature {
    @ObservableState
    struct State: Equatable, Identifiable {
      let id: UUID
      var items: IdentifiedArrayOf<ASectionFeature.State>
    }
  
    enum Action {
    }
  
    var body: some Reducer<State, Action> {
      Reduce { _, action in
        switch action {
        }
      }
    }
  }
  
  struct ContainerView: View {
    let store: StoreOf<ContainerFeature>
  
    var body: some View {
      ScrollView {
        LazyVStack {
          ForEach(store.items) { item in
            ASectionView(item: item)
          }
        }
      }
    }
  }
  
  // MARK: - ASectionFeature
  
  @Reducer
  struct ASectionFeature {
    @ObservableState
    struct State: Equatable, Identifiable {
      let id: UUID
      let text: String
      var items: IdentifiedArrayOf<ItemFeature.State>
    }
  
    enum Action {
    }
  
    var body: some Reducer<State, Action> {
      Reduce { _, action in
        switch action {
        }
      }
    }
  }
  
  // MARK: - ItemFeature
  
  @Reducer
  struct ItemFeature {
    @ObservableState
    struct State: Equatable, Identifiable {
      let id: UUID
      let text: String
    }
  
    enum Action {
      case onAppear
    }
  
    var body: some Reducer<State, Action> {
      Reduce { _, action in
        switch action {
        case .onAppear:
          // send impr log
          return .none
        }
      }
    }
  }

[topkim993]

Thank you so much for the detailed feedback — it’s been incredibly helpful in clarifying things. I'd like to share a few follow-up thoughts and continue the discussion to ensure I'm understanding things correctly.

You are pinning to exactly 1.16.1 of TCA for some reason, but 1.20.2 is the newest version of TCA.

Initially, we pinned to TCA 1.16.1 to match the same environment for comparison, but I’ve also tested with 1.20.2, and the performance characteristics remain the same in both cases.

Did you run in RELEASE or is your gif a DEBUG build?

The performance was measured in a RELEASE build. While it’s true that the RELEASE build is faster than DEBUG, the difference wasn’t very noticeable in this specific context.

Why this isn’t a fair comparison

I completely agree with your point here. We're using TCA specifically because of its strengths — testability, effect management, ...

My intention wasn’t to compare TCA unfairly, but rather to highlight how even a visually similar UI could exhibit noticeable performance differences under certain conditions.

Demo structure issue

You're absolutely right — the demo structure isn't representative of a typical TCA app in the general sense.

That said, in our actual app, we do have cases where each row or cell has its own logic and may trigger actions like tap, impression, or navigation. These cells appear in large quantities and are often displayed within scrollable views.

When users scroll quickly, the issue becomes more pronounced, as the rate of onAppear-driven actions (such as impression logging) increases rapidly. This accelerates the performance impact, sometimes resulting in noticeable jank or dropped frames.

I wanted to recreate a simplified version of this real-world scenario to better understand how TCA behaves under such conditions. While the demo is a bit synthetic, it's grounded in actual challenges we're facing.

Personally, I also find it more natural to attach a reducer to any cell that can send actions, since composability and clarity around action handling are key strengths of TCA.

About store isolation

I tried the isolated store approach using @StateObject inside each section, as you suggested.
It definitely improved performance — thanks for the tip!

That said, one trade-off I noticed is that once stores are isolated this way, it becomes harder for the parent to observe or interact with the child’s state or actions.

For example, if we isolate stores at the section level, and the container needs to react to something in that section, it requires extra wiring, which can be a bit cumbersome.

Also, when a child’s state changes and the view gets recreated due to SwiftUI’s lazy behavior, it sometimes resets to the parent’s state, which can lead to unexpected behavior.

🤔 An idea I’ve been thinking about

That led me to a thought: what if there were a way to prevent specific actions from bubbling up to the root?

For example, an impression event from a cell:

• Fires very frequently
• But doesn’t always need to be handled by the root or higher-level reducers

If there were a way to consume or intercept these events within a middle layer (and optionally block them from propagating), I think that would offer more flexibility and improve performance in large, dynamic UIs.

Is there a recommended way to handle this sort of pattern?

Thanks again for your time and thoughtful insights 🙏

Lastly, I’ve attached a sample project and a RELEASE build video demonstrating the performance using the latest version of TCA, with the same approach but a more typical layout to better reflect how our actual app is structured.

• TCAScope.zip

[mbrandonw]

That said, one trade-off I noticed is that once stores are isolated this way, it becomes harder for the parent to observe or interact with the child’s state or actions.

For example, if we isolate stores at the section level, and the container needs to react to something in that section, it requires extra wiring, which can be a bit cumbersome.

For example, if we isolate stores at the section level, and the container needs to react to something in that section, it requires extra wiring, which can be a bit cumbersome.

But this is the crux of what I am talking about. If you want the powers of parent features being able to inspect 100% of everything in the child, and child features being able to seamlessly communicate to the parent, there is a cost. And so you have to make hard decisions in your application based on the needs of your features, your users and your developer experience.

And so if you really do have a feature that can have dozens of little features displayed that each really do have enough complex logic and behavior to warrant their own reducer, then cutting off the integration between parent and child would be the trade off to make. Sure you need to implement extra wiring, but that is also exactly what you would have had to do in your vanilla SwiftUI version had it been a more complete reproduction of the TCA version.

Also, when a child’s state changes and the view gets recreated due to SwiftUI’s lazy behavior, it sometimes resets to the parent’s state, which can lead to unexpected behavior.

This should not be the case. Can you provide some more information or another demo that shows this behavior?

That led me to a thought: what if there were a way to prevent specific actions from bubbling up to the root?

No, this is not possible because when you send an action to a leaf child store, it doesn't actually handle the action at all. In fact, child stores are just thin layers of composed key paths sitting on top of the root store. So all actions go directly to the root.

But also, this kind of feature could lead to some incredibly confusing situations. In some deep leaf feature you decide to send onAppear in a "localized" manner, and many months later you forget that you are doing that and are confused why you can no longer intercept the onAppear in the parent.

Is there a recommended way to handle this sort of pattern?

The isolated store pattern is the recommended way. It solves the problems you are having and does not have the confusion I mentioned above. Since the parent and child features are not integrated together there is never the situation where the parent thinks it can snoop on the actions in the child because it doesn't even hold onto the actions of the child.

The isolated store approach still has many of the advantages of TCA (testing, value types, effect management, etc.), but it makes you responsible for communication patterns between child and parent. And as I said before, that is already something you are responsible for in vanilla SwiftUI.

And even the communication patterns can be made quite nice with the isolated store approach. You can even still use delegate actions:

struct ChildView: View {
  @StateObject var store: StoreOf<ChildFeature>
  init(state: ChildFeature.State, didComplete: @escaping (Bool) -> Void) {
    _store = StateObject(
      wrappedValue: Store(initialState: state) {
        ChildFeature()
        Reduce { state, action in 
          switch action {
          case .delegate(.didComplete(let result)):
            didComplete(result)
            return .none
          default:
            return .none
        }
      }
    )
  }
}

This uses the delegate action of the child to figure out when to invoke a callback closure provided by the parent. And you can still get a little bit of test coverage on this since you can easily confirm that the child feature sends its delegate actions properly.

[topkim993]

No, this is not possible because when you send an action to a leaf child store, it doesn't actually handle the action at all. In fact, child stores are just thin layers of composed key paths sitting on top of the root store. So all actions go directly to the root.
But also, this kind of feature could lead to some incredibly confusing situations. In some deep leaf feature you decide to send onAppear in a "localized" manner, and many months later you forget that you are doing that and are confused why you can no longer intercept the onAppear in the parent.

Oh, I see — I thought we could limit this kind of behavior using boundary actions when scoping.

I was thinking of something like in this discussion:
#1440

If we control what actions can go up using boundaries, I thought it would help make the intention clear and avoid unexpected interception from parents.

It’s a bit unfortunate that this kind of access control isn’t possible, but I get now that all actions still go through the root. Thanks for the explanation!

---

This should not be the case. Can you provide some more information or another demo that shows this behavior?

This is admittedly an extreme case, but it can be reproduced using the code you provided by making a small change: update the Item's text when it's tapped, and then scroll very quickly down and back up again.

@Reducer
struct ItemFeature {


    @ObservableState
    struct State: Equatable, Identifiable {
        let id: UUID
        var text: String
    }

    enum Action {
        case onAppear
        case didTapButton
    }

    var body: some Reducer<State, Action> {
        Reduce { state, action in
            switch action {
            case .onAppear:
                // send impr log
                return .none
            case .didTapButton:
                state.text = "Tapped!"
                return .none
            }
        }
    }
}

Expand full code

import SwiftUI

import ComposableArchitecture
import IdentifiedCollections

struct TCAContentView: View {
    static let store = Store(
        initialState: HomeFeature.State(
            id: UUID(),
            text: "Home",
            container: ContainerFeature.State(
                id: UUID(),
                items: []
            )
        ),
        reducer: {
            HomeFeature()
        }
    )

    var body: some View {
        HomeView(
            store: Self.store
        )
    }
}

struct HomeView: View {
    let store: StoreOf<HomeFeature>

    var body: some View {
        VStack {
            Text(store.text)
            ContainerView(
                store: store.scope(state: \.container, action: \.container)
            )
        }
        .onAppear {
            store.send(.onAppear)
        }
    }
}

struct ASectionView: View {
    @StateObject var store: StoreOf<ASectionFeature>
    init(item: ASectionFeature.State) {
        _store = StateObject(
            wrappedValue: Store(initialState: item) {
                ASectionFeature()
            }
        )
    }

    var body: some View {
        VStack(alignment: .leading) {
            Text(store.text)
            ScrollView(.horizontal) {
                LazyHStack {
                    ForEach(store.items) { item in
                        ItemView(item: item)
                    }
                }
            }
        }
    }
}

struct ItemView: View {
    @StateObject var store: StoreOf<ItemFeature>
    init(item: ItemFeature.State) {
        _store = StateObject(
            wrappedValue: Store(initialState: item) {
                ItemFeature()
            }
        )
    }

    var body: some View {
        Button(store.text) {
            store.send(.didTapButton)
        }
        .onAppear {
            store.send(.onAppear)
        }
    }
}

// MARK: - HomeFeature

@Reducer
struct HomeFeature {
    @ObservableState
    struct State: Equatable, Identifiable {
        let id: UUID
        let text: String
        var container: ContainerFeature.State
    }

    enum Action {
        case onAppear
        case setContainerItems(IdentifiedArrayOf<ASectionFeature.State>)
        case container(ContainerFeature.Action)
    }

    var body: some Reducer<State, Action> {
        Scope(state: \.container, action: \.container) {
            ContainerFeature()
        }
        Reduce { state, action in
            switch action {
            case .onAppear:
                return .run { send in
                    let items: IdentifiedArrayOf<ASectionFeature.State> = .init(
                        uniqueElements: (0 ..< 300).map { sectionIndex in

                            ASectionFeature.State(
                                id: UUID(),
                                text: "A\(sectionIndex)",
                                items: IdentifiedArrayOf(
                                    uniqueElements: (0 ..< 20).map { itemIndex in
                                        ItemFeature.State(
                                            id: UUID(),
                                            text: "B\(itemIndex)"
                                        )
                                    }
                                )
                            )
                        }
                    )
                    await send(.setContainerItems(items))
                }

            case .setContainerItems(let items):
                state.container.items = items
                return .none
            case .container:
                return .none
            }
        }
    }
}

// MARK: - ContainerFeature

@Reducer
struct ContainerFeature {
    @ObservableState
    struct State: Equatable, Identifiable {
        let id: UUID
        var items: IdentifiedArrayOf<ASectionFeature.State>
    }

    enum Action {}

    var body: some Reducer<State, Action> {
        Reduce { _, action in
            switch action {}
        }
    }
}

struct ContainerView: View {
    let store: StoreOf<ContainerFeature>

    var body: some View {
        ScrollView {
            LazyVStack {
                ForEach(store.items) { item in
                    ASectionView(item: item)
                }
            }
        }
    }
}

// MARK: - ASectionFeature

@Reducer
struct ASectionFeature {
    @ObservableState
    struct State: Equatable, Identifiable {
        let id: UUID
        let text: String
        var items: IdentifiedArrayOf<ItemFeature.State>
    }

    enum Action {}

    var body: some Reducer<State, Action> {
        Reduce { _, action in
            switch action {}
        }
    }
}

// MARK: - ItemFeature

@Reducer
struct ItemFeature {
    @ObservableState
    struct State: Equatable, Identifiable {
        let id: UUID
        var text: String
    }

    enum Action {
        case onAppear
        case didTapButton
    }

    var body: some Reducer<State, Action> {
        Reduce { state, action in
            switch action {
            case .onAppear:
                // send impr log
                return .none
            case .didTapButton:
                state.text = "Tapped!"
                return .none
            }
        }
    }
}

---

When using the isolated store approach, what’s the recommended way to pass dependencies down from a parent?

For example, in the parent, I can do:

ParentFeature()
  .dependency(\.timeZone, TimeZone(secondsFromGMT: 3600))

But when I isolate a child like this:

@Reducer
public struct ChildFeature {
  @Dependency(\.timeZone) var timeZone

  var body: some Reducer<State, Action> {
    ...
    print("timeZone: \(timeZone)")
    ...
  }
}

The child doesn’t seem to receive the dependency that was set up in the parent.
How should I inject dependencies into isolated child stores in this case?

---

When the parent wants to modify a child's state, for example:

case .didTapModify:
  if let firstItem = state.items.first,
     case var .aSection(aSection) = firstItem {
    aSection.id = UUID() // Force reinitialization by changing view identity
    aSection.text = "Modified"
    state.items[0] = .aSection(aSection)
  }

It seems we have to change the id to trigger the state update. But if the child itself has changed its state, this reinitialization can reset those child changes unexpectedly.

To prevent this, I was thinking of using a handler to keep the parent and child state in sync continuously.

Is this the right approach? Also, is changing the id in this way considered appropriate? Or is there a better pattern to handle parent-driven state changes without overriding child changes or forcing reinitialization?

---

To better illustrate the questions above, I've attached a sample project that reproduces these cases.
Appreciate any insights or suggestions you might have—thank you!

• ExampleProject.zip

[topkim993]

When using the isolated store approach, what’s the recommended way to pass dependencies down from a parent?

Not sure if this is the best approach, but I got it working and figured I'd share in case it helps anyone else.

1. Define the feature member variable like this:

struct ParentFeature {
    @Dependency(\.self) private var dependencies
    ...
}

2. Declare dependencyValues in the parent Feature State:

struct ParentFeature {
    struct State {
        var dependencyValues: DependencyValues?
        var child: ChildFeature.State
    }
    ...
}

3. Save to state at onAppear:

struct ParentFeature {
    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .onAppear:
                state.dependencyValues = dependencies
                return .none
            }
        }
    }
}

4. Create child stores manually:

struct ChildView: View {
    @StateObject var store: StoreOf<ChildFeature>
    
    init(state: ChildFeature.State, dependencyValues: DependencyValues) {
        _store = StateObject(
            wrappedValue: Store(initialState: state) {
                ChildFeature()
                    .dependency(\.self, dependencyValues)
            }
        )
    }
}

5. Inject dependencies from the parent like this

struct ParentView: View {
    ...
    if let dependencyValues = store.dependencyValues {
        ChildView(state: store.child, dependencyValues: dependencyValues)
    }
}

[ecito]

We had performance issues due to our cell's/item's .onAppear actions, which further triggered actions in the item's children... things like fetching the latest state from dependencies, setting up long-living observations, analytics, etc. Just the action overhead ended up taking up half the CPU while scrolling.

See here, in hindsight the red circle could probably encompass all the little stuff to the right as well:

After jiggling things around it now looks like this:

The change, which seemed impossible at first, was to completely avoid .onAppear actions for the cells. Items still have their own store, we just avoid sending the high-frequency actions that scrolling entails. This required doing some stuff outside of reducers, and updating item states in bulk via one update action at the collection level reducer.

In your case, if you're just doing impression logging, likely you can access your impression dependency directly in the View's .onAppear modifier (and access store state if needed).

[topkim993]

Thanks for the reply!

We were aware that frequent .onAppear actions could impact performance, but seeing it clearly through Instruments really drove the point home.

That said, in our case, we inject dependencies like logSender inside the Feature using something like:

// Feature
@Dependency(\.logSender) var logSender

Which makes it difficult to access those dependencies directly from the view. While we can still access the state through the store, we can’t do something like:

// View
.onAppear {
  store.logSender(store.logData) // ❌ Not accessible
}

Also, beyond impression logging, we do have a few other actions (though less frequent), and it's a bit unfortunate that some are handled in the view and others in the feature—it feels a bit scattered.

That said, considering the overhead of managing multiple stores, I do agree that this approach makes a lot of sense for handling high-frequency actions. Thanks again for sharing the insight—very helpful!

[topkim993]

Related discussions

• Scrolling performance of heavy children #3399
• Performance - Send Recursion #1290