Hacker News Reader

Comment by happytoexplain | Hacker News Reader

If you use SwiftUI at all, the app has to start with the SwiftUI lifecycle (Edit: May not be true, see replies). But then you can wrap any UIView or UIViewController in a SwiftUI wrapper (UIViewRepresentable and UIViewControllerRepresentable). So that view/controller will be presented by SwiftUI's navigation logic, but inside that view/controller, you can write a whole UIKit app if you want.

View on HN

Cool. Thank you for that. I've got through the SwiftUI tutorials and stuff, but I've never tried to make a real project that mixed both approaches, so I had no idea about UIViewRepresentable, etc.

I think that adds to my point that SwiftUI isn't something that's very amenable to "just use it where it's appropriate", or "gradually try it out by migrating a small part of your project", etc. It sounds like you have to commit to "this is a SwiftUI app now, and we can integrate with old stuff if/where/when we need to".

You can absolutely slowly migrate a UIKit project to begin using SwiftUI – it's part of what I've been doing at work for the past 8 months.

The way to cross the boundary from UIKit to SwiftUI or SwiftUI to UIKit (either direction) involves implementing one or maybe two classes/structs and is not too difficult to do.

Fair enough. I saw your reply to the grandfather comment and I asked some follow up questions there. Thank you. :)

Part of that is untrue. You can add SwiftUI to an app that starts with the UIKit lifecycle.

In fact, you can jump back and forth between UIKit and SwiftUI as many times as you like throughout your app's view hierarchy.

The current project I'm working on involves slowly porting an older UIKit+Storyboard app over to SwiftUI, so I'm seeing this in practice every day.

What's involved in the "jumping back and forth"? Is it pretty cumbersome or no? Do you use a UINavigationController at all in your app, or do your UIViewControllers do all of the navigating/presenting themselves?

We do use UINagivationController in our app, so that's no issue.

Crossing the boundary from UIKit to SwiftUI involves instantiating the SwiftUIView, handing that over to a UIHostingController, then presenting that controller. Something like this:

  let myView = MySwiftUIView()
  let hostingVC = UIHostingController(rootView: myView)
  navigationController.present(hostingVC, animated: true)

Crossing the boundary from SwiftUI to UIKit is slightly more boilerplate to write, but it's not too bad. You have to implement either a UIViewControllerRepresentable or a UIViewRepresentable (depends on your needs). Those protocols only needs two functions defined: makeUIView/makeUIViewController and updateUIView/updateUIViewController. For the simplest views and view controllers, you can leave the update definitions empty.

Thanks, I didn't know that!

Reply on news.ycombinator.com