4 ms·
To be fair, though, I feel like the difference between SwiftUI and UIKit or XIB is much bigger than the difference between UIKit and XIB. I don't have much pra
by ragnese 4y ago
To be fair, though, I feel like the difference between SwiftUI and UIKit or XIB is much bigger than the difference between UIKit and XIB.
I don't have much practice with SwiftUI since I have to support some older iOS devices, but how awkward is it to do navigation between screens implementing with SwiftUI Views and those using UIViewController and friends? How does UINavigationController work into all of that?
- jshier 4y agoXIB? xib files are used in UIKit apps, alongside storyboards, but they're simply serialized views, not a different architecture or paradigm.
- ragnese 4y agoYeah, sorry. I wasn't being precise. When I say "UIKit" I mean what iOS devs usually refer to as "programmatic views" where you do all the UI stuff in Swift code files rather than the UI Builder and Storyboard tools that Xcode offers. I'm sure SwiftUI is UIKit underneath, too, for what it's worth.
- happytoexplain 4y agoIf 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.
- ragnese 4y agoCool. 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".
- Willamin 4y agoYou 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.
- ragnese 4y agoFair enough. I saw your reply to the grandfather comment and I asked some follow up questions there. Thank you. :)
- Willamin 4y agoPart 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.
- ragnese 4y agoWhat'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?
- Willamin 4y agoWe 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.
- happytoexplain 4y agoThanks, I didn't know that!