Navigation

[mbrandonw]

As everyone knows, SwiftUI 4 comes with some new navigation APIs that seem to solve some bugs (such as drilling down multiple levels), but it's also structured in a way that doesn't play nicely with modeling navigation as a tree of state. We're still exploring ideas, but there was some really good discussion in a closed PR on swiftui-navigation that I want to highlight.

If anyone else has done explorations please feel free to add any of your findings in this discussion!

[jtouzy]

Thanks @mbrandonw!
Like I said in the previous thread on swiftui-navigation, I made some explorations with the new APIs and a TCA simple app.
I share this here for an easy follow :

import CasePaths
import ComposableArchitecture
import SwiftUI

// NOTE: Utility for quicker state scopes
@available(iOS 16.0, *)
extension Array where Element == Main.Route {
  func find<Value>(_ casePath: CasePath<Element, Value>) -> Value? {
    compactMap { element in
      guard let value = casePath.extract(from: element) else { return nil }
      return value
    }.first
  }
  mutating func update<Value>(_ casePath: CasePath<Element, Value>, with value: Value)
  where Value: Equatable {
    guard
      let routeIndex = firstIndex(where: { element in
        guard casePath.extract(from: element) != .none else { return false }
        return true
      })
    else {
      return
    }
    self[routeIndex] = casePath.embed(value)
  }
}

@available(iOS 16.0, *)
struct Main {
  enum Route: Hashable {
    case second(SecondPage.State)
    case third(ThirdPage.State)
  }
  struct State: Equatable {
    var navigation: [Route]

    var secondPage: SecondPage.State? {
      get { navigation.find(/Route.second) }
      set { newValue.map { navigation.update(/Route.second, with: $0) } }
    }
    var thirdPage: ThirdPage.State? {
      get { navigation.find(/Route.third) }
      set { newValue.map { navigation.update(/Route.third, with: $0) } }
    }
  }
  enum Action {
    case actionTapped
    case navigationPathChanged([Route])
    case secondPage(SecondPage.Action)
    case thirdPage(ThirdPage.Action)
  }
  static let localReducer: Reducer<State, Action, Void> = .init { state, action, _ in
    switch action {
    case .actionTapped:
      let route = Main.Route.second(.init(content: "Content"))
      state.navigation.append(route)
    case .navigationPathChanged(let navigation):
      state.navigation = navigation
    case .secondPage(let secondPageAction):
      switch secondPageAction {
      case .didNavigateOnThirdPage:
        let route = Main.Route.third(.init(content: "Content3"))
        state.navigation.append(route)
      }
    case .thirdPage:
      ()
    }
    return .none
  }
  static let reducer: Reducer<State, Action, Void> = .combine(
    SecondPage.reducer.optional().pullback(
      state: \.secondPage,
      action: /Action.secondPage,
      environment: { _ in }
    ),
    ThirdPage.reducer.optional().pullback(
      state: \.thirdPage,
      action: /Action.thirdPage,
      environment: { _ in }
    ),
    localReducer
  )
  struct View: SwiftUI.View {
    let store: Store<State, Action>

    var body: some SwiftUI.View {
      WithViewStore(store) { viewStore in
        NavigationStack(
          path: viewStore.binding(get: \.navigation, send: Action.navigationPathChanged)
        ) {
          Button(
            "Click me to navigate", action: { viewStore.send(.actionTapped) }
          )
          .navigationDestination(for: Route.self, destination: { route in
            switch route {
            case .second:
              IfLetStore(
                store.scope(
                  state: \.secondPage,
                  action: Action.secondPage
                )
              ) { store in
                SecondPage.View(store: store)
              }
            case .third:
              IfLetStore(
                store.scope(
                  state: \.thirdPage,
                  action: Action.thirdPage
                )
              ) { store in
                ThirdPage.View(store: store)
              }
            }
          })
          .navigationTitle("Navigation")
        }
      }
    }
  }
}

@available(iOS 16.0, *)
struct SecondPage {
  struct State: Equatable, Hashable {
    var content: String
  }
  enum Action {
    case didNavigateOnThirdPage
  }
  static let reducer: Reducer<State, Action, Void> = .empty
  struct View: SwiftUI.View {
    let store: Store<State, Action>

    var body: some SwiftUI.View {
      WithViewStore(store) { viewStore in
        Button("Second Page - Go tho third page") {
          viewStore.send(.didNavigateOnThirdPage)
        }
      }
    }
  }
}

@available(iOS 16.0, *)
struct ThirdPage {
  struct State: Equatable, Hashable {
    var content: String
  }
  enum Action {
    case buttonTapped
  }
  static let reducer: Reducer<State, Action, Void> = .init { state, action, _ in
    switch action {
    case .buttonTapped:
      state.content = "Tapped!"
    }
    return .none
  }
  struct View: SwiftUI.View {
    let store: Store<State, Action>

    var body: some SwiftUI.View {
      WithViewStore(store) { viewStore in
        Button("Third view \(viewStore.content)") {
          viewStore.send(.buttonTapped)
        }
      }
    }
  }
}

Navigation is fully driven by reducer and the subviews are totally Navigation-free. There's still some caveats.
Interested to contribute to any related implementation/researches for TCA!

[mbrandonw]

Thanks for sharing @jtouzy! One small thing I noticed while going over your code was I believe this condition is flipped:

guard casePath.extract(from: element) != .none else { return true }
return false

It should be this right?

guard casePath.extract(from: element) != .none else { return false }
return true

[jtouzy]

You're right, but interestingly it's seems to works.
That's because it's a so simple case, and I could not see anything working wrong.
I just added a random action the the ThirdPage, and then, the navigation is now malformed with this flipped condition.
Just updated the code with the new fixed version!

[mbrandonw]

I think the problem would only crop up if the second or third screen did some mutation. Like if there was a counter. Those mutations wouldn’t be replayed to the array of state.

[jtouzy]

Yep, that's why i've added a random buttonTapped action in the third screen, to trigger an action non related to navigation.

[tgrapperon]

Regarding the issue with programmatic navigation initiated by NavigationLink in a List, I have submitted a feedback about offering some kind of callback, and another one for a .navigationLink ButtonStyle, as using a Button seems to be the workaround proposed by SwiftUI engineers. I have very little hope that the NavigationLink will get callbacks, as they now navigate unconditionally when pressed, so I think the best we'll have is a built-in ButtonStyle.

If none of these feedbacks is addressed positively, and as a proof of concept, I've made the following NavigationButton that looks like a NavigationLink in a List, but runs an action. From my initial testing, it behaves and looks like a NavigationLink, whatever the interface style, dynamic font size, or layout orientation. Accessibility looks similar too. All of this can be checked more thoroughly, but at worse, we don't seem to be blocked by NavigationLinks' absence of binding (there are still subtleties around reusability outside of a List, since NavigationLink are decorated automatically, but it is maybe addressable too).

[mbrandonw]

I filed a very similar feedback @tgrapperon :)

[lukeredpath]

I think a navigation link button style is probably going to be the best outcome here. I’ve also experimented with recreating NavigationLink and while it’s possible to get close to it there’s some subtle behaviour that is tricky to recreate (which it, ironically, quite buggy and a bit broken in the beta) - specifically in a list, the link should be highlighted on tap and remain highlighted until you navigate back from the destination and the highlighting should animate away as part of the navigation animation transaction (so it participates in the interactive pop gesture).

[tgrapperon]

I agree that some built-in solution is desirable, but in any case, we can still manage to replicate the thing relatively convincingly. I've updated the gist and NavigationButton is now behaving better than NavigationLink!
I think they missed the option when they transitioned List to UICollectionView this year, and this will probably be fixed in a next beta.

[tgrapperon]

Thanks to @lukeredpath, I've rethought the approach, and I found a way to make NavigationButton style as a List row only when used inside a List. When used elsewhere, it presents as a regular button. I've updated the gist accordingly.
The hack consists in defining a .listRowBackground. When this view appears, we know we're in a List and we adapt accordingly. This is way more involved than the original solution, and we also need a little workaround to get animations for the row background, so a built-in solution is still the desired outcome, but in any case, a polyvalent NavigationButton is possible.
The current solution only fails when used in Section headers or footers because it activates the list row background, and then the button's theming.

[tgrapperon]

@lukeredpath I think I've found a way to achieve some "Load and Navigate" navigation style using NavigationStack: https://gist.github.com/tgrapperon/430f33023f82cf0d9580e67fd98e1bcc. I don't intend to maintain it, nor try to PR it, but it could maybe fit your needs. I've put a MIT license on it in any case.

[Sajjon]

Someone captured all questions and answers from Apple in WWDC Lounges here. There is a category for Navigation, maybe some answers from Apple can provide useful insight regarding the new navigation API.

[mbrandonw]

Thanks for sharing @Sajjon. Some interesting insights in there. It seems that Apple engineers don't think NavigationPath needs to expose the internals at all, but from my experiments it would be extremely handy if it did. We are drafting a collection of Feedbacks that hopefully cover some of the tools we need exposed in the new navigation APIs to make interfacing it with easier from TCA. We'll share once they are submitted.

[mbrandonw]

Hello everyone, we have some early explorations to share. It's pretty rough, but also promising. We think some of the tools will be made even nicer once we finish up the protocol reducer experimentation we have been working on. You can run the case studies app to see some simple usage.

The API is probably going to change quite a bit over the next few weeks/months, but it follows the style we've pushed for bindable state/actions as well as our nav experiments that some have found in our branches. Essentially there are reducer and view helpers that help you combine each feature's domain into the root domain.

We've also been filing Feedbacks of things we think would help make better TCA nav tools, and you can find those here.

[mbrandonw]

Just pushed another commit that added some tests to the case study. There's a lot of room for API ergonomics improvements, but it's still pretty nice to see how tests can be written across the entire navigation stack.

In particular, it shows how to push a screen C onto the stack, start its timer, pop it off the stack, and prove that the timer was automatically stopped.

[tgrapperon]

@mbrandonw The following vanilla SwiftUI view exhibits the issue with the path that is reset when the view appears:

struct ContentView: View {
  @State var path = NavigationPath([2])
  var body: some View {
    NavigationStack(path: $path) {
      Button("Navigate to 1") {
        path.append(1)
      }
      .navigationDestination(for: Int.self) {
        Text("State: \($0)")
      }
      .onAppear {
        print("OnAppear:", path, "isEmpty:", path.isEmpty)
      }
      .onChange(of: path) {
        print("OnChange:", $0, "isEmpty:", $0.isEmpty)
      }
    }
  }
}

When the view appears, the NavigationStack navigates to "2" but the state is empty from the very start at onAppear. I'm not sure what you did differently so maybe there's an explanation/workaround in the difference between your implementation and this one.

It seems to be purely SwiftUI related. This configuration can have its uses when working on a view deep in the hierarchy or in a preview, so I guess there's some motivation for them to fix it.

The issue happens on the simulator. I haven't checked on a real device or on macOS 13.

EDIT: Filed as FB10260852

[mbrandonw]

Oh good catch. I think I was looking at the wrong thing when I tested this in a vanilla app. I can easily reproduce this too. I will file a feedback too.

Edit: Deleted my other message, I was wrong. I was looking at the wrong logs.

[josephktcheung]

@mbrandonw thanks for the work on the nav-stack branch, I know it's too early to use it in production, but I'd like to ask how can we modularise the navigation so that the top level view that contains the NavigationStackStore need not pullback all the views an app can present.

Let's say our app is a football team management app, we have TeamFeature module and PlayerFeature module. A team can have a list of players.

AppFeature
  - AppView
TeamFeature
  - TeamsView
  - TeamView
  - TeamEditView
 PlayerFeature
  - PlayersView
  - PlayerView
  - PlayerEditView

All views can be present using NavigationStack e.g. AppView -> TeamsView -> TeamView -> PlayersView -> PlayerView -> PlayerEditView

With the current implementation (if I understand it correctly) I need to pullback all views from each module inside .navigationDestination reducer and also navigationDestination view helper. Is there a way to allow TeamFeature and PlayerFeature to manage its own navigation flow so that we only need to pullback 2 higher order views in AppView to make navigation work?

[mbrandonw]

Unfortunately this is not possible, and it's technically something that affects vanilla SwiftUI if you use the homogenous collection tools.

The problem is that when you use a typed mutable collection for your navigation state, you can only have one single .navigationDestination in your view. It must handle all destinations for the entire stack. Only NavigationPath is "blessed" with the ability to have multiple .navigationDestination's that cascade up the view hierarchy.

It's a huge bummer, and we've filed a feedback for it. If we had the ability to "skip" a .navigationDestination then it may be possible for us to accomplish what you are asking for.

If this feature is important to you, we encourage you to duplicate the feedback with Apple along with any additional detail for your use case.

We have also heavily investigated whether we can leverage NavigationPath to accomplish what we want in TCA, but sadly this does not seem possible either. The type is just too opaque. We get no ability to inspect what elements the path holds. We have also filed a feedback for that.

[tgrapperon]

Hey!
As the recent blog post from pointfree.co shows, it is possible to exploit NavigationPath codability to inspect what it contains.
However, an active and non-empty NavigationPath contains more dynamic metadata than what it started with when respawned from a codable representation, and it is unfortunately not possible to replace such a path with another value that was rebuilt from a codable representation we're controlling. The program complains that the path is not valid anymore and crashes.

All is not lost, however. It turns out that if we're able to read the last component of an active path, we have enough API surface to turn it into a mutable random access collection, or more simply said, an Array. From there, we regain complete control over the path, we can inspect it, observe it, and change it as we see fit.

For this to work, the NavigationPath must be serializable, i.e., with Codable components. Using the Codable representation, we can decode the last past component. For some fortunate reason, the codable representation presents components in reverse order, so we can stop decoding right after the first one! Once we have a way to obtain this value, we can combine sequences of removeLast() and append(), and opening existentials, to implement a few Collection requirements. These two methods are modifying the path in a "regular" way, as any SwiftUI developer would do, and the outcome is a valid NavigationPath.

Because we don't want to conform NavigationPath to Collection protocols ourselves, we introduce a wrapper of NavigationPath which is the type conforming to the protocol. This wrapper comes into two flavors: untyped and typed. The last one can only be used when the type of all components of a path is known and homogenous. You create any of these wrappers using either

path.inspectable // A `NavigationPath.Inspectable` collection
// or
path.inspectable(of: Int.self) // A `NavigationPath.Inspectable.Of<Int>` collection

Both are mutable, range-replaceable, random access collections. It means that most of Array's API's are automatically available, even some crazy ones like .shuffle().

Both are exposing a navigationPath property which is the inspected and controlled NavigationPath you can use in a NavigationStack as easily as

@State var path = NavigationPath().inspectable
var body: some View {
 NavigationStack(path: $path.navigationPath) {
  …
 }
}

From there, it works exactly like a NavigationPath, but you automatically get access to the extended APIs.

Some rough edges
There are currently three non-optimal issues with this approach, but none is a showstopper:

Components need to be Codable: As we have seen, our capacity to provide these APIs is tied to our ability to extract the last path component which is right now only possible with Codable components. the two other issues follow from this requirement:

• The current implementation is not super efficient, for the sake of correctness/simplicity. When we access the last path component, we serialize the entire NavigationPath before peeling off only the first component. This can probably be improved using some memoization.
• The codable representation is made to be serialized, and the type names used are the fully qualified type ones, which we would get using _typeName(x). This is unfortunately not enough to respawn the type from a string because the _typeByName function expects a more complex mangled name. I'm not aware of a way to retrieve a mangled type name from a fully qualified one. It is likely possible, but I don't know how to do it at runtime. To circumvent the issue, each time a value passes through the "inspectable" APIs, its type is registered: the type name and the mangled type names (both are available if you have the value or type) are stored in a dictionary and used when decoding the last path component. NavigationLink are however interacting with the path themselves, so we can't see the value passing through the API and register its type at the occasion. The workaround would be to define custom overloads of NavigationLink that would do this automatically. It means that if you build the path starting from an empty path and use these overloads or interact with the inspectable path, there will be no issue, but if you initialize a NavigationPath from a serialized version, it will not work if you don't register all the possible types manually. I understand why it is better to serialize the type name instead of the mangled one, but I don't know how they do in SwiftUI to rebuild types from there.

As we can see, all the issues are coming the codable trick. If we only had access to the last path component of a NavigationPath, we would be able to reimplement all of this in a very performant way. I've devised two use-cases for this feature (namely, rebuilding the "Back" button menu in a custom navigation bar, and accessory views in iPad sidebars) and I've submitted the feedback FB10624758 accordingly.

Concerning TCA navigation, how much this can be useful depends on the route that will be taken, but our control over NavigationPath seems to be as good as it'll need to be.

You can find a gist with all of this here. The whole content can be copy/pasted to replace the content of a ContentView.swift in a new SwiftUI app project.

[tgrapperon]

I think I get it! They probably rely on .navigationDestination<D: Hashable>(for destination: D) to spot the types they need, and they probably defer the decoding of each path component until they're able to do it as the View hierarchy unfolds. I can see this working. I wonder if we can do the same from our side.

[tgrapperon]

Thanks to @mayoff, it seems that this is the way they do it.
I can probably retro-fit boxes into this approach, but I'll make a standalone repo instead, as the gist muddies a little the progress.

[mfclarke-ts]

Edit: this turned out to be a bit of a dead end for decoupling or improving navigation generally. But it is still nice as a way to remove boilerplate from features that use NavigationLink to get from A to B.

I've been looking into decoupling strategies for our project as our team is increasing in size, and of course this ends up being very closely linked to navigation with SwiftUI. Definitely excited for what's being cooked up here! But we (and probably a lot of others) have a hard requirement to support n-2 iOS version. That means we're still a couple of years away from being able to use this for decoupling features :(

For us, I've been playing around with higher order TCA feature wrappers of the SwiftUI components like NavigationLink. This gives you a nice TCA friendly API that removes annoying boilerplate, and also unlocks decoupling if you need it. Should work fine for deep links as well (I mean, as well as any SwiftUI using NavigationLinks works for deep links...)

For example:

struct NavigationLinkState<
  LabelState: Equatable & Identifiable,
  DestinationState: Equatable & Identifiable
>: Equatable, Identifiable {
  var id: UUID = .init()
  var label: LabelState
  var destination: DestinationState?
  var isDestinationPresented: Bool = false
}

enum NavigationLinkAction<
  LabelAction: Equatable,
  DestinationAction: Equatable
>: Equatable {
  case setNewIsDestinationPresented(Bool)
  case label(LabelAction)
  case destination(DestinationAction)
}

struct NavigationLinkEnvironment<
  LabelEnvironment,
  DestinationEnvironment
> {
  let makeLabelEnvironment: () -> LabelEnvironment
  let makeDestinationEnvironment: () -> DestinationEnvironment
  
  var label: LabelEnvironment {
    makeLabelEnvironment()
  }
  var destination: DestinationEnvironment {
    makeDestinationEnvironment()
  }
}

func navigationLinkReducer<
  LabelState: Equatable & Identifiable,
  LabelAction: Equatable,
  LabelEnvironment,
  DestinationState: Equatable & Identifiable,
  DestinationAction: Equatable,
  DestinationEnvironment
>(
  labelReducer: Reducer<LabelState, LabelAction, LabelEnvironment>,
  destinationReducer: Reducer<DestinationState, DestinationAction, DestinationEnvironment>,
  makeDestinationState: @escaping (NavigationLinkState<LabelState, DestinationState>) -> DestinationState
) -> Reducer<
  NavigationLinkState<LabelState, DestinationState>,
  NavigationLinkAction<LabelAction, DestinationAction>,
  NavigationLinkEnvironment<LabelEnvironment, DestinationEnvironment>
> {
  .combine(
    .init { state, action, _ in
      switch action {
      case .setNewIsDestinationPresented(let isPresented):
        state.destination = isPresented ? makeDestinationState(state) : nil
        state.isDestinationPresented = isPresented
        return .none
      case .label, .destination:
        return .none
      }
    },
    labelReducer.pullback(
      state: \.label,
      action: /NavigationLinkAction.label,
      environment: \.label
    ),
    destinationReducer.optional().pullback(
      state: \.destination,
      action: /NavigationLinkAction.destination,
      environment: \.destination
    )
  )
}

struct NavigationLinkView<
  LabelState: Equatable & Identifiable,
  LabelAction: Equatable,
  LabelView: View,
  DestinationState: Equatable & Identifiable,
  DestinationAction: Equatable,
  DestinationView: View
>: View {
  typealias NavigationLinkStore = Store<
    NavigationLinkState<LabelState, DestinationState>,
    NavigationLinkAction<LabelAction, DestinationAction>
  >
  let store: NavigationLinkStore
  
  typealias LabelStore = Store<LabelState, LabelAction>
  let makeLabelView: (LabelStore) -> LabelView
  
  typealias DestinationStore = Store<DestinationState, DestinationAction>
  let makeDestinationView: (DestinationStore) -> DestinationView
  
  init(
    store: NavigationLinkStore,
    @ViewBuilder labelView makeLabelView: @escaping (LabelStore) -> LabelView,
    @ViewBuilder destinationView makeDestinationView: @escaping (DestinationStore) -> DestinationView
  ) {
    self.store = store
    self.makeLabelView = makeLabelView
    self.makeDestinationView = makeDestinationView
  }
  
  var body: some View {
    WithViewStore(store) { viewStore in
      NavigationLink(
        isActive: viewStore.binding(
          get: \.isDestinationPresented,
          send: NavigationLinkAction.setNewIsDestinationPresented
        ),
        destination: {
          IfLetStore(store.scope(state: \.destination, action: NavigationLinkAction.destination)) {
            makeDestinationView($0)
          }
        },
        label: {
          makeLabelView(store.scope(state: \.label, action: NavigationLinkAction.label))
        }
      )
    }
  }
}

And then you use it like:

struct AppState: Equatable {
  var person: NavigationLinkState<PersonRowState, PersonDetailsState>
}

enum AppAction: Equatable {
  case person(NavigationLinkAction<PersonRowAction, PersonDetailsAction>)
}

struct AppEnvironment {
  var person: NavigationLinkEnvironment<PersonRowEnvironment, PersonDetailsEnvironment> {
    .init(
      makeLabelEnvironment: { .init() },
      makeDestinationEnvironment: { .init() }
    )
  }
}

let appReducer: Reducer<AppState, AppAction, AppEnvironment> = .combine(
  .empty,
  navigationLinkReducer(
    labelReducer: personRowReducer,
    destinationReducer: personDetailsReducer,
    makeDestinationState: { appState in 
      // Opportunity to put some logic here to build the right destination state from parent state
      .init() 
    }
  ).pullback(
    state: \.person,
    action: /AppAction.person,
    environment: \.person
  )
)

struct AppView: View {
  let store: Store<AppState, AppAction>
  var body: some View {
    NavigationView {
      NavigationLinkView(
        store: store.scope(state: \.person, action: AppAction.person),
        labelView: { PersonRowView(store: $0) },
        destinationView: { PersonDetailsView(store: $0) }
      )
    }
  }
}

So now we can have a fully built, tested and merged PersonRowView, and in parallel a fully built, tested and merged PersonDetailsView, with some minor work required at the end to glue them together with NavigationLinkView in the parent feature (AppView here). I imagine a similar process could be done for modals, sheets etc. with the extra step of a convenience extension on View if we want to keep it super close to SwiftUI. We haven't hit that need yet, but if we do I don't think it would be a terribly difficult process.

Question for you all: what am I missing? This seems nice to me, but I've only been working with TCA for 8 months. I might be missing gotchas that will rear their ugly heads when it's too late... 😱

[mfclarke-ts]

So now we can have a fully built, tested and merged PersonRowView, and in parallel a fully built, tested and merged PersonDetailsView, with some minor work required at the end to glue them together with NavigationLinkView in the parent feature (AppView here).

You know what, I just realised you can achieve the same with plain old NavigationLink and friends. You'd just need to hand crank the state, actions etc. This code here just codifies the pattern and removes boilerplate.

[mfclarke-ts]

I've had a chance to shake this out a bit more from the decoupling perspectve, and it unfortunately explodes with generics as you specify deeper and deeper navigation trees. Even 2 deep is too unwieldy I think. I'm not super confident with existentials, but I might revisit at some stage once I have a deeper understanding.

So, in terms of improving navigation, this kind of thing is just a bit of a helper to remove boilerplate for now.

[johnpatrickmorgan]

@mfclarke-ts you might be interested in https://github.com/johnpatrickmorgan/TCACoordinators. It allows for decoupled views to be composed within complex navigation stacks. Based on https://github.com/johnpatrickmorgan/FlowStacks.

[mfclarke-ts]

Wow this looks great, thanks @johnpatrickmorgan!

[mfclarke-ts]

I played a bit more with my code above, with the idea of flattening the state and actions trees to the parent. It does work, you just need to add generics to the view for a generic destination. Can't simply use the NavigationLinkView. So I think I'll call this experiment a bit of a dead end as it doesn't seem worth the hassle. Especially given a much more comprehensive solution already out there like TCACoordinators :)

[torcelly]

Hello everyone. Over the past few weeks I have tried several approaches but none have worked. Whenever you share states between screens, it stops working: iOS 16 Navigation API feedbacks

Apple is shipping the last betas before the official release. I have two apps that use TCA but I can't launch them in the App Store because they are broken on iOS16. My main concern is that the architecture will remain broken until I find a solution to the new opaque navigation API in iOS16.

Any hope? I will keep trying :(

[stephencelis]

@torcelly Sorry to hear you're having issues!

Hello everyone. Over the past few weeks I have tried several approaches but none have worked. Whenever you share states between screens, it stops working on iOS16 / iPadOS16.

Can you explain what stops working? I think it might help us understand if you can explain what you've tried, what your requirements are (deep linking, where/why/how you need state-driven navigation, etc.), and where things went wrong specifically.

The sketches Brandon mentioned earlier in this thread were very promising in our uses, and we plan on polishing them up after we wrap up the protocol release, but it'd also be good to know if they solve whatever problems you are running into.

Apple is shipping the last betas before the official release. I have two apps that use TCA but I can't launch them in the App Store because they are broken on iOS16. My main concern is that the architecture will remain broken until I find a solution to the new opaque navigation pattern in iOS16.

Without more information I'm not sure we can understand if the issues you're hitting are TCA-specific or just general navigation problems in vanilla SwiftUI. Wanna take a lil time to flesh out an explanation?

[torcelly]

@stephencelis Sure! My apologies. I thought it was a general error but now I think that maybe I'm doing something wrong.

I have detected several issues with the new navigation API (stacks). However all of them are mentioned here by Brandon and in this discussion.

The second topic is something related with sheets + bindings. I am building the simplest example possible to share a quick explanation here. Give me a few hours and I'll post it here.

Offtopic: I have not had the opportunity to thank and congratulate you for the great work you both do. I love TCA. Thanks!

[torcelly]

@stephencelis I've created a topic in swift forum because I suspect that it isn't a general navigation issue just something I am doing wrong. I do not want to create noise in this navigation general discussion.