SwiftUI vs UIKit - Comparison of building the same app in each framework

[@brianbkcodes1449]

The side-by-side comparison is great! Felt like it was a director's commentary or a sportscaster narrating what was happening in the game.

[@awais.fayyaz]

You are doing amazing work Paul. Keep rocking !

[@PhilipBacchi]

This is fantastic and I LOVE the side by side comparison. PLEASE do more of these side by side videos!!!!

[@porroapp]

Watching this at the end of 2023, I can say I have no need to learn UIKit with SwiftUI. I come from a ReactJS background and learning SwiftUI just made a lot more sense given it's declarative nature and less boilerplate code. Very happy to learn SwiftUI it's so far so good.

[@tonynguyendtn1984]

Your videos are so good I’ve bought your book and now I watch and click on all the ads on your videos to make sure that you get every last cent out of the advertisers. You deserve it!

[@CapDrew]

I am new to swift and this is great advice. Never knew what they were until now

[@hanzalaraza8709]

if you are comparing both the framework and time to achieve the specific milestone , you should have chosen the fastest way for implement UIKIT which is through storyboard then we could call it a fair comparison .. by this time , this comparison is not fair .. we can achieve these milestones in much quicker way in UIKit by using Storyboard , outlets , actions etc Btw i like the way you are comparing frameworks

[@rebeloper]

Also, one could use awesome github repos like TinyConstraints in making layout super fast. The main difference between SwiftUI and UIKit is not how fast you can build apps, but how to approach building apps. This has also been said by Paul in numerous other videos of his.

[@alexanderlester7455]

I would really like to see a similar video comparing UIKit (with Storyboard) compared to SwiftUI. I really appreciate this video though!! I’m finding the switch from UIKit to SwiftUI to be EXTREMELY difficult though honestly... It seems so difficult to write clean code using SwiftUI

[@bartoszdolewski4915]

Great comparison but I HIGHLY enjoy that kind of video template. I hope I'll see more video-templates like that from you, where the coding is done quite fast and you comment stuff in real time with pause breaks. Great way to keep video relatively short, busy millennials like me really appreciate this ! :)

[@cultibotics]

Cool! Having three instances of Paul might make it even better: one working with and advocating/apologizing for UIKit, one working with and advocating/apologizing for SwiftUI, and one moderating.

[@wyattb3138]

I’m learning Swift as a hobby. I use Interface Builder instead of coding with UI kit. It’s intimidating to see that I will have to learn how to programmatically make a UI. Your videos help me so much and help me gain experience in Swift too. Thank you.

[@bobbynwm]

Mate, this is funnier than expected! You make UIKit look like an old timer :) This video definitely convinced me to move into SwiftUI prototyping as honestly I've got completely cluttered into Storyboards and ViewControllers mixed with code and seques and all of that ... just to build the prototype for development... :)

[@mauricejulesm]

I wish many people using this side by side way of comparing frameworks, it's very helpful when one wants to decide on which to use. Thanks +Paul Hudson

“Hacking with SwiftUI” will be best series on KZbin !

[@valerika9164]

Side by side comparison is a really cool idea! Thank you for you work, Paul 🙏 You are amazing!

[@AhmdIsmail]

Thanks Paul for this great video! I actually started to use SwiftUI on my main project couple of months ago and I'm mostly satisfied except for one problem which is backward compatibility. Many great features of SwiftUI today are exclusively available for iOS 15 which makes me feel that I should've waited for a year or two not to get new features but to only use the existing ones while being able to support at least two major versions of iOS

[@RubenvandenEngel]

As you said, UIKit and SwiftUI cannot easily be compared. For instance I'd usually create a xib file for the detailview just to make the layout with all the constrains using the interface builder. This is because the constrains in code are so ugly and take a lot of time to write. Now in SwiftUI constrains aren't a thing anymore and create elements by code is made a lot easier. So it's still not completely fair to write everything in code and time it. Then of course SwiftUI will be better.

[@ltq0809]

as we create a new project, we are choosing to use SwiftUI or Storyboard, not UIKit... so i would say, if we know how to use storyboard very well, it might not be slower than using swiftui

[@denisblack9897]

swiftui is cool, but it still has 2 years till it's gonna be used in production

[@ВладТретьяков-г4с]

Take a moment to notice how SwiftUI introduces multiple levels of abstraction with extra `UIViews`, while UIKit keeps the view hierarchy looking neat and simple. 🎉

[@15458434]

I'm pretty sure this was faster constructed in Interface Builder. Having both projects finished around 9 minutes.

[@thwKobas]

Not fair at all, there is no need to create detail view controller in code, you can just drag and drop UI controls on storyboard and create whole screen easy. This would for sure reduce lines of code for UIKit, and I think you did it on purpose this way. I don't say UIKit is better, or that SwiftUI is better, just that this was not good enough comparison.

[@charlesm.1638]

I wrote an app to be used within the company I work for and was stunned of how quickly I a managed to write the app in SwiftUI including having to fetch a JSON from my API. But I agree I am still working with both UIKit and SwiftUI.

[@guitaripod]

Awesome video. It's so cool how the SwiftUI code can run on all Apple devices with some minor adjustments.

[@staybalancedn]

Guitaripod not my iPhone 6...

[@guitaripod]

staybalanced it’s time to move on from 2013 my friend

[@staybalancedn]

Guitaripod give me one good reason of a feature to upgrade. I haven’t been moved to get a new phone new features seem more like gimmicks

[@guitaripod]

@@staybalancedn You already answered your own question 😸

[@evennot]

​@@guitaripod iOS 13 still has quite a few awful glitches. Forcing people to dispose a working device for sake of new way of arranging views in the editor is kind of a weak excuse. It's not revolutionary either. React Native goes with this concept a bit better: more forgiving view state management, stylesheets, etc. I have new devices for testing, but iPhone 6 is still more usable, even after I bought lightning-audio-data port adapter. TBH, newer iPads have sidecar option and apple pencil. First one is slightly glitchy, but second one is a killer option (both in terms of usability and price)

[@MrEvansjethro]

Thanks Paul, very informative. I'm starting out with IOS development and I needed to know what I am getting myself into. You simply made things easier for me. I truly appreciate you.

[@AleMohamad]

This was amazing! Loved the comparison, and it’s great to still show that UIKit still has the power to make iOS apps. It’s gonna be with us a lot more, until SwiftUI gets the power to compete with UIKit in bigger projects. 😉

[@Sergio-eg1ex]

Hi, thanks a lot. What is yours opinion about start learning SwiftUI in 2023? Or you strongly recommend to learn UIKit as well?

[@ClarkCox]

Why, in the UIKit version did you need to add a wrapper view to inset the text? Why not just set a width constraint on the label?

[@fdaygo7794]

I imagine to do it properly with display scaling

[@WolfiiDog13]

Just found this channel, and I'm loving it.

[@SuperMacGuy]

Super cool demo. But I feel it’s not exactly fair to do all the layout in code for uikit. I’m a believer in doing that in the visual editor. Wouldn’t most people do it that way?

[@cappuccinopapi3038]

I’m speechless this was so enjoyable, so much better than my university lecturer.

[@ImprovingAbility]

with the advent of the Corona virus traditional schooling will die (at least that's my hope)

[@ondrejpisin7567]

I'm not sure how valid this is, usually you use SnapKit or some extensions for constraints, but also you choose app format where SwiftUI really shines. Anyway nice comparison, thank you.

[@raitasorin]

Ouh mate i can't denied how that Beautiful and shiny was ! I love that Bro well done, please stay more around The Blue Planet

[@mrglwatson]

Wow, amazing that you programmed it that quick.

[@SladeruS]

Thanks you for your videos to help us to learn swift. Have nice Christmas.

[@dimiutube]

Thanks, Paul! This was a good comparisson for these two frameworks. I will stay at UIKit, but SwiftUI is definetely a good way for building new Apps with limited functionality quickly.

[@raitasorin]

Yeah but where is today Objective C ? So that far will go UIKit to will disappear as well just like Objective C so UI Swift will be taking he's place very Soon

[@andreisaioc]

@@raitasorin Not that soon, i suspect that another 2 solid years uikit will still be top. Then slowly fade away. The swiftui will need at least 2-3 years to mature at the point where you can make a real complex app. UIKIT is here for 10 years now...

[@omick16]

Why didn't you use a storyboard on your StarshipViewController and just pass around the values? Although sometimes buggy, I think the storyboarding is one of the strengths of UIKit

[@AaronHilton]

Great work!! Loved the side by side comparison.

[@nikitayankov3935]

Would it be less lines of code and, probably, much faster with using storyboard for UIKit (outlets, view composing, segues, etc) ?

[@VahidSayad]

of course.

[@punishedbrains9954]

Yes and that's why I think it's not really a fair comparison. UIKit is meant to be "meant to be" used with the storyboard to set stuff up and then programmatically tweak it a bit. I think it would have finished very close if not faster.

[@Seitenwerk]

@@punishedbrains9954 Using SwiftUI ist much faster then Storyboards and UIkit. Example: Try setting up a table with Storyboard. You will have to add it to Storyboard, add a cell, design the cell. Then drag everything into your view controller. Then add the delegates, and delegate methods, then implement the code to tell the table how to deal with the data, which you will also have to implement. Now compare all this with how it works in SwiftUI: Just wrap whatever content you would like to have in a cell in "List(){..}". Finish. ^^Thats it. No Protocols, methods, data, etc.

[@evennot]

@@Seitenwerk except when your table starts to grow immensely. Or if you'll need to perform animated edits to the table. Or if you need just to scroll somewhere in the list. Or basically anything other than a flashy demo. I think SwiftUI has giant potential but it's still just a tool for quick prototyping

[@ecx007]

@@Seitenwerk Really? With a simple right click you assign the delegates. And the methods of the tables I have them in a snippet

[@CodeWithCal]

I wonder if UIKit would be quicker if you use storyboard to define the layout rather than doing it programmatically?

[@DorkSanat]

the course I bought is ios app development - angela yu from udemy and it is based on xcode 12 (when ui kit was still used) but this is 2023 and xcode is ont having uikit option we create a file based on swift ui, what should I do ??? please help

[@tigran.zakaryan]

Paul is your opinion about UIKit is still relevant by 2023?

[@jjamespacbell]

Great Video and loved the comparison but... Most developers would have used Autolayout in storyboard to create that app prior to UIKit. would that have been the faster approach?

[@jjamespacbell]

I meant to say prior to SwiftUI not prior to UIKit

[@ashleymills69]

@@Glassip It's NOT "always more clear to have everything in code"… that's purely your opinion .

[@b_t_s8792]

I think you’d be surprised at the percentage of UI in the top chart apps that is not storyboard based. There are trade offs between code and storyboards, and the larger the team and longer lived the app, the worse storyboards look. That’s a big part of why swiftui is so exciting, we can finally use interface builder without most of the downsides.

[@anudeepananth]

This is a great video comparing the two platforms, amazing... thanks for this...

[@tedvga]

Compatibility. Unfortunately SwiftUI is only available for iOS 13.0 and higher. Using SwiftUI would thus mean that you can no longer support people with older devices. There are still millions of iOS devices out there with iOS versions older than iOS 13, and are no longer be updated because Apple (policy) does not supply updates for this older devices. Take, for example, a banking application with millions of users. Of course, as a bank, you must support as many devices as possible, even those that are bought a long time ago. These are your customers, were you are depending on, whether rich or living on a small budget. Note that for a lot of people, iPads and iPhones are relatively expensive devices. if you live on a small pension budget, in many cases you can't even afford to replace your iPad or iPhone There are millions out there that can't. That is why I make my apps available starting with iOS 9. Unless special features only available in later iOS versions are needed e.g. like AR. I have absolutely no problem with targeting starting with an old iOS version. (but maybe Apple has, because from a commercial point of view of a hardware seller, it is more profitable to "encourage" people to replace their devices as soon as possible. However, I wouldn't go that far to say that Apple is introducing new tools like SwiftUI all the time for that very reason..) Using UIKit is not so hard as it might look for beginners, especially when using a language like Swift. Paul, you're talking about a lot of boilerplate code, and yes, using UIKit needs more of that, but most of it in my apps is written-once-use-anywhere in class extensions or even UIKit sub-classes that I've made. (the latter is one of the advantages of using Object Oriented programming, you haven't got this flexibility with SwiftUI because it is based on structs instead of classes) So, in the end because of extensions and sub-classes, my apps are relatively small and run great even on the older devices. No problem. In summary, in this perspective, to get a job as iOS developer, it is very important to master UIKit because at many companies, SwiftUI cannot be deployed, simply because it is not available in older iOS devices that need to be supported. There is a social aspect to this too, think about it, e.g. maybe you have (grand)parents who are happy with their older iPads and iPhones. so restricting or upgrading your apps to a higher iOS version counts them out.

[@YousefHaidary]

Very helpful and insightful comment. Thank you

[@chesterman18g]

great video Paul! However, I think that with swiftUI (for the time being) it's a bit harder to make a really custom UI - currently we are using here basic UIKit ported elements. What you think? SwiftUI is more concise, no boilerplate code. Don't get me wrong, I am currently hesitating to start build a complex UI with SwiftUI.

[@rebeloper]

SwiftUI is still the new kid on the block, but when a UI component is missing one can always use the UIKIt version of it with UIViewControllerRepresentable

[@deegha]

My question is why not comparing the time taken with story board? Its not an illegal way of building apps 🧐. Its like you are asking a moter bike not to start its engine and race with a foot cycle 🤦🏾‍♂️

[@pickemparty]

Can you show the side by side of keyboard tabbing from one text field to another as is done easily in UIKit and unknown in SwiftUI?

[@IMostfa]

Thank you very much, don’t you think that using UiKit with storyboards will make things a lot faster ?

[@evennot]

Also using layout frameworks for doing layout is much faster way to go

[@IMostfa]

Jeffrey Haines after five months of using SwiftUI I'm regretting my original comment 😂 SwiftUI is way better

[@karis_nemik]

Thanks for a great video! I'm curious, which you did first - UIKit or SwiftUI version?

[@swelsh]

Fantastic idea for a video, Paul!

[@richardwalters9249]

Question: If I'm jumping into iOS programming, and I am using the Stanford 2020 SwiftUI class (on the multithreading lecture now) ... am I doing well, or should I have backed up and learned UIKit / Storyboarding first ? Curious as to your opinion

[@AliAljoubory]

This is awesome. Quick question, do you need to have a particular Swift or Xcode version to use SwiftUI? Like Swift 5? My current codebase is Swift 4.2 but I'd love to use it.

[@Gabifuertes]

Ali Aljoubory you need the Xcode beta, which runs on Catalina beta, and you can only target iOS 13 or higher. I’m not sure wether Swift 5 is required but it’s set by default for new projects.

[@ricocrescenzio5067]

It’s required xcode 11, swift 5.1 and iOS 13 to run. I think it’s too early to make production apps with swift ui, because there will be still users with iOS 12 in next 1-2 years

[@fibowibo5359]

what was the real time without speedup? only detail I am missing, nice work overall!

[@gillesashley9314]

I'm planning to move to Canada from Africa, I want to know which market dominates there between iOS native development vs Flutter cross platform development?

[@surestamang33]

Really inspiration video for me. As react native developer,I don't know about it much. I want to know the SwfitKit and UIKit. Your video made me clear. Thank you.

[@CanispaterChristmas]

Nice comparison! I use the containerView trick with stackViews all the time. lol!

[@rdtba21qw]

As ever, hugely helpful and informative - thank you Paul.

[@100coinstar2]

I love your videos... I know I'm late to respond but to be honest, I would rather like to see a video comparing the headaches involved in trying to figure something out that is not working as expected and the time it takes googling or jumping into the documentation for solutions. I think in that case, SwiftUI development might be slower (but that's just me).

[@ZoeSummers1701A]

I really appreciate the effort and detail in this comparison but it’s not a fair test. UiKit’s auto-layout is horrendously complicated because it’s so flexible. But it’s intended to be done in IB with code as the fallback. Surely a better test is do UIKit in IB vs SwiftUI?

[@jonathanmorris1480]

What about next 4 years time? Will Swift ui be the norm in 4 years?

[@alejmc]

This is amazing on so many levels. Having bumped into your channel has been a great thing. Thanks lot for these. Had a question, was checking your Gumroad and for a complete beginner on Swift (but not so much on programming, I mostly do C# and shaders) which pack should I begging with? Power Pack or Plus Pack? Cheers.

[@twostraws]

Definitely the Power Pack, but save your money and follow my free 100 Days of SwiftUI first: hackingwithswift.com/100/swiftui

[@jason18401]

Hey Paul, can we get a tutorial more slowly explained as well?

[@AvenCode]

It's so clear! Thank you so much! Great job.

[@cridgit001]

I subbed because of this video. Super helpful. Thanks so much.

[@darryl_young]

Another great video. Thanks, Paul!

[@richprice5434]

great video...im still in the UIKit camp for now. my question is... will all the big companies adapt to SwiftUI or stick with UIKit? i still think when going for jobs for the next few years, building out an app in code using UIKit is still going to get you job over SwiftUI.

[@adviceforidevice4536]

I think that'll depend on how fast SwiftUI will adopt.

[@TheHy6xD]

Paul, I did not know these features like customSpacing for stackView and fast coding in UIKit. I am tired so much of spacing in stackView, thanks for that method a lot!

[@0xifarouk]

Can you upload this project please?

[@shingetzu88]

Amazing! Thanks Paul. Are any of these projects in your github?

[@zatochiSiberian]

Thanks. What about memory footprint and performance?

[@darrylthomas4306]

Excellent video. Thanks! Just subbed.

[@supriedonk]

Just wondering, on UIKit we usually load asynchronous data on ViewDidLoad or ViewWillAppear. How we do it on SwiftUI? On init? or introduce another method ( like load data, and somehow reload the UI once the data is loaded )

[@supriedonk]

i just found out from your others video, that we can use @State for this case. Can’t wait to try it out

[@mohsenkhosravinia4703]

I think you should make the second vc in storyboard and then compare.

[@sergeykolinko]

Hi Paul I’m playing with SwiftUI wright now. And I have a question to you about the WabKit: import SwiftUI import WebKit struct WebView : UIViewRepresentable { let request: URLRequest func makeUIView(context: Context) -> WKWebView { return WKWebView() } func updateUIView(_ uiView: WKWebView, context: Context) { uiView.load(request) } } struct webView_Previews: PreviewProvider { static var previews: some View { WebView(request: URLRequest(url: URL(string: "www.apple.com")!)) } } //All works. But keyboard is not appearing when it needs. If you have any solutions it will be great! Thank you!!

[@westfield90]

As a complete novice wanting to learn iOS programming which platform do you recommend to get the basics correct ?

[@Aaron-dt3xz]

Depends on what you want to do. SwiftUI is amazingly fast and easy to use, but it is definitely missing some features. For instance, if you want to do something like, say, move a textbox up above the keyboard when typing, that isn't something you can do with SwiftUI yet. SwiftUI also doesn't support a lot of elements like WebViews. Additionally, SwiftUI only supports iOS 13, so if you're planning on actually distributing an app, it shouldn't be used as a complete replacement for UIKit yet. Therefore, I'd recommend learning UIKit (at least the basics) as well as SwiftUI, since the two are interoperable. That way, you can create most of the stuff you need in SwiftUI which makes things a lot easier, and if you want any of those advanced features only in UIKit, you can embed them into SwiftUI (and vice versa).

[@evelynlima3769]

How about a mixed one? Using swift together with swiftUI

[@marioepsilon]

The layout part that wasted most of the time for the UIKit version was done wrong, you don't need to use stacks, in fact stacks makes it harder. You can do it very quickly in many ways, I can do the entire constraints of that view with just 5 lines of code using constraintsWithVisualFormat. Anyway, "faster" or "less code" is not a suitable measure of how good something is. When it comes to code, you might have to spend more time at some point, but it saves you time later.

[@atlassimulor8512]

Thanks for the info and for these examples!

[@volimpia]

Great video, although i feel it was not very fair to UIKit. It has storyboards and it is a greate advantage, if we had done all the code in storyboard - it would have taken equal time to SwiftU, and code lines would have been shorter. I love storyboards and do not code programmatically much, so maybe i am biased. But storyboards make creating UI super fast, in fact at first i found it faster than SwiftUI.

[@andywong3095]

Excellent. I think, I am very good with XAML, but I can estimate, it will take me, about 1 hour (may be more) to do the same app on UWP. Nothing wrong with XAML or UWP, it is you, you are much better than me. Ha. Thank you!

[@shotaioramashvili3935]

Great work Paul !!! Thank you.

[@ejpusa]

hi, is there a link to the code examples? thanks

[@top10exploration1]

That was Great Toturial easy comparison.

[@mobilemon5032]

So we can't use both UIKit and SwiftUI in the same project? It has to be one or the other?

[@DonavonBuchanan]

Both can be used in the same project. It looks like SwiftUI will only be supported on iOS 13 and MacOS Catalina though.

[@drewmccormack]

"Lots of boiler plate code for UIKit". Yes, that is because you didn't fully leverage the storyboard. This whole in-code approach is a waste of time. You could have done all the autolayout etc, detail controller etc much faster using the storyboard. So a bit of an apples and oranges comparison. The UIKit version could be much faster.

[@vladnet5485]

Drew McCormack agree 👍

[@pierremoreau5597]

I agree, he could have done this app in UIKit within 9min too and less line of code then SwiftUI if he used properly the storyboard.

[@vladimircreator]

Storyboard is less maintainable than code so it does not make sense to use it

[@HerrThomasE]

Great! Thank you very much 🙂

[@droid6298]

Sir how can i pick videos like in image picker SwiftUI

[@moksh8]

Why would anyone use UI kit to hand code the design in the first place ?! That’s counter productive and against the basic functionality of the product.

[@Ascentyon]

Some reasons I'm strongly in favour of hand coding the design: - Storyboards/Xibs are XML files. Have you seen the conflicts on those things? Also, reviewing pull requests that change them is massive PIA. - There is no way to define a constant for your colors, padding, font. Good luck updating your branding. - Reusing components is a massive PIA. If you need the same collection view cell on 2 view controllers, you need need to create a Xib for it and do half the work in code. - Simply opening Storyboards/Xibs files in a different version of Xcode generates 5-10 lines of changes. - If you make a typo in Interface Builder, you get errors at runtime. If you make a typo in code, you get an error at compile time - With interface builder, you need to use implicitly unwrapped optionals. If you forgot to link that IBOutlet, enjoy your crash at runtime. Yes, you do it 2-5x faster in interface builder, but you pay that heavily in maintenance cost later.

[@moksh8]

@@Ascentyon Excellent points ! More the reason why the UIKit must evolve to rectify the shortcomings or the whole design platform needs a better workflow. Perhaps the Swift UI is a step in that direction. Wouldn't you agree that approach to design is best designed and not coded - visually - WYSIWYG ?!

[@ecx007]

@@Ascentyon Fake, after 3 months without touching the Swift UI code this will look Chinese to you.

[@ricocrescenzio5067]

Nice but I’d rather have used storyboards and xibs for this kind of comparison

[@jooowtjuh]

I am new to ios development, would you recommend uikit or swiftui?

[@whette_fahrtz]

Johan Schobben you should try to learn both. SwiftUI kit is new and not totally fleshed out, UIKit is the only way to do a lot of things still. SwiftUI is pretty easy to pick up.

[@rebeloper]

You should start with UIKit. while SwiftUI is easy to pick up, UIKit still has many things that SwiftUI cannot do. Also you will not get a job with SwiftUI alone.

[@thedude4254]

how is your IOS dev journey been so far?

[@sourPollo]

I’ll be doing your 100 days of SwiftUI soon.

[@rodyharris]

Excellent video! Thank you

[@regandawson6347]

UIKit ‘in code’ is not a fair comparison lol this would be trivial to make in interface builder, almost no code at all required

[@averoes4029]

Thank you !!

[@mizoto6550]

SwiftUI won but you had to purposely make uiKit take longer by doing it programmatically. Not sure why you did that if the goal was to see which one was faster...

[@gabrielrml]

So the moral of the story is use UIKit and charge by the hour.

[@timmy334]

Can you do one addressing translating a UITextView for text entry into SwiftUI?

[@retrocu]

i never use uikit without interface builder. so all of coding the interface is simply do not exists in my workflow. if i need a custom ui element sure i can code that but after coding over i use that new uielement inside of interface builder. and i use a storyboard for every viewcontroller and it works great and clean. without interface builder swiftui will not replace uikit. for people who do not use ib and code every ui element sure it is great. but without interface builder this is simply is much more code. and i do not want code more.

[@altamistral]

I agree. A comparison to UIKit without IB is like competing in a race blindfolded. If he used IB the UIKit workflow would have been ridiculously faster.

[@ThierryZanzouri]

True but not sure it will be the same while handling datas manipulation and complex actions. SwiftUI is great to design screen but when you try to manipulate datas its need a lot of thinking.