AppForce1: news and info for iOS app developers

Twitter Space: SwiftUI versus UIKit

February 18, 2022 Jeroen Leenarts
AppForce1: news and info for iOS app developers
Twitter Space: SwiftUI versus UIKit
AppForce1: news and info for iOS app developers +
Help us continue making great content for listeners everywhere.
Starting at $3/month
Support
Show Notes Transcript

This time Stefan and I share our thoughts on the topic of choosing SwiftUI or UIKit for your next iOS project.Fortunatly things are very nuanced and there are also some clear guiding principles we were able to come up with.

The Paul Hudson video comparing SwiftUI against UIKit mentioned by Jeroen.

Blog written by Jeroen:
UIKit vs. SwiftUI: How to Choose the Right Framework for Your App

Runway
Put your mobile releases on autopilot and keep the whole team in sync throughout. More info on runway.team

Lead Software Developer 
Learn best practices for being a great lead software developer.

Support the show

Rate me on Apple Podcasts.

Send feedback on SpeakPipe
Or contact me on Mastodon: https://hachyderm.io/@appforce1

Support my podcast with a monthly subscription, it really helps.

My book: Being a Lead Software Developer

Stefan Blos:

Welcome, everybody, to the space. This week, we will talk about Swift UI and UI Kit today, I think the vs in the title is already, maybe a little misleading. But we'll come to that later on. We prepared a little bit of things today, we will start off just with a quick comparison between swift UI and UI kit, what both are, and then talk a little bit about the differences. So in the way they are built, and everything. So that will be the second point. And then we will just close up with some overall thoughts we have, what our opinions are, what we think is, is really the point in this these two frameworks coexisting. And then we're happy to also hear from you, our wonderful audience here to chime in with your thoughts, because we're always happy to hear those. And yeah, so I think we should start with a quick comparison. I mean, probably most of you are already familiar. There's UI Kit swift UI, like it is the is basically the old dinosaur. I mean, that's not a big. It's not a bad thing. It's good. My daughter, she loves dinosaurs. So it's a positive thing. But it's been around for quite a while, I think it was released in 2008. And that's correct. The first version of iOS.

Jeroen Leenarts:

Wow, that's why was the iOS SDK, it was still called iPhone. iOS was an SDK was made available in 2008. So that was like the first public release that you could use as a as a non Apple employee to develop your third party iOS apps.

Stefan Blos:

It's crazy that it's been around for like 14 years already. Right? Yeah. Okay, so spitting out more facts. It's based on objective C originally. So I think most most, if not all, of UI kit is written in Objective C, actually. And so swift, was not around back then when it was released. So yeah, it's been, it's been primarily developed for Objective C, but of course, and adopted for swift as well. So yeah, and I think one of the most important things about it is it's, it's seen quite a lot of evolution over the years, right. So it's, it started off in 2008. But it's been evolving ever since it's still in very active development. So there's a few examples, for example, there's been the last chapter TC, there has been very new API's for buttons, for example, have been have been overhauled quite a bit. And also other other things. So it's not not at all like it's been, it's been neglected by Apple, it's still in very active development. And it's been a very, very battle tested framework, I'd say.

Jeroen Leenarts:

file, let's go a little bit deeper on your on UI kids first, because what a lot of people forget about the state UI kit is actually part of the bigger framework, Cocoa Touch, and called the touches, again, like a derivative framework of the original Mac framework called cocoa. There were other frameworks before that, called carbon. But you could say fairly well, but Objective C. So the language that we most of us started iOS development with was actually the language that technically on a technical level, it was a large part in what saved Apple as a company back in the day, because nowadays, we know Apple as being this huge, big tech company that has total world dominance with their iPhone devices. And they're trying to branch out into other services. But before that, yeah, it was. Apple has been on the fringe of computers and personal computing for a number of years after the initial success, and basically, Steve Jobs getting back into Apple, adopting Objective C through their purchase of the next company with the next operating system, which was the basis of Mac OS. And actually, in the next operating system, they were already using Objective C as the main language. And I have to look it up how many years ago that was, but yeah, suffice to say that as being able to do software development, with Swift, or Objective C and UI kit, or Swift UI, is in large part, thanks to the success that Apple has had with Objective C. And that's it's an interesting history that is well worth looking up, go to Wikipedia or anything. And there's so much cool stuff that has happened over the years with this language and the entire history. That's why it is the way it is So, you could say that I pretty much like I still love Objective C as a language, because that's it's it's amazing. It's low level, but not at the same time. So yeah, just want to share that, because probably along this conversation, people will notice that I'm more on the dinosaur end of the spectrum. So I know I'm going to go extinct at some point with my preferences in Objective C, and the EU will be like the new thing. So you're like the mammal that directs that take over the growth after the dominance of the dinosaurs? Really?

Stefan Blos:

Okay. Okay. That's that's very, very picture language here that. I'll take that. I'll take that. Yep.

Jeroen Leenarts:

So stretch? Why?

Stefan Blos:

Yeah, I think, yeah, as you already mentioned, the safety is basically the new kid on the block, if you want to say so it's been released in 2019. I think it was kept up to see. So it's been Yeah, Rod three years now that it's been out. The difference here is now that this framework is really based on and written in and for swift, so that there's really not a lot of Objective C, I'm really not sure about, if there's internally Objective C working, I'm pretty sure there is, but at least the public facing things are all written in Swift. It's, we get back to that point later on when we do the comparison. But I mean, the most huge difference, I think, is that it's a declarative framework, or UI kit is not. But like I said, we'll come back to that later. And, yeah, I mean, it's due to the fact that it's been released a few years ago. And it's basically we're still still very new. And speaking in relative terms here. It's under very active development. So I don't think someone has done the comparison for the DC. What more sessions were about Objective C or Swift UI? I think swift UI was, was the one with more sessions about Yeah,

Jeroen Leenarts:

Apple is really Apple is really pushing adoption of Swift UI as much as they can. But the challenge they're facing right now is that iOS 1314, and 15 have a very different levels in how good they support swift UI as a as a platform.

Stefan Blos:

Yeah, of course. I mean, yeah, you can, you can see in iOS 13, the first version of Swift UI could be used. And then the next two years, or the next two versions of iOS, new features have been added to Swift UI, some, some minor, but some pretty, pretty important, and really, really beneficial to us. So we will come to that again. But yeah, versioning of iOS is definitely something that's important to keep in mind when thinking about which framework might be more useful. Okay, so I think we we've made it pretty clear what what the two frameworks are. So what do you think? Should we should we just start off with talking a little bit about the differences between the two frameworks?

Jeroen Leenarts:

Yeah, I think that would be a good one to do first.

Stefan Blos:

Nice. What what do you want to talk about? First, we have a few points here that you could choose which one, which one is your favorite to talk about other differences?

Jeroen Leenarts:

Well, I'd like to know what you think of how UI kit and swift UI compare in practice when just using it. Day to day when developing an iOS app.

Stefan Blos:

I think the most important difference here is the way it's used, or the UI is built right? For so for me, I started off with UI kit as well. So for me, I first started off with interface builder. So the visually visual visual version of building UI there, you can drag and drop UI elements, or UI Kit elements. And use auto layout to basically combine those and define the rules that the way they should be arranged on the screen, which is pretty powerful. And it offers a nice way to get into development, I think. Then I learned about, oh, hey, you can also do that programmatically. And I really enjoyed that. So I preferred that way of the visual one because I think it offers a nice way to to be very specific about everything and write it out. For the same time it takes quite a while to to write all these rules and all these other layouts code. So let's sit down stuff that I would say, but at least you have, you have both possibilities. And they're both both totally valid to do. Whereas swift UI, it has this this declarative UI that you just write in code. There's also some, some additional helper things that Xcode offers you, where you can embed things that you can also use the elements from the UI. But I think the main way to do it is to write it in code. And then you have these wonderful previews on the side, that when they're working, I think everyone who has worked with those notes that they sometimes are not that reliable. But at least to me, I can say most of the time, they're working pretty well. And you can, you can see the code you're writing directly translated into your eye at the same time. Which of these, to me is one of the features I love most, because it just offers a way to be so quick about building UI. So I think that's a nice advantage that swift UI has there. Yeah, that's true. Yeah. So the one one big difference, though, is the underlying programming paradigm, right? So UI kit offers more like an imperative approach, or Swift UI is more declarative? Can you? Can you be a little bit elaborate on that? What what, what the difference is and what that means?

Jeroen Leenarts:

Yeah, so yeah, basically, what it comes down to is that what UI kit, you really have to define what you want to have on screen. And if you want something to change on the screen, you have to do that explicitly. So you have to take a label off of the screen, or you have to change the contents of the label, you really just putting and removing user interface elements, and you are updating them by pushing data into them. And that's what you do with UI kit. So with Swift, why it works a little bit differently. Because what you do there, you define a user interface that is about that, that basically is there. And then you update your user interface by changing the underlying data model. So if you change something in the data model, the user interface is directly tied to the data model. So then, for instance, if you change, for instance, a string that's on screen, and it needs to be something else, you just change the data model and then swift why notice this this change in your data mold and make sure that it ends up on the screen. And the advantage there is that these smaller tweaks, you don't have to have to to put this, you don't have to write those very explicitly, like you would with UI, K, a little bit of a disadvantage there is that you have to make sure that your view structure that you have on screen can support all the different ways that you want to have this screen display itself. So especially if your screens become a little bit more complex, then there's a lot more stuff in there. And you need to make sure that your data model then interacts with your view hierarchy in such a way that it has the effect that you want. While with UI kit, you could do it a little bit around so that you have something on screen because you want to display certain aspect of your functionality to the user. And once you're done with that, you can take it off screen and show a new small sub hierarchy of the screen. It's a small difference. But it's really a different way of approaching and tackling the problem that you are trying to solve, which is of course an end user interacting with, with your application trying to achieve the goals of the what you're trying to do with your app. So I think that's like, with the big differences, UI kits, you push data into the user interface. And with Swift UI, the data is pulled from your model by the user interface. And you don't have to explicitly do that. And that's the big difference I see with with UI kit and swift UI, conceptually. And of course, this has all kinds of implications on how you should define your user interface and how you can what API's you're actually working with. Because a UI view is a different thing compared to Swift UI view structure.

Stefan Blos:

I really liked the point you made about that user won't notice anything of that. I think that's something you do your job. Yeah, as developers, it's something that we sometimes forget that the end user doesn't really care about the structure of our code and how beautiful it is, but only that stuff works. Right. But I mean, I think that's the one thing that probably most of the like only developers are struggling with when switching over to Swift UI is the different approach here with a declarative UI and Seeing the UI as a function of the state. That's, that requires a very different approach to creating UI handling the app, state and everything. So I think that's really a point that something, at least for me, I really needed to learn. And just just as a quick, quick side note, we have Martin in this space as well. He's our colleague here at stream. And I think two weeks ago, I had a problem. I was debugging my code, it wasn't working, and asked him to have a look at it. And he said, Oh, yeah, I mean, you're, you're basically doing the imperative approach here. And that's not working out. So he just did a to remind me that oh, yeah, you have to think declaratively. The UI is a function of the state. And once we figured out that everything was working again. So that's definitely something to keep in mind. And that's not always easy to wrap your head around. Alright, but that's the difference for the programming paradigm here between the two frameworks. Another thing we wanted to touch on is the support for both. So if you have a look at the documentation that Apple provides, which is famously very good, right, then you can see that do I could of course, due to it being around for quite a while, has has more, I think the documentation and as well as the content that also like third party, or other people to produce, be it on Twitter, or YouTube or everything. That's more in terms of UI kit, maybe also Stack Overflow, it's important to note, right, because I think people are using that. So I think there's there's a lot there. But as far as I'm concerned, so I think swift UI is catching up there. There's

Jeroen Leenarts:

definitely what you see there with documentation is that it's two things because UI Kit has been around much longer. And especially online, if you are doing things that are more on the edges of the capabilities of the framework, or that is more like that you get into this gray areas that is not very clear in APA documentation, how things are supposed to work and how they actually work in practice, then you definitely can find more on depth on online on websites, blogs, Twitter StackOverflow. But on the other hand, with Swift UI, what you really see is that Apple did a big push on advocating for swift UI to be a very suitable framework for entry of junior developers into app development on the iOS platform, you could have an opinion on whether or not swift UI is very suitable for junior developers, because it is on the surface, first tutorial you run through it's it's simple, you think, but then it gets complex quite quickly. But what you do notice there is that Apple has like a lot of introductory documentation, just getting you to write and define your first user interface with Swift UI and get it running on a simulator or a device quite quickly. And it's, it's two things really, because the introductory material on UI Kit by Apple, it's, it's a lot less detailed and a lot less. There's just a lot less available on that front from Apple. So yeah, so that that's a big difference that I noticed with with Swift UI and UI kit. And but I have to say that on both frameworks, there's plenty of stuff that you can find online. And it is just a matter of making sure that you know, where to search and what your keywords are supposed to be for the problem that you're trying to solve right now. So but I do think that for both frameworks, there's plenty of information available. And you do notice that swift UI has like a more of that it is, because it's newer, because it is more interesting to write about, because that's there's still a lot of undiscovered or undescribed areas there. So there's not a lot of there's still a lot of Greenfield what people can write about with Swift UI. And so New Content becoming available on blogs and stuff is most likely to be swift UI right now. While I think that swift UI is in no way yet for end users, the main framework that we'll be using in production apps, because yeah, most apps have to deal with some kind of minimum iOS version to to be able to run. And I think that's a nice entry into our next topic, really. And that's the minimum iOS version support that you have to be considerate about when you're using Swift UI, right?

Stefan Blos:

I mean, you could definitely hear the podcast host from this segue into the next topic. Kudos to so great job. Yeah, I mean, Swift UI It's been only available from iOS 13 on, as we mentioned before. And in iOS 14 and 15, there's been quite a bit of new features added also some quality of life improvements so that things can be handled much easier considered how it has been done before. But I think you you found a nice article article on that, too, which is talking about, about this, this topic. So can you can you quickly share what it's about?

Jeroen Leenarts:

The article that I wrote or which one do you mean?

Stefan Blos:

Oh, you've linked one in our show notes? And I'm just looking at that.

Jeroen Leenarts:

Ah, yes, that's the that's the that's the first and support any device support that you have with different iOS versions, right? Yeah. Yeah, yeah. So what you're facing is that look for once to do swift UI, you have to make a decision on okay. Do I want to do this on iOS 15? And onwards, iOS 14 onwards. So I have 13 and onwards. And yeah, it is? Well, the thing is, you have to have iOS 13 or more to be able to even use Swift UI. But the consensus online is that with iOS 13, that swift UI is in no way ready to build a full feat build a full featured and complete app. And in some places, it's actually even broken a little bit. So I don't think it's really possible to write a complete app with iOS 13 version of Swift UI. With iOS 14, things got a lot better. And I have seen people build applications with iOS fit 14, and making sure that bridge some specific specific pieces of UI kit into Swift UI to, you know, just fill out these, these these gaps and these missing features in Swift UI on iOS 14. And then with iOS 15, it's just a whole lot better, because with iOS 15, what you notice there is that it's really something that is a lot of a lot has been added on iOS 15. But the minimum target is that if you want to do a full feature, I would definitely go with Irish 14, I think. And it's just something that is to be something to be aware of. And if you look at the device supports that you're looking at with iOS 1314 and 15, you're actually in, in quite a good place, actually. Because I was 15 is supported all the way back to iPhone six s device, I think it was and also like four or five year olds, iPads. And so that's the right now it's not a big issue. I think because back in the day that it was like iOS 1011 And those versions of iOS, it really was like, Okay, if you want to support older devices, which was really a big codebase very important. You were looking at, look, you were looking at a version of iOS that. Yeah, you had to go like one or two versions back to make sure that you had a conference of like four to five year old devices, which is not the case right now.

Stefan Blos:

Yeah, that's that's a good point. I mean, it always depends on the on the application itself, right, what what it requires, or how many, how many versions it needs to support. But I think I think you should be pretty fine for most cases, adding iOS 14 and 15. Support. Right. Just a quick, quick add on that. I mean, UI kit, I wrote in our show notes that I get as the Dwayne Johnson of development because it's rock solid. So I think you should be safe when you use UI kit for basically every every iOS versions there are I think there are a few API's that are only supported on newer Oss. But most of all, most of it all should be to be supported, right?

Jeroen Leenarts:

Yeah, that's true. And, and the one special snowflake in all of this is if you want to do anything with witches, you're definitely looking at at swift UI anyways. So that's also, if you have to stick with UI kit for the long run with your code base, then definitely start pitching widgets within your project, because then you have to use Swift UI on that specific target, because you cannot define which it's without using Swift UI. So that's like a very convenient entryway for an existing code base to at least start using Swift UI in some capacity.

Stefan Blos:

Because everybody loves widgets, right? I use

Jeroen Leenarts:

them every day. Actually. We took the

Stefan Blos:

thing that really helps. But yeah, I wish that more were apps would support them. But yeah, that's a different topic. That's a different topic. So if we if we jump to the next topic of, of the comparison, it's the last one we wanted to touch on. And that's development speed. So I think that's a very subjective topic, right? Because everyone, everyone might feel different for that. But one thing I noticed on on Twitter, actually, that quite a few people voiced after they first encountered swift UI, was that they said that swift UI brought back their choice into UI development. I wouldn't go go that far, maybe. But I think I think there's definitely something to be said that the Swift UI with the way they they offer previews, for example, like I said, sometimes they're broken, they're not always working very well. But at least for me, I can say most of the time, they're pretty, pretty stable. So that's it, that's a huge win for me, considering development speed. And also, I think, due to this declarative approach that swift UI takes where you have a more precise description of what you're going to show on the screen. And the system handles more of the of the underlying tasks. I think that definitely helps in writing more, or writing less code, actually. And probably being quicker about that. Once you've got the hang of it, right?

Jeroen Leenarts:

Yeah, because there's like a really cool video that Paul Hudson did on his hacking with Swift website. And that's pretty much he builds an app, same feature set in, in UI kit, and in Swift UI, and then he just times himself while doing that. And he just makes a comparison, also, by narrating the video on what His thoughts are on this process. And then in the end, the both of these code bases are also available fields just have to look at. So we will probably, once we share some notes on this trigger space, we will put that link in there as well. Yeah. And what's really nice to see there is that if you're good in UI kids, and you're good in Swift UI, you will be done quicker, with Swift UI, according to Paul Hudson. And what you also notice in this code that he's written is that a lot of the animations, a lot of the transitions, all this, all this stuff that makes you that takes your app from a nice app to a great app, that's a lot of that you get for free with with Swift UI, and it seems so a lot of the animations and transitions that that you can do on an iOS device, they are pretty much most of them are done automatically. So I'm just talking about transitions and making sure that the things are smooth for the end user. So and with with with UI kit, you have to make sure that you add most of those animations yourself or that you make sure that you opt into to the animation by declaring that animation should be done by the framework. And what you really noticed with Swift UI is that all those animations, you pretty much get for free, you just update the view model. And then the view hierarchy observes these changes. And this makes sure that all the state changes that are required to reflect the new state of the data model are updated in a nice way on screen. And of course, you can influence that and make sure that it looks even better than what you get out of the box. But I think not having to do a lot of this animation and transition logic explicitly, is a large part of why a code base written is fetch wine with the same features as a UI Kit based code base is a lot smaller.

Stefan Blos:

Yeah, and one thing I want to mention there, I think you can achieve everything with both frameworks, right? So if you especially on the topic of animations, and everything, so I think swift UI has some, some nice gimmicks there. But if you if you know how to do it and UI kit, then you can do the same year as well. So that's, that's something I wanted to add there. Yeah,

Jeroen Leenarts:

yeah. But there's also another one that we haven't touched upon yet. And that's multi platform support. And what we talk about there is, if you look at UI kits, the only thing that you can do with UI kit, in your view hierarchies is something that works on on an iOS app on iPad app. And that that's about it. Of course, you can take catalyst and have UI kit available in some capacity on the Mac platform. But what you can do with Swift UI is that you can basically take the data model, and if you hire a key that you're working with, you can if you set things up correctly, you can take that all the way from the smallest screen that you have available to the largest screen that you have available. And of course, everything around this application logic is, of course, custom to the platform that you're working on. So I'm talking about what US iPad iOS, iOS and Mac OS. But the the, the opportunity for reuse on this whole spectrum of screen sizes is much better with Swift UI. And I think that's something that is very interesting, especially if you are aiming for a new app that is supposed to be working on a watch on a watch on a phone and on on a computer screen reading. It doesn't imply that it's it's a write once run anywhere situation, though. Apple clearly indicates that's not the case article for swift UI. But so it's mostly the UI programming and the model that adhere that is attached that that that is transferable across the entire apple ecosystem. And the only framework that I'm aware of that seems to be doing this cross device support to such an extent, is maybe flutter. But I'm not very much aware of how good this framework is. And I don't want to go into that topic right now. Because that's something that one of our colleagues at stream should tell us a lot, a lot more about. So yeah, and I think that's a very important aspect to investigate. And also to consider when defining what framework you're going to use to write your app with

Stefan Blos:

virtue by last year, I gave a conference talk. There was also like, most about Swift UI. But one thing I did was some live coding. And I was mainly talking about iOS there. But it was really cool, because at the end, I could just say, hey, and now we can set the target to be Mac OS. And hey, our app works exactly the way on the it works on iOS, and Mac OS as well. So it's a pretty cool, pretty cool thing to have. But of course, there are still some, some, some work to be done and some adoptions, but having this opportunity is really, really nice.

Jeroen Leenarts:

I agree to that. And it's difficult for everything that we want to talk about now with, if I'm looking at our notes,

Stefan Blos:

I think we did. So we want to invite other people to share their thoughts. Now, we will quickly quickly to sum up, but if you want to chime in and share your thoughts on the topic, feel free to now raise your hand or whatever it's called into the spaces. I'm still not sure. But yeah, so to free, we're happy to hear from you. What do you think? So it's to me, my overall, overall summary of the topic is, you probably need both. It's not, it's not a great idea to only learn one and have no idea about the other one, right? So I think that 650 is probably the future. Because because it's it's been around for a few years now. Apollo's really pushing it. Newer things, like you mentioned, like widgets, they can only be written with 50 eyes. So I think that's, that's already an indication that that it's it's really becoming more important, the future, but you like it is not going anywhere, especially for larger projects that have a larger history, I think you'll like it will still stick around for quite a while. So yeah, very, very important to know, know, a thing or two about both.

Jeroen Leenarts:

And the funny thing is, say, like three weeks ago, I published a article on UI Kit versus swift UI. And get I'm just going to read a little bit from that. So should you use Swift UI or UI kit for your next project? Well, I think it really depends on your use case. And it's not something that Stefan and I can answer for you. And but we do agree very much that swift UI is something that you have to make yourself familiar with. And make sure that you that you scale up yourself in Swift UI, if you're doing UI kit, only right now. And the other way around, if you're fully invested in Swift UI, make sure to also pick up UI kit because UI kit is not going anywhere in the near future. And the some rough guidelines that I use myself when I have to decide between using UI kit or Swift UI are pretty much these things. So I choose for UI kit, if I can answer any of the following questions with Yes, so and those are if you need maximum control of how your app looks and behaves. So you don't want to have things happen automatically with transitions and stuff, UI kits. If you want to minimize surprises and rough edges while developing. It's gotten a lot better with iOS 14 and 15. But they're still there. Juice UI kit, if you need specific features, frameworks or SDK that that does not support or work well with swipe so swift UI, of course UI kit. And of course, if you have to support iOS 12 and or iOS 13, definitely choose UI kit, you will switch while the other hand is also very interesting. And I love working with Swift two, I actually because it's just so easy to, to hash out some codes and to get something working, that looks great, just from the get go. So that's if you want to maximize development speeds. So moving quickly is more important than having device support. And all those things go with Swift UI. And if you want to have lots of animation transitions that don't take a lot of effort on your end, and also take a lot of code swift UI again. And if you want to prepare yourself for the future of app development on all of Apple's platforms, well, there's there's no discussion there, you have to make sure that you're familiar with Swift UI, I think. So I do think that UI kit is very important right now to be aware of. UI kit is obviously a lot more mature compared to Swift UI, but swift UI is getting there. And what is very clear is that Apple in their WWDC talks, the amount of Swift UI content pieces that they publish. Apple really wants swift UI to be the future of development on all Apple platforms. So that's something to just be aware of. And we got a request from Martin, he wanted to share something. So Martin, go ahead. What do you want to say? Well,

Martin Mitrevski:

first, great discussion, I think you summarized really nicely, the differences between swift UI and UI kit. Basically, I just want to share some experiences, because in the last two years, I've been mostly working with Swift UI. And previously, I do a lot of fewer kids. And you generally think you summarize pretty nicely. But if you asked me at this point, if I start a new project, unless I have to support something, which is below, I was 14, I will always pick swift UI. Because I think it's getting there in terms of features. And its development is faster, as you've mentioned, of course, you don't have the stability of UI kit, but you get some other benefits. And you can always, you know, go back to UI kit for for some features. And I think most of the time, I love it. But there are cases where it can get you frustrated. So I was mentioning this to Stefan before the the the Twitter space. So yesterday, I wanted to provide support in our SDK, when you have a top view support, and you select, you know, channel, you want the top view to be hidden on push. And while this in UI is just flick that you can set up in Swift UI turned out to be a lot of pain. And it's not supported by the native view. And you need to do a lot of bridging, again to UI kids. And stuff like this. So from time to time, there are cases like this. But I think all the other benefits that you get, allow you to sometimes spend some time on issues like like this. So in general, I think if an app or an SDK can support something over iOS 14, then it's a pretty nice choice. But you also mentioned some, some time ago, I think you should know both of them. Because at some point, even if you are a UI kit, only developer, at some point, you might have to develop widgets, which are in Swift UI, and vice versa, if your Swift UI developer, and there are cases where you have some unsupported feature on Swift UI, you have to do something in UI kit.

Stefan Blos:

That's very interesting to share that. Yeah. And I want to I want to touch on one thing quickly, because you mentioned that bridging took UI kit, even from Swift UI is pretty easy, right? And I think that's a that's a very important and interesting thing to have. For example, I I created an app a few years ago, and I revisited that and wanted to add functionality there. And I noticed two things. The first thing was that oh my god, what terrible quarter right Two years ago, and I think that's basically the experience that everybody has. Right? At least I hope so. And

Jeroen Leenarts:

that's two weeks old, actually.

Stefan Blos:

Okay, yeah, that's good. That's nice to hear. And the other thing was that one of this app was completely written in UI kit, it was really easy to just add new features and new UI elements with Swift UI, because it's so easy to bridge between the two. And that's been something I really enjoyed. Because while we progressively saying, Hey, you can choose this one in these situations and the other one, then I think it's nice to know that it's not always the black and white decision, right? Because you can still experiment, the Swift UI and UI Kit based app. While you can also use UI kit in Swift UI apps at points like the one that Martin mentioned, where you need it, right? So has that been the experience for you as well, Martin, when you needed to bridge to IKEA, it's been pretty easy to do.

Martin Mitrevski:

Yeah, it's pretty easy to do. But it's always good idea to try to avoid it. So I think it's best if you do it only in some exceptional cases, like when there is no other way around. But for example, in cases, like let's say you need a search bar, before I was 15, I think it's better to just implement the search bar from iOS 14 with the Swift UI component and just breach everything to the UI kit. So I guess it depends from case to case. But bridging to UI kit, I think should be done with some really necessary. And it's easy, as you mentioned, is just wrapping UI view representable, or your view controller presentable. So it's not really a hard thing to do,

Stefan Blos:

but probably helps you a lot here is the fact that you know, both frameworks, right? You know, when, when it makes sense to bridge to the UI kit from Swift UI and vice versa. And when it doesn't make sense, right. So that's also going to the point that it's really helpful to know about both.

Martin Mitrevski:

Yeah, yeah, totally agree.

Jeroen Leenarts:

So yeah, I think we covered pretty much all the things that we wanted to talk about, Stefan, just 45 minutes into the space already. It's time flew by, for me. So yeah, if there's no other questions, to anybody listening, please follow stuff on me. And also Martin online, if you if you have some questions on using Swift UI in practice. And yeah, with that, I'd say, if you're in Europe, I'd say enjoy your lunch hour, because that's for most of us, then 15 minutes from now, if not, next meal, or next coffee break, enjoy the time. And just think a bit about the things that we shared. And if you don't come up with another question, at that point in time, do feel free to mention us on on Twitter. And we'd love to get in touch with you. And to just share our thoughts and hear about your ideas on on these topics. And also, if you have an idea that we could use for a next Twitter space that you would find interesting for us to talk about. Also feel free to share that with us because we'd love to just do things that work well for people in the audience, because we're actually learning a lot of things by just doing these spaces as well. And it's always good to explore.

Stefan Blos:

Very true. So thanks, everybody for being here. If you have ideas or questions, feel free to tweet at us or you can also send us DMS. We're always happy to receive those. We all share some notes after the space, like we've been doing for the previous ones. And we just wanted to mention we're doing this weekly. So you should be able to see a new space popping up probably roughly around the same time for next week. So feel free to look out for that. And I think with that we're done. So thanks for joining in. Thanks Martin again for sharing thanks to rune for being such a wonderful co host and have a great rest of your day everybody.