My HONEST opinion about UIKit vs SwiftUI in 2023
Vložit
- čas přidán 25. 09. 2022
- The debate between learning SwiftUI or UIKit is an ever-changing landscape. In this short clip, I give my updated thoughts as of late 2022.
My iOS Developer Courses
seanallen.teachable.com/
seanallen.co
Twitter:
Sean Allen - / seanallen_dev
Hired.com:
hired.com/x/1n01g
Book and learning recommendations that help out the channel if you decide to purchase (Affiliate Links):
Paul Hudson's Hacking With Swift:
gumroad.com/a/762098803
Donny Wals - Combine:
gumroad.com/a/909014131
Mark Moeyken’s SwiftUI Books:
www.bigmountainstudio.com/swiftui-views-book/fzc51
Objc.io Books (Thinking in SwiftUI & Advanced Swift):
gumroad.com/a/656585843
Ray Wenderlich Books:
store.raywenderlich.com/a/208...
#swift #softwaredeveloper #iosdeveloper - Věda a technologie
My iOS Development Courses: seanallen.teachable.com
Just signed up - I started applying for iOS jobs a week ago but need to broaden my base of skills somewhat.
Hope you enjoy the content, Thomas!
@@seanallen Hi Sean, could I please get a Slack Invite?
Wow that was short yet agreeable in many ways. As a beginner I was eager to catch up with SwiftUI but just like what you said on your other video, skipping fundamentals have its own downside in a long run than drilling it
This question was scratching my head for the past month thank you Sean
I agree with what you said, but youve dodged the ultimate question there. Whats the future? The future is SwiftUI. And fundamentally, its hard. My advice, as a principle iOS dev with 12 years experience, is to go with SwiftUI, and Combine, and functional declarative programming. Theres a huge amount to understand in both UIKit and SwiftUI, but the difference is like that between internal combustion engines and electric motors for cars: why would you learn how to create an internal combustion engine when its clear the future of cars is electric motors?
.. the one reason you would learn about internal combustion engines is because, its good to have that background for your knowledge. The same is true of UIKit. Its good and useful to have knowledge of it. But this wont become your main skill. Its not the thing you need to be expert in, anymore.
Thanks for the clarification, Luke Smith.
Apple is really hurting their ecosystem by limiting first class development to a couple of rarely used languages. I can understand why they discourage C/C++ for app development, but there's a lot of applications written in those languages. Porting those apps to Swift is quite involved and requires a steep learning curve. Moreover, are tons of safer programming languages than C/C++ out there such as Object Pascal, Rust, and Ada, but those languages are not first class citizens.
I stay as where I am...UIkit for complex iPhone applicaions, and SwiftUI for watch applications (that are bound to have simple processes)
Thank you for that!! I was so intimidated/overwhelmed with both, but this puts me a little at ease. 🙂✌️
Happy to help!
well usually a lot of companies now a day are using uikit, i think it's related to version support issues which is (SwiftUI) is currently have and some other issues like not too much compatible with some design patterns, as an iOS developer we are using UIKit for our company :)
I started iOS development because of SwiftUI - I love it! But when I got my first internship, UIKit is used over 90% of the time. So I am learning both, UIKit because I need it at work and SwiftUI - simply because I love it. It’s pretty exhausting, but I am making progress at both. Is it still bad and I should drop one for another (in this case drop SwiftUI)?
I would say if you already have a job as an iOS Dev, you should learn whatever the workplace needs first. Then learn the other. I'm not saying it's impossible to learn both at the same time, it's just the harder, slower path.
Same boat!! Doesn’t hurt to do both!! We will survive and prosper!
And I am a flutter developer but was amazed by swift ui so im thinking about a career change 😁
actually swiftui should make you a better uikit developer. swiftui is a wrapper around uikit after all. at the end of the day you will ultimately learn what you need to know to get and hold a job. learning outside of necessity is much harder to do.
Respect to you for doing both, that is really tough. I was challenged enough first time round learning Autolayout for UIKit - that took some time and a few books. And for SwiftUI, autolayout is totally redundant. I was actually annoyed when I started with SwiftUI and realised that all my hard won Autolayout knowledge was useless in this new world. SwiftUI layout is totally different. I think youve been unlucky in the work place: Ive done nothing but SwiftUI for the last 4 years in positions ranging from banks, medical apps and marketplace apps. Its the future, so stick with that, and maybe even think about moving somewhere (when you can) that is doing it fully. Any new or greenfield apps will be.
Thanks Sean we love you
thanks for the advice!
No problem!
I’m still all in on UIKIT. it’s tried and tested (mostly) so as a beginner I know that there won’t be many system errors or hacky work arounds. I imagine SwiftUI to be complete by 2024.
now 2024 bro
That said both can co exist, I use UIKit for drill downs in data, while I use SwiftUI for graphing at the end of the drill down, somewhere between step 4 and 10 of the drill down depending on the depth of data.. Then again I do mainly databases, no games.
My biggest challenge was probably the language Swift. First there was string index before after and offset, then there was ????????? all those optionals and optional chaining and unwrapping. Took me a long time to get used to things.
Thank you Sean! 🙏 I just was in such state) Now I will go on a favourite way - SwftUI!💪
Glad it was helpful!
I can do both, but I prefer UIKit (at least for the base project, individual reusable views are nice in SwiftUI), I am planning to convert a big project completely written in SwiftUI in 2019 into UIKit. The problem with SwiftUI is new features are only compatible with the latest iOS, clients always want support as many as old OSs possible and there are deprecated APIs every year, it's frustrating to maintain.
That’s a good outlook! Never know what info you can find in the comments! Do you feel UIKIT would ever get deprecated?
@@cookednick I definitely find swiftUI easier and I am very comfortable with it. Unfortunately most of my companies legacy apps are in UIKit so I have been focused on that. With swiftUI being a break of fresh air! Cant wait for that switch personally!
So I started my path in iOS development this year, got a full bursary to study for the year so why not. Got a job in August at a really great company in South Africa. Very happy there! So for the past 4 months I had a deep dive into SwiftUI, actually quite comfortable in it. My companies main app are in UIKit and the latest task I’ve received is in UIKit. Not having touched UIKit since my deep dive in SwiftUI has been a cluster f&@k😂… so I found out about programmatic UIKit and have been in a deep rabbit hole today… probably time for the switch working with a team now that is good with storyboards… life of an intern.. atleast I’m enjoying the grind!
Hey @RawRECHO, I am also a South African! I have been trying to get some info on which is used more here in the industry. I know your company would be 1 / 1000, but with you being in the industry and networking, what do you feel is the main option used?
I come from a self-taught web dev background (Just started learning React), and really want to get into the native app scene - as I see there are not as many running around like that of the front end jr applicants. I feel this would be a higher barrier of entry, meaning a little easier to get work.
Would love to know your take.
hi im a student new in iOS Development by joining the Apple Developer Academy. they recommend me to start with SwiftUI, also some said that Apple is migrating from UIKit to SwiftUI. but here in my country, i saw LinkedIn, like all the entry level iOS developer requires UIKit. and it kind of makes sense, because i heard that it is an "expensive" thing for a Company to migrate due to the something called "Code Legacy"...
would you please talk about this or do you already have a video?? thank you. 🙏
Just started learning and doing swiftui only. It is coming very easy and I love it. I have no intention to find a job in this field, just want to make my own apps.
If that's the case, then SwiftUI is 100% the way to go for you! Glad to hear you're enjoying it.
@@seanallen thanks. I’ve been doing web dev for last 20+ years and I’m so burnt out on it. I’m kicking myself in the butt for not trying ios dev earlier.
If you are focused on learning one, as you take notes, you can comment which articles have info on both. That will save you time in the future, if you need fo “switch sides”.
Since WWDC22, a noticeable number of Apple developer docs now reference them both. (Note: not always clearly labeled, and not always included in the same order)
Good point.
Kindly make swiftui calendar view tutorial with adding events functionality
great advice!
Thanks Harold!
I enjoy UIKit more however I want to develop Apple Watch apps too, is it true that I need to know SwiftUI to make any apple watch apps or have widgets? Can I have a UIKit app with a SwiftUI apple watch to go with it (I am a total beginner so its all a bit confusing to me)
Two years ago I learned enough SwiftUI to join a project. Then, a lead dev decided that swiftui's navigation was trash and implemented the navigation in uikit. Then he quit. I am now stuck with an app that is half of everything, not knowing how to properly support it and how to improve further as an ios developer. I should have stayed with react-native...
Why debate. Both are awesome together. Views that aren't super-complex which is at least 50% of my views are SwifUI and the rest are UIKit. Also starting with nearly zero experience in UIKit and a lot of experience in SwiftUI made UIKit so much easier. You are already so used to doing MVVM, state-driven UI, and handling Combine/Concurrency.
Best advice ever. Period
I write UIKit like SwiftUI lol. View models and Combine are magical for readability, testability, and conciseness
can someone help me please ..
i have a SWIFTUI application with a flow as follows: A(landscape orientation)->B(landscape)-C(portrait)->D(portrait). also when I navigate back from C to B it should turn back to landscape as B is in landscape. (I am using NavigationLink in my application to navigate)How do I achieve the portrait lock in swiftUI.
i tried the .onAppear{} and .onDisappear{} method.. (firstly it is no longer available on ios 16 and secondly it gives a choppy animation where the view does not expand fully to take the new rotated screen size; there is white space after it rotates)
Perfect answer
Totally agree. Also true for 2024, in my opinion.
Agreed. This is still my take.
Do you think learning both may be a problem for a seasoned native android developer? I want to start learning native iOS development but really want to invest in what will be used mostly in the future
If you are a seasoned developer and understand imperative vs. declarative programming, I think you will be fine learning both. I said learning both is confusing for beginner developers that are learning how to program for the first time because imperative/declarative are two VERY different ways of thinking.
As a beginner learn UIKit. 95% of the apps are still entirely written using this framework. Some parts might be implemented using SwiftUI and added using UIHostingController, but most UI components are done in UIKit. And you will need to maintain and fix this code. Without a good understanding, you will not be able to do that. We as a community will completely switch to SwiftUI in the best case in ˜5 years.
My current state:
navigation -> Coordinator + UIHostingController
View -> SwiftUI, fallback to UIKit if necessary
I have a question, Allen, Can I add iOS16 widgets into an exsiting UIKit project? Thank you
Yes, you can add widgets to a UIKit app. But Widgets must be written in SwiftUI.
As a Canadian ,most of companies use UIKit but they are some companies use SwiftUI but very few ,and it's impossible to mastering both .what's ur thoughts and suggestions ???
I would go with whichever one you enjoy the most. Like I say in the video, you can make either path work. Do the one you get more enjoyment out of.
Hello Sean and thank you for great content!
As a hired junior iOS developer I have to question your reasoning on this one. I haven't gotten far into learning SwiftUI and I already come across at least two situations where I have to COMBINE, SwiftUI and UIKit to make things work. This means I kinda have to learn both at the same time, as you advice not to.
Examples
1. Using Map from SwiftUI only to realize that MapOptions like "Satellite, Hybrid, ShowTraffic etc.." aren't implemented in SwiftUI. I have to use a UIViewRepresentable and use a MKMapView() instead. Hence I have to learn about MKMapView which is UIKIT.
2. To put those MapOptions in a sheet seemed like a good idea! Let me just do that.... Hmm, seems "presentationDetents" is what I should use. But these are only available in iOS 16! *
Not to worry though, says Apple. You can do this in UIKit instead!**. Hence , I have to learn about UIKit, and put it in the rest of my SwiftUI.
I want to work with SwiftUI. I think its cool. I think its awesome and it works really well. But it feels for me that it is still in early stages. So for me to follow your advice to just go all in on one feels impossible.
Go in on SwiftUI 100% = Sorry, not all things you want to do are possible
Go in on UIKit 100% = Sorry, you cant do programmatic UI as in SwiftUI. Please write this boilerplate.
Go in somewhere in between = Sure thing! Its not gonna be as efficient, but you could do all the things.
What are your thoughts?
This advice is geared towards people just learning iOS development who are still working to find their first job. You said you are hired, so you are further in your journey than who I'm speaking to in this video. If you are making a living as a developer already, then you have the luxury of time to learn both.
@@seanallen Ah, I see. Yeah I thought that I might missed something, and being in the wrong target group would explain. Awesomesauce then I at least know I'm not barking up the wrong tree by learning both at this point in my career. Great to hear from you! Keep up the good work. :)
Hello Sean, I wanted to ask that I have 6 years of experience in UIkit, but I did not learn architecture or any senior dev things in this time. Now my office requirements are to learn any hybrid apps development language like flutter. But I am more into iOS, so I am little confused about it. Because I want to excel in my career too. what steps should I take to be excel. Your reply will be much appreciated. Thank you
Don’t think you can go wrong with flutter. It covers most of the backend functionality for both android and iOS. With the front end being nativity coded in the corresponding programs.. had a chat with one of the intermediate devs at my company! Seems like it saves a lot of time when programming for both platforms!
@@bronsonvdbroeck thanks mate
I've never touched Flutter, so I can't speak to that. But in general, I typically want to work on things that I enjoy and are fun. If I wasn't interested in hybrid app development and my job made me switch to hybrid app development... I would start looking for a new job. But that's just me 🤷♂️
@@seanallen Thanks bro. And what about the knowledge gaps. How should I cover them like CI/CD, Test driven development, Different design patterns like VIPER etc.
Good advice Sean✨ Both Frameworks are Awesome.
SwiftUI makes it easier to focus on the Business logic by making View codebase of the app smaller and easier to organize.
On the other hand developing with UIKit deepens knowledge of Reference semantics, which by its own is a quite useful skill in OOP.
I was quite skeptical when the SwiftUI was firstly introduced, but the last two WWDC-s made it clear that SwiftUI is the future of iOS development and Apple devs are putting tremendous work to fill the functionality gaps between the two frameworks.
I agree. Both paths can work. Pick whichever you enjoy the most, in my opinion.
What they really need to do is make a swift only program that’s more serious than playgrounds and leave Xcode alone. Similar to how they split iTunes up
Coming from Web (React/Nodejs/Typescript) and Flutter (Dart), I'm all in on SwiftUI. SwiftUI will probably go full mainstream in 2024. I'm dedicating 2023 to that goal (complex apps with SwiftUI). This gives Apple plenty of time to polish it and come up with Apple AR glasses (🤞).
Going all in SwiftUI will probably give you a good sense of accomplishment by creating UI rapidly, however not knowing what's happening behind that V/Stack, List, etc will give you trouble to debug when something is not behaving as you expect. Don't get me wrong, I'm not saying SwiftUI has limitations in said components, but pin pointing the bug in a List closure could be hard if you don't know the fundamentals of UITableView/UICollectionView etc.
It's been a little over a year since I started learning iOS, I went all in with SwiftUI but I got to a point where I felt I didn't know what was my super-declarative code actually doing. So I went all in with UIKit from scratch to get solid fundamentals, some months later I got an interview and to be honest I don't think I would've been able to get the job with just SwiftUI knowledge, as all the questions where Swift/UIKit.
Now, I see SwiftUI as a flexible/fast framework which I use for some simple/regular views to save myself boiler code and leave most of the job to iOS to figure out.
This is a balanced take. I like it.
i'm from Flutter going ''to SwiftUI. it's like walk in a park.
I mean if you are a comp science grad with strong background in programming, it is just learning a framework - you can basically learn on the job, and you need to be able to work in multiple code bases and different frameworks all the time
My question, will learning UIKIT help SwiftUI make more sense? My biggest hang-up is mostly dealing with Lifecycle and State management.
I think it can actually confuse you to learn both. They are completely different programming paradigms. UIKit is "imperative" programming while SwiftUI is "reactive". They are two completely different ways of thinking. I think it will confuse you.
Thanks alot for this! Now I now how to start and not pick up both at same time 💜
On spot.
where can i learn swiftui? there is nothing in apples curriculum at all (fundamentals, explorations)
*on it
As a beginner programmer & an Apple fanboy, SwiftUI just feels very Apple, it’s so intuitive
yeah if you are new just learn SWiftUI. By the time you are good at it it will be the norm by then anyway. Just look for work with startups that are using SwiftUI and have no legacy UIKit to bother you unless the company is willing to teach you as UIKit as you work.
Heheheheee.....Well that settles it for me. Shall stick with UIKit for the foreseeable future; after all, some people still work with Fortran.
You'll be more than fine focusing on UIKit
I do both.
However, we know very clear that SwiftUI is the future for iOS, iPadOS, watchOS, macOS development environment.
Personally, building app with declarative syntax is so much better than the imperative way like UIKit(legacy way). UIKit's problems are big redundancy, bad readability, not great for code maintaining at big scale. UIKit is basically Java Swing.
I prefer SwiftUI because it is cleaner, lighter, and faster to build everything. Even for now its customization is less than UIKit, I believe the customization will soon become better than UIKit. Most of UIKit contents are also very old.
Not to mention the new Widget Kit can't be built with UIKit.
Still, using both of these make you feel like you are using completely different language, so if you are an iOS developer, it is better to stick with one a time only, otherwise, you will not catch up every update efficiently.
Well said.
If you want pain and suffering go with SwiftUI, IMO.
why do you say so????
@@asymmetrictechnologies2339 Apple's actually adopting it like crazy as of new OS releases. But it also explains why Ventura and iOS 16 are so buggy. SwiftUI is just not production ready. There are bugs that haven't been fixed in a long time. Don't get me wrong, SwiftUI is way, way better overall. But it's still so young you cannot built anything serious. The ease of building complex layouts and animations so quickly is incredible (instead of suffering with auto layout), but eventually you hit the wall. And then you spend so much time coming up with workarounds because something is bugged in SwiftUI or simply no way of doing it in SwiftUI. Like that one guy on Twitter said, "SwiftUI is death by thousands of paper cuts," after building a simple app.
Yeah. My plan is to completely master SwiftUI and then use UIKit when I need to. Especially as a beginner iOS Dev
That's what I would do as well (if I were a beginner in 2022)
tab vs space battle 😄
The video of a guy who’s tired of the drawn out productions only for the algorithm to decide to randomly suppress the video. Not sure if that’s the case but I love the straight to the point style!
I'm experimenting with different formats, but overall I'm working to cut out as much fluff as possible (even in the longer videos).
The only good reason to learn SwiftUI is if you need Widgets and thats because there is no other way 🤢🤮
I respectfully disagree :)
Downvotes, because you can't have an 2023 opinion in 2022 you clickbaiter.
The same opinion applies. Nothing changed.
@@seanallen Well, the problem was that in 2022 SwiftUI was not feature ready for real world apps (yeah i know hosting back into UIKit is possible) and i tried to find out the change in the 2023. An Apple Programming opinion is only valid until the next WWDC.
Why did you capitalize the word HONEST in the title of this video? Why did you include the word honest at all…? This leads me to believe that you’ve been a dishonest liar in all or your other videos… 🤔 Poor choice of title for this one.
I took a deep dive learning about CZcams title/thumbnail techniques and I'm experimenting with some of that. Did I miss the mark with this one? Maybe. I won't learn anything unless I experiment. I gotta play the CZcams algorithm game to some degree. And that game is all about getting people to click on your videos AND watch a high percentage of them.
@@seanallen Fair enough I guess. I dunno if you can tell who the comments come from - but I’ve been a subscriber for several years and have learned a lot of things from your channel. I’m sure I’m in the minority - but I normally actively avoid any video with a click-bait title (like MUST SEE, or EPIC TAKEDOWN, etc…). It makes me think of the supermarket tabloids. I haven’t seen much of that from you - but the capitalized word “honest” in todays title just jumped out at me - and my reply was mostly in jest while at the same time pointing out what people might think if they actually thought about the title before they clicked on it.
But while I’ve got your ear - here’s a suggestion for a future video that I would personally find useful. How about a video targeting people that have an older app (maybe 2+ years old) that they now want to update to the newest version of Swift - especially if there are any gotchas with pod updates - and how to deal with deprecated features and functions in the simplest way possible. I guess I’d be more specific if I had already tried it - but I haven’t It’s on my near-term todo list.
@@seanallen it’s really too bad that CZcams doesn’t let you specify two different titles - one to display to non-subscribers - and another more accurate, less click-bait-y one to show subscribers so as to not insult their intelligence… 🤔
This would be lovely. I would title videos very differently towards people that already know me vs. those that find me randomly (suggested or search).
This is an interesting idea. I would have to brainstorm how to make this well. It's tough to create a dummy project with old versions of swift, outdated pods, deprecated functions... but this is always a pain in the ass (the updating of an old codebase).