CompileSwift Podcast – Listener Question on SwiftUI vs UIKit


  • Share on Pinterest

Season 4 Episode 6

We have a bit of a bumper episode this week, quite a few things to get through.

First of all, if you did not catch the stream by Cocoatype on Friday night, he was doing an April first special. Oh my gosh, you missed out! You need to check it out.

I think the lesson learned was never let anyone submit bits to make you eat hot sauce. Go check out the stream. That's all I'm gonna say.

I want to give a shout-out to Cevnz, thank you so much. You said you listened to a whole bunch of podcast episodes. I greatly appreciate it.

Britishfrog dropped by the stream and suggested the topic for this episode.

But first, what have I been doing this week?

I have been doing a lot of SwiftUI and it really made me appreciate some of the good and the frustration when working with this new technology. I think that a lot of the frustration honestly just comes from not practicing enough.

I'm sure we all go through this when you're professional developers. You use a whole bunch of different technologies more than likely every week, especially if you're working for a company or something like that and you've got multiple apps of varying ages.

This week I have worked with, JavaScript, React, React-Native Objective-C Swift, and SwiftUI.

It has been a busy week, it also made me appreciate how much I can do with SwiftUI very quickly. In a couple of days on some side projects of my own, I have spun up views that I think look pretty good. They certainly matched the designs, which is a win right there by using modifiers and creating custom modifiers.

Custom modifiers are something I should probably talk about and do some videos on at some point. It made me appreciate how quickly I can spin up views for approval or changes from the client. 

Britishfrog dropped by the CompileSwift.live stream chat room with the following topic suggestion for this episode.

What are my thoughts regarding SwiftUI and UIKit, and which to use? Both from a project and a team perspective.

Here's my approach.

If it's an existing app that probably uses UIKit, whether it is storyboard or code-based generated views, I leave it alone until I feel it's necessary or the entire team agrees that the time is right to rebuild with SwiftUI.

Now that can mean different things to each of us. I'll give you a couple of examples.

Maybe you've got a really complicated storyboard that's giving you problems or something that you now need to change in some way, which I think is a good reason to go back and consider SwiftUI.

But it’s not that simple, what is the underlying view controller, business layer, and everything else written in? Is it written in Swift or Objective-C?

If you answered Objective-C, now you've got to decide if you want to convert to Swift as well. Because that will certainly make life a lot easier. Again, your experience may vary. And if you've got no experience with that, the question is, do you want that headache?

Then there is the question of time, do you have the time to take on that conversion? Now we all know that there's never enough time given to engineering tasks compared to features requested.

 I'll get into some of the approaches that I think are a good way to do that here in a minute. 

If you are looking at this question when starting a new project. I think you have to look at the project and say, what does this project need from the user interface. What kind of components? What kind of views are we going to need here?

Make a list. Whatever you anticipate or hopefully, you know, by now, if you're at this design stage, architecture stage, what is the app going to need?

Because what you need to do then is take that list of requirements for the UI components and do a little research, a little homework, look at it, and find out if these components already exist in SwiftUI?

Am I going to have to build them? Can I build them or is this just asking for a nightmare and I should go with UIKit because of what I need now, the reason I say this is a couple of times it's hit me where I've gone to do something then I realized that either the component isn't there yet from Apple, or yes, I could build a custom one, but it's just not worth the level of engineering effort.

Finally, there's a hybrid world that you can live in. You can take a SwiftUI view into a UIKit app and vice versa. That is an option that I think is a good one. And I've mentioned before how thankful I am that we can do that. This gives you the best of both worlds with perhaps a little bit of pain in the middle, but maybe if 95% of your app can be built in SwiftUI, but that 5% is some custom components you built for your company or some proprietary thing, you could still bring those in, in a UI kit wrapper.

My approach is to ask these questions to myself and my team to look at it on a per component per view and per-app basis. If it's an existing app, I like to go the route of converting over time. I like to work with my team and say, okay, let's look at what makes sense. So let's break this down.

Converting Objective-C to Swift at the business, the model level, all of that underlying stuff is pretty straightforward to do at this point. You can go in there, you can do that. You've not touched the views at all. This will make converting views much easier down the road.

When I say. How much time do you have to do this? How much time is a product or a company timeline release cycle going to give you? Do you have time to deal with the business layer first, and get that up to speed.

When it comes to rebuilding views, start with the simple ones. Then move on to the ones that cause the most pain. For example, views with complex constraints.

There are some folks who think SwiftUI is terrible right now, but at the end of the day, it's not necessarily about sticking with one technology or, poo-pooing the new thing because you like the old thing it's about delivering products.

If switching to a different technology like SwiftUI enables you to do that quicker, more efficiently, more robustly, and more reliably. Then it’s something you have to think about.

This is my advice to everyone on any software platform, always be aware of those technologies around you and how that's going. Stay in touch, and read the news. It is so easy to just keep doing your thing and not pay attention to the world around you until the world catches up with you. 

Then you suddenly got a lot of homework to do.

I'm hoping this answers your questions. If it doesn't please reach out to me.

Subscribe / Follow The Podcast

Click here to see all available platforms

Listen on Apple Podcasts
Listen on Spotify