Observation beta

[mbrandonw]

Important

This discussion has gotten too long for us to reasonable keep track of, so we are locking it. If you have questions or comments about the observation beta, please create a new discussion.

Hello all, today we are beginning what is perhaps the most important beta for the Composable Architecture, ever.

We are bringing Swift 5.9’s observation tools to the library, and we are doing so in a way that is backwards compatible with the current version of the library, and backwards compatible with older versions of iOS. That’s right. Even if you are targeting iOS 13 you will be able to use all the new tools we are previewing today.

To try out the beta you can point your dependency on the Composable Architecture to the observation-beta branch. We have prepared a migration guide that can be followed to try updating some of your features.

We do not recommend depending on this beta branch for long term, active development of your application. It is likely to have many breaking changes in the coming weeks or months until its final release.

But we would appreciate if everyone could point their projects to the observation-beta branch and let us know a few things:

1. Does your project still compile? We always aim for releases to be backwards compatible, and so this one is no exception.
2. Does your test suite still pass and does your app still work the same as it did before?
3. Can you update some of your features to use @ObservableState and let us know if it works for you? Does your app still behave the same?
4. Can you update some of your uses of IfLetStore, ForEachStore, SwitchStore, etc. to instead use simpler constructs, as detailed in the migration guide. Does everything still behave the same?
5. Can you update some of your uses of sheet(store:) with sheet(item:), popover(store:) with popover(item:), etc., as detailed in the migration guide.

[catienza022]

I've been keeping up with the latest TCA stuff on a side project. It's not huge but it does have 15 small-ish features with reducers now. I just sat down to play with the new stuff but I'm having issues migrating. The project compiled and ran fine pointed at the observation-beta branch. I am targeting iOS 17 and was already up to date with release 1.4.x, though.

I tried starting at the app reducer level, as recommended in the migration guide, but I'm struggling already with my tabView. I added the @ObservableState macro to my TabFeature.State and immediately get an error that my state must conform to hashable and also:

Property '_$id' must be declared public because it matches a requirement in public protocol 'ObservableState'

[stephencelis]

@davdroman Strangely the issue goes away if you add @ObservableState to the Todo type.

We're not sure if this is a SwiftUI bug or something we can work around, but will look into it further. If you have any ideas, let us know!

[davdroman]

@stephencelis hmmm... the issue does go away for a bit longer, but after a while of switching back and forth between fields and editing them the issue resurfaces.

[stephencelis]

@davdroman I'd be curious if you can repro in a much simpler example. The custom font, etc., stand out as things that could cause SwiftUI to get into a weird state with auto layout. Not to say TCA's binding acrobatics don't exacerbate the situation, but I'm curious how general the issue is.

[davdroman]

@stephencelis not sure why but using the observation-beta-modify branch the issue is fixed.

[mbrandonw]

@davdroman well, that's promising, though I don't really understand why. We will hopefully merge that branch in sometime this week.

[coenttb]

Dear Stephan and Brandon, amazing work, this is all looking incredible.
I hope to help by pointing out 2 findings.

1.
For our projects, we use nested typed extensions. For example:

@Reducer
struct X {
    ....
}

public extension X {
   @ObservableState
    struct State:Equatable {...}
}

public extension X {
   @CasePathable
    enum Action {...}
}

I find that in the case of an extension housing the Action for X, the following code is generated by the macro:

public extension X {
    @CasePathable
    enum Action: Equatable {...}

   extension PuzlBookkeeping.Action: CasePaths.CasePathable {
   }
}

For the avoidance of doubt: I am pointing out that the extension statement is inserted in an existing extension statement. This is not valid swift code.

2.
Additionally, I find that where I create an additional initializer for State structs:

public extension X.State {
    init(
        y:Y
    ) {
        self = .init(...)
    }
}

That I get the error: "Immutable value 'self._$observationRegistrar' may only be initialized once". I am not sure why this is happening, but the code otherwise compiles and works correctly pre-observation-beta.

I hope these findings are helpful to you. Thank you for providing us with this extraordinary library.

[coenttb]

Dear Brandon,

In the following, when I comment out @Reducer, it compiles just fine. If I do not comment it out, it doesn't compile, and throws errors ("'Y' is not a member type of struct 'X'; Circular reference resolving attached macro 'Reducer'; Circular reference"). I tried this in an empty new package, importing solely the Observation beta version of TCA.

import ComposableArchitecture

@Reducer
struct X:Equatable, Reducer {
    var body: some ReducerOf<Self> {
        EmptyReducer()
    }
}

extension X {
    @ObservableState
    struct State:Equatable {
        
    }
}

extension X {
    enum Action:Equatable {
        case test(String)
    }
}


extension X {
    @Reducer
    struct Y {
        
    }
}

extension X.Y {
    struct State:Equatable {
        
    }
}

extension X.Y {
    enum Action:Equatable {
        case test(String)
    }
}

I believe this is the minimal working example, and it could very well be that my other errors are a consequence of this.

[mbrandonw]

Hi @tenthijeboonkkamp, this is a bug in the Swift compiler and we have documented it here.

Are you currently running on the newest TCA 1.5 and using the @Reducer macro before trying out this beta? We recommend you update to the newest TCA before trying the observation beta because this issue is not related to the observation tools mentioned in this discussion.

[coenttb]

Thank you for pointing this out @mbrandonw, I wasn't aware this relates to 1.5 and not Observation-beta. I had not upgraded fully to 1.5 (just leaf nodes), but I think I did see the error when I was experimenting with 1.5, too.

I will hold out for swift complier improvements to allow for this pattern (the 'circular references').

[coenttb]

Dear @mbrandonw ,

Upon further investigation, one of my earlier issues does persist AND only relates to the beta. The following code gives the error: "Immutable value 'self._$observationRegistrar' may only be initialized once".

import ComposableArchitecture

@Reducer
struct X:Equatable, Reducer {
    var body: some ReducerOf<Self> {
        EmptyReducer()
    }
    
    @ObservableState
    struct State:Equatable {
        var test:String
        
        init(test: String) {
            self.test = test
        }
        
        init(){
            self = .init(test: "hello")
        }
        
    }
    @CasePathable
    enum Action:Equatable {
        case test(String)
    }
}

Commenting out the second init removes the error, and successfully compiles. Also, changing the second init to not refer to the first init (so its 'non-convenience') also fixes it.

[mbrandonw]

Hi @tenthijeboonkkamp, sorry lost track of this in this large discussion. I'm not sure there is much we can do about this. It is happening because the _$observationRegistrar is defined as let with a default value. Structs defined like that cannot do self = … in their initializers.

This simple example demonstrates the problem:

struct Foo {
  let x = 1
  init() {
    self = .init()  // 🛑 Immutable value 'self.x' may only be initialized once
  }
}

Perhaps Swift could allow this someday, but unfortunately it does mean you cannot initialize structs like this when using @ObservableState.

[mycroftcanner]

In our project, we previously managed different representations of the same state using two distinct viewStates: one for a minimal cell in a list and another for a detailed state page. This was achieved using a viewStore. Now, with the viewStore removed, how can we maintain this level of differentiation in our views? @mbrandonw @stephencelis

[mycroftcanner]

Using computed properties?

[mbrandonw]

Hi @mycroftcanner, the observation tools handle this for you automatically so that you do not need to manually manage view state. Can you share some example code of what you do in your code base so that we can understand what it is you are trying to achieve?

[mbrandonw]

Yes, computed properties on the state can work just fine.

[davdroman]

This might be a silly question as I don't have a lot of experience with macros yet, but wouldn't it be possible to abstract WithPerceptionTracking as a macro that you attach to the view struct declaration which then tacks it onto the body for you?

@PerceptionTracking
struct FeatureView: View {
    var body: some View {
        VStack { ... }
    }

    // synthesized:
    var body: some View {
        WithPerceptionTracking {
            VStack { ... }
        }
    }
}

[stephencelis]

That macro unfortunately does not exist yet: https://forums.swift.org/t/function-body-macros/66471/1

[stephencelis]

Also, a more subtle issue is that you WithPerceptionTracking needs to occur in every escaping closure, so sheets, popovers, and more, so even when function body macros are a thing we're not sure it's worth using this mechanism, since it's partial, and since this is for a feature that is eventually going away anyway.

[davdroman]

Thanks for these clarifications, makes sense 🙂

[larryonoff]

‪My initial feedback.‬

‪1. It would be great having more examples of using new tools. The best for me is always isowords.‬
‪2. I don’t understand is it safe use nested WithPerceptionTracking, e.g. for ForEach children.‬
‪3. I don’t understand how use Observation when ‬State is a model object that doesn't have @ObservableState macro attached.
4. Should WithPerceptionTracking wrap sheet, fullScreenCover, etc. modifiers?
5. Some animations were broken. I assume that it's since the mix of ViewStore and WithPerceptionTracking + Store.

Thanks for such a great changes.

[larryonoff]

This is expected. You are only allowed to reach into store's state when the feature is using @ObservableState. Otherwise you would run the risk of accessing state in the store that is not actually observed by the view.

Do you think there're some better options than attaching @Percetible? I ask since you already did swiftui-navigation or swift-concurrency-extras :)

[mbrandonw]

I'm sorry, I do not understand the question. Can you explain more?

[larryonoff]

Is there any better options to avoid using @Percetible to make model object (e.g. Recipe) observable? I would like to avoid marking model objects with @Percetible

[mbrandonw]

Hi @larryonoff, if you don't want to mark Recipe with the @ObservableState macro then you just have to introduce a dedicated domain/reducer for a single recipe, and mark that State with @ObservableState:

@Reducer
struct RecipeItem {
  @ObservableState
  struct State {
    var recipe: Recipe
  }
  // ...
}

@Reducer
struct Recipes {
  @ObservableState
  struct State {
    var recipes: IdentifiedArrayOf<RecipeItem.State> = []
  }
  // ...
}

struct RecipesView: View {
  let store: StoreOf<Recipes>
  
  var body: some View {
    ForEach(store.scope(state: \.recipes, action: \.recipes)) { store in
      RecipeItem(store: store)
    }
  }
}

struct RecipeItem: View {
  let store: StoreOf<RecipeItem>
  var body: some View {
    Text(store.name)  // ✅
  }
}

[larryonoff]

@mbrandonw awesome advice. Thank you

[ocapmycap]

I had been struggling to create a heterogenous list view that would display based on enum case and kept getting lost trying to keep track of all my IfCaseLet and scoping logic, so I pared back to the simplest example I could think of... and still got lost.

But after reading the migration guide I implemented a trivial example and was so impressed how much better this syntax flows. The only issue I ran into was a TextField that wouldn't update with $store.text syntax. And, likely not your fault, but any struct tagged with @ObservableState would not work with the extension Sourcery Pro (below a failed memberwise initializer).

Very simple example but thanks so much for the work that went into this update!

[ocapmycap]

So sorry, I thought I'd attached my gist. https://gist.github.com/ocapmycap/b96f04343dc98effae98d15a4e7376ca

I've marked on line 190 where the binding would not work. I just changed the code back and the error message is Cannot assign through dynamic lookup property: subscript is get-only. This was targeting macOS 14 and iOS 17, both with and without PerceptibleState wrappers.

The Sourcery issue is related to Sourcery Pro, the commercial product for the framework, which has an Xcode plugin. I just tried it and it didn't work producing a memberwise initializer for an @ObservableState struct. I realized I was not highlighting the @ObservableState property wrapper, though -- when I do, the initializer works as expected. Likely my unfamiliarity with using property wrappers.

[mbrandonw]

Hi @ocapmycap, the code in that gist compiles just fine for me. Are you sure you are running it against the freshest commit to the observation-beta branch?

[ocapmycap]

Hi @mbrandonw I just targeted the latest commit with a different project and got the same warning.

Any other info I could provide to be helpful?

[stephencelis]

@ocapmycap $store.title requires the action type to conform to BindableAction to work, as well as using BindingReducer in the reducer's body (without an action, implicit or explicit, the store has no idea how to feed updates back into the system).

[ocapmycap]

Thank you! 🤦 I misread the binding changes and didn't realize those had to stick around.

[cdowney102]

@mbrandonw @stephencelis I just finished migrating my app fully. It's still in development and targeting iOS 17. I did get to use/ update just about every component mentioned in the migration guide.

1. Does your project still compile?
Yes, it did.

2. Does your test suite still pass and does your app still work the same as it did before?
Yes, it seems to work the same as before both before any changes (on the beta branch) and once the migration was complete. I don't have full test coverage, but what unit tests I do have (roughly 50% of features) did pass.

3. Can you update some of your features to use @ObservableState and let us know if it works for you? Does your app still behave the same?
I've finished migrating all features. It seems to work well and behave the same. App metrics looks good.

4. Can you update some of your uses of IfLetStore, ForEachStore, SwitchStore, etc. to instead use simpler constructs, as detailed in the migration guide. Does everything still behave the same?
I've done all of these and they work the same 👍

5. Can you update some of your uses of sheet(store:) with sheet(item:), popover(store:) with popover(item:), etc., as detailed in the migration guide.
I've done all of these and they work the same 👍

I did notice one thing in the console after migrating that doesn't happen on my main branch without the migration. This output gets logged to the console when I switch tabs sometimes: Update NavigationAuthority bound path tried to update multiple times per frame.

Granted this is my own app, the migration was very trivial following the migration guide. The only things that slowed me down were the known issues of needing to have State and Enum be moved from extensions of Feature into the Feature struct. That part was kind of a bummer (I kept forgetting to do that) and led me to some weird compiler errors a few times that took me a minute to figure out. For example I would get seemingly unrelated and misleading errors in xcode such as The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions on the view. Sometimes the error would be Property '_$id' must be declared public because it matches a requirement in public protocol 'ObservableState'. In both cases, it either came down to forgetting to annotate State as @ObservableState or forgetting to move it inside the Feature struct.

This was really fun and exciting and I am looking forward to the next video. Thanks for all of your hard work. One question: The @Reducer macro automatically marks our Action enums as @CasePathable. Any plans to have it also take care of @ObservableState as well to avoid situations I described above?

[mbrandonw]

Hi @cdowney102, thanks for giving it a spin and giving us a detailed report!

I did notice one thing in the console after migrating that doesn't happen on my main branch without the migration. This output gets logged to the console when I switch tabs sometimes: Update NavigationAuthority bound path tried to update multiple times per frame.

That's strange. If you are able to ever create a minimal reproducing example of this we would love to look into it more.

The only things that slowed me down were the known issues of needing to have State and Enum be moved from extensions of Feature into the Feature struct.

This is a huge problem that we have gotten dozens of reports about, and Apple has yet to acknowledge it. We highly recommend chiming in on this issue to let it be known it is affecting a lot of people.

Any plans to have it also take care of @ObservableState as well to avoid situations I described above?

That is the plan, but for 2.0 since it is technically a breaking change. Naively applying @ObservableState to all States while WithViewStores are still around can lead to a lot of churn in view renders and create strange behavior.

[Jimmy-Prime]

I am experiencing Property wrapper cannot be applied to a computed property error when I have a property wrapper in State

@propertyWrapper
struct EquatableFormItem<T: Equatable>: Equatable {
    let original: T
    var wrappedValue: T

    init(item: T) {
        original = item
        wrappedValue = item
    }

    var projectedValue: EquatableFormItem<T> {
        self
    }

    var changed: Bool {
        original != wrappedValue
    }
}

@Reducer
struct FormFeature<T: Equatable> {
    @ObservableState
    struct State: Equatable {
        @EquatableFormItem var item: T // <-- error in this line
    }

    enum Action { ... }

    var body: some ReducerOf<Self> { ... }
}

[mbrandonw]

Hi @Jimmy-Prime, this is unfortunately just a limitation of Swift macros in general. It affects vanilla SwiftUI too:

@Observable
class Model {
  @EquatableFormItem var item: Int  // 🛑
}

Macros and property wrappers just do not play well together. And because it's a Swift problem, and not a TCA problem, we're not sure how we want to handle this right now. Currently I think our easiest advice is to just shy away from using property wrappers in state.

You can also use @ObservationStateIgnored to fix the problem, but then changes to that value will not re-render the view. You would need to integrate EquatableFormItem with the observation tools like we did for PresentationState, but that also seems really strange. We're not sure if that is the correct recommendation, or if we should provide tools that make it easier to do that.

[Jimmy-Prime]

Oh, I see. I'll move away from property wrapper inside State then

[larryonoff]

Looks that most issues will be connected with iOS <17.

[stephencelis]

@larryonoff Did you mean to thread this comment elsewhere? Having a hard time understanding it 😄

[larryonoff]

@mbrandonw @stephencelis

This's just an assumption since WithPerceptionTracking have to be properly used instead of WithViewStore and for lazy views for all iOSes <17

[stephencelis]

@larryonoff I think something in your comment may be missing, but "most issues will be connected with iOS <17" doesn't make a whole lot of sense to me. I think you need to specify what kinds of issues you mean. Are you suggesting that there are library bugs in the beta that are iOS <17 only? Are you suggesting something else?

For what it's worth, our observation backport is mostly direct source from Apple, so there shouldn't be a ton of difference, and we haven't experienced any bugs with WithPerceptionTracking yet (and if you omit it, the library should emit runtime warnings to help you fix the problem).

[larryonoff]

@stephencelis I mean that a lot of issues with 1.6.0 on iOS <17 can be connected with human factor, i.e. when someone forget to use WithPerceptionTracking as result SwiftUI doesn't observe state changes. I already faced with it, but thanks for the document.

This's just feeling after some short experience playing with observation-beta.

As a suggestion, it would be great have some compiler warnings (that WithPerceptionTracking should be used), but I'm not sure that this's possible.

I also don't like that it could be nested WithPerceptionTracking, e.g.

WithPerceptionTracking {
  ForEach(store.scope(state: \.rows, action: \.rows) { store in
    WithPerceptionTracking {
      Text(store.title)
    }
  }
}

and looks that it may be better having withPerceptionTracking view modifier, that won't increase nesting level in view, e.g.

ForEach(store.scope(state: \.rows, action: \.rows) { store in
  Text(store.title)
    .withPerceptionTracking()
}
.withPerceptionTracking()

[stephencelis]

I mean that a lot of issues with 1.6.0 on iOS <17 can be connected with human factor, i.e. when someone forget to use WithPerceptionTracking as result SwiftUI doesn't observe state changes. I already faced with it, but thanks for the document.

This's just feeling after some short experience playing with observation-beta.

As a suggestion, it would be great have some compiler warnings (that WithPerceptionTracking > should be used), but I'm not sure that this's possible.

This is a trade-off of the backport, and would apply to a vanilla SwiftUI application as well.

We're open to suggestions on how to improve the situation, but we think that even the current beta's need to add the occasional WithPerceptionTracking when you hit a runtime warning is way better than asking folks to learn about view stores and WithViewStore, view state structs and observe: and removeDuplicates, IfLetStores, ForEachStores, SwitchStores, CaseLets, sheet(store:)s and a bunch of other presentation modifiers, binding view stores and binding view state, etc. etc. etc. We're eliminating a ton of concepts here and allowing folks to target as far back as iOS 13 in exchange for a single new view requirement.

and looks that it may be better having withPerceptionTracking view modifier, that won't increase nesting level in view, e.g.

In this example that may be true, but as soon as you are in a view builder of multiple statements, you'll need to wrap the entire thing to apply a view modifier, which means reaching for Group or VStack, which introduces nesting and an extra line for the modifier, would be slightly different, and could lead to subtle refactoring issues. We think the view wrapper is probably the simpler concept as a result.

[pschneider]

Hey @mbrandonw,

I still had the code of your composable architecture tutorial on my machine and I thought of just trying to convert it based on your migration guide. All of this went very smoothly and, like others, I really like the changes you're implementing here! 🙏

However, one issue showed up in regards to the AddContactsFeature. I'm sure I'm missing something here, but just wanted to ask what you think is the best solution to solve this.

Below is the code from the tutorial converted according to your migration guide:

struct Contact: Equatable, Identifiable {
    let id: UUID
    var name: String
}

import Foundation
import ComposableArchitecture

@Reducer
struct AddContactFeature {

    @ObservableState
    struct State: Equatable {
        var contact: Contact
    }

    enum Action: Equatable {
        case cancelButtonTapped
        case delegate(Delegate)
        case saveButtonTapped
        case setName(String)
        enum Delegate: Equatable {
            case saveContact(Contact)
        }
    }

    @Dependency(\.dismiss) var dismiss

    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .cancelButtonTapped:
                return .run { _ in await self.dismiss() }

            case .delegate:
                return .none

            case .saveButtonTapped:
                return .run { [contact = state.contact] send in
                    await send(.delegate(.saveContact(contact)))
                    await self.dismiss()
                }

            case let .setName(name):
                state.contact.name = name
                return .none
            }
        }
    }
}

struct AddContactView: View {
    @State var store: StoreOf<AddContactFeature>

    var body: some View {
        Form {
            TextField("Name", text: $store.contact.name.sending(\.setName))
            Button("Save") {
                store.send(.saveButtonTapped)
            }
        }
        .toolbar {
            ToolbarItem {
                Button("Cancel") {
                    store.send(.cancelButtonTapped)
                }
            }
        }
    }
}

This code fails to compile due to Return from initializer without initializing all stored properties on the AddContactFeature.State. This happens as soon as the @ObservableState macro is applied.

Would you just set an empty contact here as a default inside the AddContactFeature instead of passing this via the ContactsFeature.addButtonTapped action?

//...
  case .addButtonTapped:
      state.destination = .addContact(
          AddContactFeature.State(
              contact: Contact(id: self.uuid(), name: "")
          )
      )
      return .none
//...

[majelbstoat]

I have a similar thing, with:

@Reducer
struct QuestionDetailFeature {
    @ObservableState
    struct State {
        var question: Question
    }
    
    \\ ...
}

The error goes when @ObservableState is removed, but then I can't use self.state.question in the View.

[stephencelis]

@pschneider This appears to be a bug in Swift, where you sometimes need to manually implement the initializer:

 @ObservableState
 struct State: Equatable {
   var contact: Contact
+
+  init(contact: Contact) {
+    self.contact = contact
+  }
 }

Xcode will generally do the work for you, though!

[pschneider]

@mbrandonw Ouch, haven't seen this one for a while 🙈 That works like a charm, thank you!

If more people are facing this in the process of migrating, it might also make sense to add a small note to the migration guide that this is not an issue with adopting the macro itself.

[majelbstoat]

Following the migration guide, I'm having trouble making NavigationStack work.

Original Code:

struct AppFeature: Reducer {
    struct State {
        var path = StackState<Path.State>()
        var questionList = QuestionListFeature.State()
    }

    enum Action {
        case path(StackAction<Path.State, Path.Action>)
        case questionList(QuestionListFeature.Action)
    }

    struct Path: Reducer {
        enum State {
            case detail(QuestionDetailFeature.State)
        }

        enum Action {
            case detail(QuestionDetailFeature.Action)
        }

        var body: some ReducerOf<Self> {
            Scope(state: /State.detail, action: /Action.detail) {
                QuestionDetailFeature()
            }
        }
    }

    var body: some ReducerOf<Self> {
        Scope(state: \.questionList, action: /Action.questionList) {
            QuestionListFeature()
        }

        Reduce { state, action in
            switch action {
            case .path:
                return .none
            case .questionList:
                return .none
            }
        }
        .forEach(\.path, action: /Action.path) {
            Path()._printChanges()
        }
    }
}

struct AppView: View {
    let store: StoreOf<AppFeature>
    var body: some View {
        NavigationStackStore(
            self.store.scope(state: \.path, action: { .path($0) })
        ) {
            QuestionListView(
                store: self.store.scope(state: \.questionList, action: { .questionList($0) })
            )
        } destination: { state in
            switch state {
            case .detail:
                CaseLet(/AppFeature.Path.State.detail, action: AppFeature.Path.Action.detail, then: QuestionDetailView.init)
            }
        }
    }
}

This compiles and works as expected. Following the guide, I ended up with:

@Reducer
struct AppFeature {
    @ObservableState
    struct State {
        var path = StackState<Path.State>()
        var questionList = QuestionListFeature.State()
    }

    enum Action {
        case path(StackAction<Path.State, Path.Action>)
        case questionList(QuestionListFeature.Action)
    }

    struct Path: Reducer {
        enum State {
            case detail(QuestionDetailFeature.State)
        }

        enum Action {
            case detail(QuestionDetailFeature.Action)
        }

        var body: some ReducerOf<Self> {
            Scope(state: /State.detail, action: /Action.detail) {
                QuestionDetailFeature()
            }
        }
    }

    var body: some ReducerOf<Self> {
        Scope(state: \.questionList, action: /Action.questionList) {
            QuestionListFeature()
        }

        Reduce { state, action in
            switch action {
            case .path:
                return .none
            case .questionList:
                return .none
            }
        }
        .forEach(\.path, action: /Action.path) {
            Path()._printChanges()
        }
    }
}

struct AppView: View {
    @State var store: StoreOf<AppFeature>
    var body: some View {
        NavigationStack(path: $store.scope(state: \.path, action: \.path)) { // error is here
            QuestionListView(
                store: store.scope(state: \.questionList, action: \.questionList)
            )
        } destination: { store in
            switch store.state {
            case .detail:
                if let store = store.scope(state: \.detail, action: \.detail) {
                    QuestionDetailView(store: store)
                }
            }
        }
    }
}

This does not compile, with 4 errors, all on the NavigationStack line:

Cannot convert value of type 'Binding<Store<StackState<AppFeature.Path.State>, ChildAction>?>' to expected argument type 'Binding<Store<StackState<State>, StackAction<State, Action>>>'
Generic parameter 'Action' could not be inferred
Generic parameter 'ChildAction' could not be inferred
Key path value type 'StackState<AppFeature.Path.State>' cannot be converted to contextual type 'StackState<AppFeature.Path.State>?'

[majelbstoat]

Of course, I found the issue 1 minute after posting. I also needed to make Path a @Reducer and its state @ObservableState.

Maybe a good idea to be explicit about that in the migration guide?

[mbrandonw]

Hi @majelbstoat, that is a good idea. We will update the migration guide soon.

[danikkm]

@majelbstoat, did you manage to solve this problem? I am facing the same error. Both Feature State and Path are annotated with @ObservableState.

[majelbstoat]

Path had to be annotated with @Reducer and its State had to be annotated with @ObservableState. Then everything worked for me.

[jondlew]

With ViewStore being an ObservableObject it could be used as an EnvironmentObject in child views needing access to the store.

With the new tools, is the only option manually passing the store to child views?

[jondlew]

Using this to access the store from Environment:

@Environment(StoreOf<Feature>.self) private var store

Generates this error: 'init(_:)' is only available in iOS 17.0 or newer

Ideas? Thanks!

[jondlew]

It looks like using an Observable in Environment is iOS 17 only. So for now manually passing the store to child views appears to be the only option (unless you know of a workaround).

Thanks!

[mbrandonw]

Ah yeah, it is iOS 17+. You can also create a wrapper that turns any type into an ObservableObject for the purpose of putting it into the environment:

class ObservableWrapper<Object>: ObservableObject {
  let object: Object
}

Then you could do:

.environmentObject(ObservableWrapper(object: store))

That's not really a legitimate thing to do pre-Observable because changes in the object are not actually observed. But if your feature is integrated with @ObservableState then it should be OK to do.

[jondlew]

Okay, I'll give it a try – thanks!

[jondlew]

In case anyone else needs this, here's what worked for me:

Add the Wrapper class:

public class ObservableStoreWrapper<Object>: ObservableObject {
    public var store: Object
    
    public init(store: Object) {
        self.store = store
    }
}

Add the store as an EnvironmentObject in top level view:

struct ParentView: View {
    @State var store: StoreOf<Feature>
    
    var body: some View {
        WithPerceptionTracking {
            
            ChildView()
       
        }.environmentObject(ObservableStoreWrapper(store: store))
    }
}

In a child view needing access:

struct ChildView: View {
    @EnvironmentObject var wrapper: ObservableStoreWrapper<StoreOf<Feature>>
    
    var body: some View {
        
        VStack {
            
            // Access a State value
            Text(wrapper.store.someValue)
            
            //Send an action
            Button("Action Button") {
                wrapper.store.send(.someAction)
            }
            
            //Use a binding
            TextField("Text", text: $wrapper.store.someText)
        }
    }
}

[tonyarnold]

I'm really excited about this release - thanks for sharing the beta preview!

I've been attempting to use the Perception framework sans ComposableArchitecture on some existing projects, but I can't seem to get it to react to any changes, ie:

import Perception

@Perceptible
class MyClass {
  var otherObject: SomeOtherObject?

  init(otherObject: SomeOtherObject?) {
    self.otherObject = otherObject
    self.observeChanges()
  }

  func observeChanges() {
    _ = withPerceptionTracking {
      _ = self.otherObject
    } onChange: {
      DispatchQueue.main.async {
         print("Hi!")
         self.observeChanges()
      }
    }
  }
}

Am I doing something obviously wrong?

[stephencelis]

@tonyarnold I think we'd need more info to diagnose, but please note that this framework isn't currently supported outside of the TCA beta in SwiftUI. Also worth noting that even Apple's official Observation framework isn't really supported well outside of SwiftUI. The public withObservationTracking is a blunt tool lacking support for cancellation and even the ability to reasonably respond to didSet. Our backport doesn't attempt to alleviate that situation.

[tonyarnold]

Thanks for the explanation, @stephencelis!

I've checked, and my issues are visible when using the Observation framework directly, too, so this doesn't seem to be an issue with Perception.

[jondlew]

Testing with a stripped down Feature/View on iOS 16 triggers this log message repeatedly:

Perceptible state was accessed but is not being tracked. Track changes to state by wrapping your view in a 'WithPerceptionTracking' view.

I noticed this first in my app that was working great with iOS 17. Testing against iOS 16 triggered an endless stream of the message in the log and brought the app to a crawl. The app actually continued to work (albeit with super slow response).

So I tested the following in a new test app and was able to trigger the log messages:

@Reducer
public struct TestFeature {
    public init() {}
    
    @ObservableState
    public struct State: Equatable {
        var testValue = "Change Me"
        public init() {}
    }
    
    public enum Action: BindableAction {
        case binding(BindingAction<State>)
    }
    
    public var body: some ReducerOf<Self> {
        BindingReducer()
        Reduce { state, action in
            switch action {
            case .binding:
                return .none
                
            }
        }
    }
}

struct TestView: View {
    @State var store: StoreOf<TestFeature>
    var body: some View {
        WithPerceptionTracking {
            VStack {
                TextField("Binding Test", text: $store.testValue)
            }
        }
    }
}

If I remove the binding, and just display the "testValue", the log message goes away. So it appears that using a binding will trigger the log message regardless of using WithPerceptionTracking.

This is using XCode 15.1 beta 3

[mbrandonw]

Hi @jondlew, thanks for the report. I believe I have a fix in this PR #2609. Can you point to that branch directly and verify it fixes things for you?

[jondlew]

This fixes my simple test app, @mbrandonw. Still seeing the issue in my actual app, so I must be missing some WithPerceptionTracking usage. I'll keep working on it and let you know if I can't resolve it there as well. Thanks!

[mbrandonw]

@jondlew if you expand the purple warning in Xcode it should give you a stack trace that hopefully tells you where the problem is.

[jondlew]

I'm not seeing any purple warnings in Xcode.

I can remove WithPerceptionTracking from my test app's view running iOS 16 and the binding will still work, but no purple warning is shown.

[stephencelis]

The purple warnings can be finicky. I see them sometimes but other times they disappear. Restarting Xcode or my computer also seems to help sometimes.

[jondlew]

I've updated to the latest commits on observation-beta which fixed the WithPerceptionTracking log messages on iOS 16.

However, the app is very slow on iOS 16 – each time a list view is rendered the CPU pegs at 100% for several seconds and the app is unresponsive to taps and scrolling (this is on Simulator -- I don't have an iOS 16 device to test currently).

After the CPU returns to 0%, the app will respond to taps again. Navigating to a detail, then back to the list using a NavigationStack results in the CPU pegging again.

iOS 17 performs great, so I'm guessing WithPerceptionTracking is doing some pretty heavy work.

Is this something you've seen before? Thanks!

[jondlew]

The latest updates to this branch have added a new WithPerceptionTracking warning triggered when navigating to a child with a NavigationStack.

The warning is shown on the Button action that sent to the store to trigger navigation, but only after the button is pressed.

 struct TestView: View {
    @State var store: StoreOf<TestFeature>
    var body: some View {
        WithPerceptionTracking {
            NavigationStack(path: $store.scope(state: \.path, action: \.path)) {
                List {
                    ForEach(store.items) { item in
                        Button(item.id.uuidString) {
                            store.send(.listItemTapped(item.id)) // <--- PerceptionTracking Warning Here
                        }
                    }
                }
            } destination: { store in
                switch store.state {
                case .childFeature:
                    if let childFeatureStore = store.scope(state: \.childFeature, action: \.childFeature) {
                        ChildView(store: childFeatureStore)
                    }
                }
            }
        }
    }
}

Also, I still haven't tracked down the cause of the CPU spikes on my real app. All my troubleshooting points to loading complex-ish data into state. I have a publisher sending data via a task to the reducer each time the view is shown. The spike is there whether I actually render anything to the view or not.

This same code on iOS 17 causes no perceptible CPU usage, while on iOS 16 it's 100% for several seconds.

[mbrandonw]

@jondlew this should help: #2614

[jondlew]

Yes, that fixes it – thanks!

[scogeo]

@mbrandonw I did some more digging on the performance issue on DEBUG builds when using WithPerceptionTracking and it seems the main culprit is in inSwiftUIBody defined in PerceptionRegistrar. I did a real quick and dirty memoization implementation as follows and performance became acceptable:

  fileprivate var memoizedResults: [AnyHashable: Bool] = [:]

  var isInSwiftUIBody: Bool {
     // Check cache
      let addresses = Thread.callStackReturnAddresses
      if let memoizedResult = memoizedResults[addresses] {
          return memoizedResult
      }

      for callStackSymbol in Thread.callStackSymbols {
      guard
        let symbol = callStackSymbol.split(separator: " ").dropFirst(3).first,
        symbol.utf8.first == .init(ascii: "$"),
        let demangled = String(symbol).demangled,
        demangled.hasPrefix("protocol witness for SwiftUI.View.body.getter : ")
      else { continue }
      // update cache
      memoizedResults[addresses] = true
      return true
    }
    // update cache
    memoizedResults[addresses] = false
    return false
  }

This was just a quick hack to take a stab at the problem and doesn't take into account threading, etc. but there is clearly some room for improvement here. But with this quick hack I was able to at least fully exercise my app in the simulator when it was previously nearly unusable due to the lag.

[mbrandonw]

Hi @scogeo, this looks like a great idea to us. Would you want to PR this against the observation-beta branch? If not, we can take care of it soon.

[timcolson]

I was introduced to TCA a few weeks ago. I've read about the core concepts, so I am excited to dive in!
Given this Observation announce/beta, seems worth waiting a bit for an updated tutorial. (Fewer things to learn and unlearn.)

Unless there is a beta branch of TCA tutorial?

[oliverfoggin]

Hey @timcolson

The main learning curve around TCA is not so much the integration with SwiftUI but more around the structuring of an app and its data and composing child features out of parent features and using Dependencies and so on.

None of that will change much (if at all) with the new ObservationBeta updates. The changes with this update will primarily mean that you just have less work to do to get SwiftUI views working. i.e. everything becomes more vanilla SwiftUI with TCA working as the "back end?" (middle end? 😅) of your app.

[mbrandonw]

Hi @timcolson, I agree with what @oliverfoggin said. By far the most complete tutorial of what TCA is today is our 1.0 tour, and the lessons learned there immediately transfer to when the observation tools are officially released. All that will change with the observation tools is that you will be able to delete a bunch of code.

But also the "Meet the Composable Architecture" tutorial has already been updated, and lives here. You will just have to build the documentation locally to view it in its rendered format.

[Jimmy-Prime]

Hi, I find view is not updating when trying to migrate features that have this shape.
An ItemFeature that operates on Item and an DetailFeature that operates on Item.Detail

DetailFeature works fine standalone, but when it's embedded in ItemFeature, view is not updating. If I roll both features back before observation, everything works fine

I am on revision 67e9c64f5e62db4d66b359eeb66e0f3d6c564b89

import ComposableArchitecture
import SwiftUI

// a vanilla SwiftUI view that uses binding of optional

struct OptionalFieldView: View {
    @Binding var field: Int?

    var body: some View {
        Button {
            if field == nil {
                field = 0
            } else {
                field = nil
            }
        } label: {
            Image(systemName: field == nil ? "circle" : "checkmark.circle.fill")
        }
    }
}

// models

struct ItemDetail: Equatable {
    var field: Int?
}

struct Item: Equatable {
    // some additional properties
    // ...

    // properties
    var detail: ItemDetail
}

// a feature that operates on Item.Detail

@Reducer
struct DetailFeature {
    @ObservableState
    struct State: Equatable {
        var detail: ItemDetail
    }

    enum Action: BindableAction {
        case binding(BindingAction<State>)
    }

    var body: some ReducerOf<Self> {
        BindingReducer()
    }
}

struct DetailView: View {
    @State var store: StoreOf<DetailFeature>

    var body: some View {
        OptionalFieldView(field: $store.detail.field)
    }
}

// a feature that operates on Item, and integrates DetailFeature

@Reducer
struct ItemFeature {
    @ObservableState
    struct State: Equatable {
        var item: Item

        var toggle: DetailFeature.State {
            get {
                .init(detail: item.detail)
            }
            set {
                item.detail = newValue.detail
            }
        }
    }

    enum Action {
        case toggle(DetailFeature.Action)
    }

    var body: some ReducerOf<Self> {
        Scope(state: \.toggle, action: \.toggle) {
            DetailFeature()
        }
    }
}

struct ItemView: View {
    @State var store: StoreOf<ItemFeature>

    var body: some View {
        DetailView(store: store.scope(state: \.toggle, action: \.toggle))
    }
}

#Preview {
    ItemView(store: StoreOf<ItemFeature>(initialState: ItemFeature.State(item: Item(detail: ItemDetail(field: nil)))) {
        ItemFeature()
    })

//    DetailView(store: StoreOf<DetailFeature>(initialState: DetailFeature.State(detail: ItemDetail(field: nil))) {
//        DetailFeature()
//    })
}

[mbrandonw]

Hi @Jimmy-Prime, can you create a new discussion for this question? This discussion has gotten too long for us to reasonable keep track of and so we will be closing it soon.

[mbrandonw]

Hello everyone, this discussion has gotten far too big for us to reasonably keep track of, so we are locking it for now. Please create a new discussion if you have questions or comments about the beta.

[scogeo]

I'm sharing some of my findings on the performance of the perceptionCheck() code when using WithPerceptionTracking on iOS 16 in the simulator. The sample app I used for these investigations was a a fork of SyncUps that includes WithPercpetionTracking and iOS 16 support.

I did my own quick and dirty instrumentation using a DEBUG build (and without _printChanges()) to see how many calls of perceptionCheck() were being made and how much time they were taking. The use case is to launch the app, press the Add button to create a new SyncUp. After the sheet appears and has focus, I measure how many calls and time in perceptionCheck() after typing a single character in the focused Title field. I did this both with and without a WithPerceptionTracking wrapper in the SyncUpForm body.

The table below shows the two use cases and how many times perceptionCheck() was called and some of the conditions under which it was called. I manually analyzed the call stack frames in the debugger to classify calls of .isInSwiftUIBody as to whether they were coming from a reducer or not. (Test machine is an M2 Pro)

Test Case	.isInPerceptionTracking true	.isInSwiftUIBody called from Reducer call stack	.isInSwiftUIBody called from non-Reducer call stack	Total calls to perceptionCheck()	Total Time spent in perceptionCheck() (secs)
No use of WithPerceptionTracking inbody	0	34	10	44	0.73
WithPerceptionTracking used in body	7	34	18	59	0.75

From this simple use case, there is a lot of computation going on to perform the perception check. This results in a severe degradation in performance and explains why typing in a text field in the simulator is painfully slow with 0.75 seconds of computation per keystroke.

The good news is the main culprit seems to be the unnecessary perception checks inside of reducers. Reducer call stack frames are particularly large and also have very complicated mangled names. So not only are they responsible for over 75% of the calls to perceptionCheck() in this use case, they probably also are the most computationally expensive of those calls. The non-reducer calls had fewer stack frames and far simpler symbol names to demangle.

Although this use case was a simple interactive UI use case, any heavy use of read access on observed state inside a reducer is going to incur a large penalty when running the perception back port in DEBUG mode due to the perception check.

Since we don't care about read access of observed state in a reducer for the purpose of the perception check, it seems that there is some low hanging fruit to detect if perceptionCheck() is being called from inside a reducer call stack through perhaps a TaskLocal variable and then skip the complex isInSwiftUIBody code for those calls.

Thoughts?

[mbrandonw]

Hey @scogeo, thanks for this detailed writeup, but would you mind starting a new discussion? I'm going to lock this one because it's gotten way too long and we can't keep track of everything inside.