UIKitNavigation beta

[mbrandonw]

Hello everyone!

We have a very exciting beta to share today that brings powerful state management and navigation tools to UIKit. The tools are heavily inspired by SwiftUI, but made to feel at home in UIKit. See our blog post for more details, but the short of it can be summarized in 4 simple bullet points:

• You can now use @Observable models with UIKit in order to observe changes in the model and update the UI in the most minimal way possible:

  let model = Model()
  
  func viewDidLoad() {
    super.viewDidLoad()
    
    let countLabel = …
    let activityIndicator = …
    let factLabel = …
    
    observe { [weak self] in
      guard let self else { return }
      
      countLabel.text = "\(model.count)"
      activityIndicator.isHidden = !model.isLoadingFact
      factLabel.isHidden = model.fact == nil
      factLabel.text = model.fact
    }
  }

• You can use 2-way bindings to bind an observable model to various UIControls, such as UITextField:

  @UIBindable var model: FeatureModel
  …
  let nameTextField = UITextField(text: $model.name)

• You can perform state-driven navigation in UIKit using a syntax that is similar to SwiftUI:

  navigationDestination(item: $model.detail) { detail in
    DetailViewController(model: detail) 
  }

• And the whole thing back-ports all the way back to iOS 13 using our swift-perception library.

That’s the basics, but there’s still a lot more in this beta, and a lot more coming in the future. We recommend you check out the blog post for more information, as well as the case studies in the repo, and please start a discussion with any questions or feedback.

[davdroman]

A bit out of scope but are TCA stores compatible with the new observe { ... } mechanism?

[acosmicflamingo]

Yes, and it's making a reducer's state observable that gives the observe { ... } mechanism its super powers.

[mbrandonw]

A bit out of scope but are TCA stores compatible with the new observe { ... } mechanism?

The observe function already exists in TCA and can be used today. We are moving that tool to swift-navigation, but that should mostly be invisible to users of our libraries.

[maximkrouk]

I was recently thinking about the lack of PresentationStack in TCA, don't have this problem right now, but if some modules use modal presentation to present each other recursively you won't be able to extract them into different spm targets, however both uikit and swiftui do not support this API and this lib might be the right place to enable it 🤔

[paulofaria]

@mbrandonw @stephencelis Is there a way to use UIKitNavigation with TCA when using NavigationStackController and var path: StackState<Path.State>? I'm having a hard time deriving a UIBinding for NavigationStackController.init's path parameter.

When I do:

self.init(path: $store.path) {
  ...
}

I get this message:

Cannot assign through dynamic lookup property: subscript is get-only

I guess we need a way to transform the binding with a construct similar to what we need for SwiftUI's Binding using something like _StoreBindable_SwiftUI?

$store.path.sending(\.pathChanged)

What are your plans here? With SwiftUI we actually have a NavigationStack initializer that takes a scoped store of StackState and StackAction, I imagine you'd want to go with something like this for UIKit, eventually.

However, I'd love to know if there's any way I can use NavigationStackController with TCA and var path: StackState<Path.State> right now?

[paulofaria]

I think maybe instead of an initializer and a separate function, maybe it makes more sense to merge them into a single initializer? Like the SwiftUI counterpart?

[mbrandonw]

Hi @paulofaria, are you aware of this PR on TCA that brings support to these UIKit navigation tools?

[paulofaria]

No, I wasn't! I tried looking for branches, but somehow I missed this! Taking a look, thanks!

[paulofaria]

Looks like it has part of what I pasted above, but not the specific parts for NavigationStackController. Do you think it makes sense for me to send a PR with it or do you have other plans for the API?

[mbrandonw]

Ah yes, that is something we plan on adding. If you want to PR, then please do go for it. We definitely would want it to mimic what we have for NavigationStack, and so a single initializer that handles the root and destinations at the same time.

[mingyoung]

Thank you very much for your hard work! Is there a plan to support AppKit? If so, when can we expect this support to be available?

[mbrandonw]

Hi @mingyoung, we haven't had any time to look into AppKit specifically, but we definitely think it is possible. The biggest blocker is our unfamiliarity with AppKit in general. In UIKit it's very clear that there is the present method for sheets/popovers/covers/etc..., and pushViewController for stack-based navigation. But in AppKit we are not sure what that looks like.

If you can give us any tips or help us out in anyway, please let us know. And at the very least we hope that we are providing enough tools that would allow people to build support for AppKit on their own.

[BrentMifsud]

I wonder if these tools belong in swift-perception instead of UIKitNavigation (or maybe it should be called UIKitBindings instead of UIKitNavigation?)

Just a thought, as it seems a big chunk of this library is dedicated to getting observation working with UIKit

[mbrandonw]

Hi @BrentMifsud, we want to keep Perception focused on just being a back port of the Observation framework because its lifetime is limited. Once people can target iOS 17+ there is no reason to depend on it anymore.

And the core observe and UIBinding tools are actually in a library called SwiftNavigation because they can even be used on non-Apple platforms.