How to integrate UIKit and SwiftUI in the same application

Recorded January 24th 2021 – watch the full episode on YouTube.

What do you think is the best way to integrate UIKit and SwiftUI? Do you approach from SwiftUI and bring in UIKit as needed, or start with UIKit and bring SwiftUI?

Ish Shabazz: I try to do SwiftUI first. I started off doing SwiftUI for views and then UIKit for navigation, as well as anything that didn't really work well with SwiftUI. For example, at the time I gave a talk on SwiftUI, UICollectionView didn't exist yet. So I needed a collection view. Alright, so now I have just a wrapper, and I was making something on my own called SwiftUIKit. That's just my framework where I'm tossing in all the representable views of UIKit wrapped in SwiftUI.

Another beauty of SwiftUI is that even if you don't feel like SwiftUI is ready for production, it's a good idea to bring some SwiftUI into your project because you can still do that live rendering. You can just wrap your UIKit code in SwiftUI, which is what I mentioned in my talk, and then you can just view your UIKit in the canvas, which is neat.

Paul Hudson: So you get some of the benefits of SwiftUI while still using UIKit?

Ish Shabazz: Absolutely, yes. It's a completely different way of thinking. It took me a while to even understand what's going on, because I've been doing the UIKit navigation for so long – I was very confused about what SwiftUI was even attempting to do. Now I'm more on board. I still would like a little bit more laziness to it, an option for laziness, because sometimes having your entire view hierarchy render at once can be a bit much. Something that I learned the hard way is it's really important to think about how things will be rendered.

"Why is this performance so garbage? Yeah, because that's not meant to happen. So you have to be careful about where you place your UIKit integration."

For example, SwiftUI renders very quickly like we mentioned, whereas UIKit does not. What you don’t want to do is put yourself in a situation where your UIKit views are re-rendering, and trying to do that 60 times a second, because UIKit was not meant to re-instantiate that frequently. I ran into the issue I had a collection view on the same page as a text field. Every time I typed a letter, it would redraw the collection view. I was like, "Why is this performance so garbage?" Yeah, because that's not meant to happen. So you have to be careful about where you place your UIKit integration.

Paul Hudson: I think because UIKit is based entirely around the idea of classes, and so your UIView comes from UIResponder, which comes from NSObject, and so on. And when you have a UIStackView or whatever it gets all these properties and methods that just come with it, whether or not you need them. For the longest time, you could set a background color on a stack view and it wouldn't do anything – it was a non-rendering view. I think changed in iOS 13 or 14.

Ish Shabazz: Until this year.

Paul Hudson: But those properties and methods did nothing at all, because it wasn't designed to do that, but it still had this property and the methods, with memory being assigned to it across the board for all its parent classes. It was expensive and that's entirely gone away, because it's all now simple in SwiftUI.

Ish Shabazz: Absolutely. So that's a thing you really have to look out for, in understanding the differences between the structs and classes, and being mindful of not just injecting a class into a struct without understanding what that might lead to – usually latency, you end up with some choppy behavior at that point.

"The calendar picker made me pretty happy. We had a really crappy calendar picker for a very long time. And to be able to actually see the grid calendar, I thought was great."

Paul Hudson: Yeah, I certainly think that SwiftUI, is one of those things that brilliantly determines the difference between easy and simple. It's very easy to make SwiftUI applications, but none of it is simple. The struct and classes thing alone is time consuming, but then property wrappers for understanding what's happening there.

Ish Shabazz: There ends up being a lot behind it. SwiftUI hides a lot of stuff for you, but if you just dive in you get to see, "Whoa, there's a lot a going on.” That’s why for a while I was really hoping Apple would open-source SwiftUI – then we would see how they're doing things. But I realize there's probably a lot there that we never get to peer in on. For instance, I'd really like to understand what forms are doing, because it's a lot of formatting. We use the Form view – it rounds the corners of the list, it provides a little padding, it changes the font style for the section headers; there's a lot of additional stuff that you don't see, all you see is Form.

Paul Hudson: There's of course the push and pop-behavior pickers that had the crowd go wild at WWDC, or buttons changing a bit, or inline table rows – it's just, “yeah, it's exactly what I want. Good job." Joseph Heck says he hopes he sees focusable views exposed more in SwiftUI.” And I think I'm guessing here, he means the ability to add focus to views, and take it away again. Which particularly right now is problematic – you want to say, “hey, resign first responder." And there is still now no way of doing resign first responder. We're waiting for a WWDC21, maybe to get something like that in iOS.

Ish Shabazz: I certainly hope so, because right now, unfortunately many times I have to wrap a UITextField, because just from user experience. Basically say you want to log in, put in a username. You don't want to have the user tap to put in the credentials, because what else would they do? That's why they're there, to put in the credentials. You want to have the focus already there. And then when that's done, they hit return. You didn't want to move the focus to the password field. And currently with SwiftUI, that's just not a thing. And it's unfortunate.

"Thing you really have to look out for, in understanding the differences between the structs and classes, and not putting, being mindful of not just injecting a class into a struct without understanding what that might lead to."

Paul Hudson: It's unfortunate, but I can imagine being someone who's got some important client work, and the client's work, just dismiss the keyboard now and like, "Oh, that's surprisingly hard to do." It ought not to be, it should be a simple thing to do, but it is surprisingly hard to do in SwiftUI.

Ish Shabazz: Absolutely, and as such, at that point, it's just easier to just use the UIKit version of it, which I really don't want to do, but it's just so much simpler at this point to go that route. So I, for sure, that's at the very top of my list for this year. Last year, it was really near the top. Last year, the top was text views, because there was no multiline texts. And the collection view, there's no grid. Multiline texts, I'm like, "How do you not have multiline texts?" Now we have multiline texts, but cannot automatically gain focus easily. So I should've been more specific in my wish,

Paul Hudson: So demanding Ish! Never happy with what you've got.

Ish Shabazz: This is true. I'm never happy. But yeah, that would make me a lot happier. Although the calendar picker made me pretty happy. We have had a really crappy calendar picker for a very long time. And to be able to actually see the grid calendar, I thought was great. Although I hear not everyone loves the new time picker. I think it's fine, but a lot of folks don't like it.

Paul Hudson: No one likes change, Ish! It's interesting because I think we're seeing these things because of the increased iOS-macOS integration – they didn't wait 14 years to introduce a color picker just for fun. They added it only because you had to have one to fit into the macOS ecosystem, to have a color picker is basically required on macOS. And so now we've finally got a color picker. So maybe macOS plus iOS should have happened sooner.

Ish Shabazz: Yeah, so much is going everywhere at the same time. So for instance, we got popover views on iPad, but we couldn't use them on iPhone for quite a while. Remember that? It was, you get this thing but you only get it in this one area. And going across the board now.

Sponsor Hacking with Swift and reach the world's largest Swift community!