Strange delay when opening a view

[Paul-Svetlichny]

Hey guys. Hope you are doing well!

I'm having strange issue with using TCA. It's a hybrid project, where we are trying to implement some components with TCA version 1.9.2. The issue is that when I press a button, which just adds a TCA view on the screen, it takes about 2 seconds to show it. No matter how complicated it is, like if it only has a couple of Text components in it, it still takes 1.5-2 seconds to show up.
Our "native" screens open up immediately. Is there something that we are doing wrong or is it just a normal view loading performance with TCA?
Please find the view code below. In the example there are two "components" added to the screen, both with no actions (I know they can be just simple views, but I'm trying to build and learn, so creating them as TCA components). One is just a header with 3 lines of text, and the other is our own more complex component, which we use in other views normally, and the TestView opens up slowly with and without it, so it itself is not the cause of the issue.
The "Report" object is mocked and is there just to imitate the initial loading of the report from the outside world.

import SwiftUI
import ComposableArchitecture

@Reducer
struct WeeklyReportsTest {
@Dependency(\.navigationManager) private var navigationManager

@ObservableState
struct State {
    var header = WeeklyReportsHeader.State()
    var weeklyOverview = WeeklyReportsOverviewScore.State()
}

enum Action {
    case back
    case onAppear
    case header(WeeklyReportsHeader.Action)
    case weeklyOverview(WeeklyReportsOverviewScore.Action)
}

var body: some ReducerOf<Self> {
    Scope(state: \.header, action: \.header) {
        WeeklyReportsHeader()
    }
    Scope(state: \.weeklyOverview, action: \.weeklyOverview) {
        WeeklyReportsOverviewScore()
    }
    Reduce { state, action in
        switch action {
        case .back:
            navigationManager.back()
            return .none
        case .onAppear:
            let report = WeeklyReport.mocked
            state.header.report = report
            state.weeklyOverview.average = report.score.average
            return .none
        }
    }
}
}

struct WeeklyReportsTestView: View {
let store: StoreOf<WeeklyReportsTest>

var body: some View {
    VStack(spacing: 48) {
        WeeklyReportsHeaderView(store: store.scope(state: \.header, action: \.header))
            .frame(maxWidth: .infinity, alignment: .center)
        
        WeeklyReportsOverviewScoreView(store: store.scope(state: \.weeklyOverview, action: \.weeklyOverview))
            .frame(maxWidth: .infinity, alignment: .center)
    }
    .onAppear { store.send(.onAppear) }
}
}

#Preview {
WeeklyReportsTestView(
    store: Store(
        initialState: WeeklyReportsTest.State()
    ) {
        WeeklyReportsTest()
    }
)
}

Just to show the approach, here are child views without the View code for simplicity.

import SwiftUI
import ComposableArchitecture

@Reducer
struct WeeklyReportsHeader {
@ObservableState
struct State {        
    let title = "title"
    let lastWeekString = "last_week"
    var report = WeeklyReport()
    }
}
}

struct WeeklyReportsHeaderView: View {
let store: StoreOf<WeeklyReportsHeader>

var body: some View {
    VStack(spacing: 2) {
        Text(store.title)
            .font(.sofiaNormal(size: 12))
            .foregroundStyle(Color.koala)
        Text(lastWeekString)
            .font(.sofiaBold(size: 15))
            .foregroundStyle(Color.snow)
    }
}
}

And the other one

import SwiftUI
import ComposableArchitecture

@Reducer
struct WeeklyReportsOverviewScore {
@ObservableState
struct State {
    let title = "overview_title"
    var average = WeeklyReport.ScoreReport.Average()
}
}

struct WeeklyReportsOverviewScoreView: View {
let store: StoreOf<WeeklyReportsOverviewScore>
... some view code
}

Thanks in advance!

Best regards,
Paul.

UPD: We tried to add a couple more scopes, and we've got a fascinating result of waiting for 34 seconds to load a simple view, which we have no issues with showing without using TCA.
I have a feeling that we've done something terribly wrong, but I can't figure out what is it.

[mbrandonw]

Hi @Paul-Svetlichny, no there is no penalty to creating a Store and presenting a TCA feature. You can run any of the dozens of case studies and demos in the repo to see that there is no delay when navigating around, or check out isowords, a complex app with dozens of screens built entirely in SwiftUI and TCA.

There's really not much we can do to help without a minimal project that reproduces the problem. Can you try providing something? Also the time profiler can help find stack frames that take a long time to execute.

[Paul-Svetlichny]

And another thing, the delay happens when the View asks for Store data.
For example, this single line cause a small delay of half a second (just visible glitch)
Text(store.header.title)
But at the same time, this line doesn't cause any glitch at all:
Text("store.header.title")

[Paul-Svetlichny]

And one more thing is that when I turn on full logging, I'm starting to get this error massively when loading a screen with TCA:
Perceptible state was accessed but is not being tracked. Track changes to state by wrapping your view in a 'WithPerceptionTracking' view.

[Paul-Svetlichny]

So finally it appeared that adding WithPerceptionTracking { } to the View solves the problem.
Can somebody please explain why? :)
And also why it only slows things down in the Debug build, and not in the Release one?

[stephencelis]

@Paul-Svetlichny If you support <iOS 17 and are using observation tools, you must install WithPerceptionTracking views for iOS 16 and less to actually update the UI when state changes are observed.

In Debug builds, we emit runtime warnings when we detect access to observable state in a view that is not using WithPerceptionTracking. These runtime warnings are meant to help you catch bugs in your app before releasing it to your users. While we do our best to make these checks speedy, it is still quite an expensive thing to analyze at runtime, and involves demangling Swift symbols in the stack. So these are just trade-offs to back-porting observation and making it easy to catch moments where WithPerceptionTracking is missing.

Let us know if you have any more questions or if you think these checks should not apply to you!

[mbrandonw]

And it's also worth mentioning that it is only when we catch a problem that it is an expensive operation. If we detect that WithPerceptionTracking is being used correctly we cache that result and then we don't need to compute it again (for that view).

So, if you had a lot of state access in a view without properly using WithPerceptionTracking, then you will incur a lot of perception checks.

Be sure to read the documentation on the observation back port to understand how these tools work.

[Paul-Svetlichny]

Thank you for reply and explanation! We are supporting iOS 16 and it was not an obvious requirement to use Perception, though it helped and now everything seems to be working without glitches.

Best regards,
Paul.