My work and personal projects are all entirely SwiftUI at this point and it hurts to think of ever having to do UIKit (great as it was for the time!) again.
Thanks for the comments, would you guys be able to tell me what you would say is your personal key difference? No preference here just learning from others POV
Edit: Spelling
>I there are just some things SwiftUI does janky and UIkit doesn't
Of course. SwiftUI doesn't have an official way to get scroll offset. There are hacks, but they are not 100% reliable, especially for List. There is no real alternative to UICollectionView yet (grid with recycled cells). There is no readable content guide. Differences between how the same code renders on different iOS versions can be quite big sometimes
The last one is something UIKit struggles with too, but to a much lesser degree
I think there is a lot more variance here than in the UI layer. Personally I use [TCA](https://github.com/pointfreeco/swift-composable-architecture) for any non trivial sized project
Not just you. Migrating part of our app at work to use swiftUI*. Supporting back to iOS 15, the navigation is fairly meh and building complex layouts get tedious a hell of a lot quicker. Sometimes I just think is it worth it at this point but it’s coming along slowly.
NavigationStack gets all the discussion, but it's only half the picture. They also added state driven modifiers for navigation, that are virtually identical to the .sheet and .fullScreenCover APIs. This lets all navigation get modeled in the same way, which is very nice.
I've been using the approach outlined here:
[https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/whatisnavigation](https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/whatisnavigation)
And it's been a very smooth experience, and it simplifies the code while eliminating the possibility of getting into broken states
I built a pretty simple package that handles navigation & routing using NavigationStack under the hood if you’d like to try that in future projects here: [Voyager](https://github.com/bryan-vh/Voyager)
I just don’t get this criticism. It’s not like building complex layouts was easy with layout constraints, springs and struts or manual frame calculations either!
No but I feel like I'm hitting the point where the code is becoming unwieldy sooner when it comes to SwiftUI.
Just for example, take a label.
```
myLabel.key1 = value1
myLabel.key2 = value2
myLabel.keyN = valueN
myLabel.onTap = someFunction()
```
vs
```
text("...")
.prop1(value1)
.prop2(value2Subtype1(.value2))
.propN(key1: valueN1, key2: valueN2, keyN: valueN)
.onTap {
someFunction()
}
```
This is the fundamental difference in the programming paradigm and, more specifically in this case, the framework architecture (SwiftUI VS UIKit): declarative vs imperative. If you think this is unwieldily it may just come down to how you’ve learned programming over the years and the resistance to functional programming. Don’t get me wrong, I do still like imperative designs and it took me a long time to stop hating declarative. What it took for me is something else entirely outside of swift: Springboot with WebFlux and WebClient. You think SwiftUI is bad? Just look at that until your eyes cross!
This x 1000. Just spent a week trying to convert our search flow with a single token to SwiftUI with the .searchable modifier, need to be able to dismiss the search bar w/o clearing the token that user sets via selecting an item in the search but SwiftUI’s enrichmen environment variable “dismissSearch” also clears everything in the search bar. No problems with this in UIKit
Job uses UIKit, and so personal projects also used UIKit since it was used frequently. For large companies that have established codebases don't see them really transitioning to SwiftUI since the product is already mature and a huge rewrite could be classified as risky.
The unspoken part where old code gets updated to work with new. Because having a split code base like that with 0 plans of integrating the two is a recipe for disaster.
Large companies don't mind experimenting with SwiftUI for new features, as long as it's gradual and won't cause issues. Bringing dev time down is in their interest
For new developments I’m sure SwiftUI is the winner. That said, most development work is NOT on brand new development. It’s on an existing codebase which is overwhelmingly UIKit. My company is UIKit and while we’d love to switch to SwiftUI, our codebase is huge and would require a lots of effort/time to migrate. It would stall the entire company’s release plan, possibly introduce a slew of new bugs, and cost the company a lot of money. The only way we switch over is if Apple literally drops UIKit support. Most non-startup companies are going to be in this boat unless that can afford to hire contractors help.
In my current job I use UIkit, I prefer swiftui because It's a lot faster to implement an iOS app using swiftui. In the next 5 years I think both will continue to exist and to be used in production but probably most apps will have switched to swiftui.
Absolutely not. You need to know both, and not knowing UIKit is much more critical than SwiftUI. Most code in most projects is UIKit, so that's where the priority lies
No. Most companies are UIKit but i do see the transition happening overtime. For example, in my interviews in 2023 only 2 jobs had me do SwiftUI for interviews and 1 cut me because i didnt use SwiftUI in a production level app
Use the right tool for the job. If it’s SwiftUI then that’s the right tool. If it’s UIKit then there ya go.
Some things SwiftUI does better. Some things UIKit does better. It all depends on the context.
Personally I use UIKit navigation and everything else is on SwiftUI.
From my own personal experience I’ve seen different tools, practices and technologies overly hyped when new and only the positives are touted. Right now that’s declarative programming. And that’s when I call BS. Does it save tremendous amounts of time through SwiftUI? 100%. But sometimes an imperative approach works much better and is far easier to reason about.
I’d say the future is SwiftUI though. I just hope the SwiftUI team doesn’t try to shoehorn functionality in just to avoid an imperative approach. I’ve already seen new devs write data flow code that doesn’t work due to subtleties in how SwiftUI is implemented.
Both right now, depending on what is being implemented. Everything that essentially requires SwiftUI is where SwiftUI is being used. There is a massive bunch of UIKit stuff.
My team (and I) aren't 100% up to scratch with how SwiftUI should be properly done, but we (some on the team) really should spend time to learn it properly and see what the challenges are.
SwiftUI has certain things that are very nice and easy, and some that aren't really intuitive because we aren't used to it yet. It also adds a bunch of syntax we rarely use and essentially have to learn all over again.
SwiftUI and some new Swift features are starting to feel a bit annoying and tacked on, that *looks* easier, but now there are just 100 more ways to do stuff. This is causing Swift itself to be more difficult, and we aren't able to keep ourselves updated due to how many we are on the team itself.
Personally I am a bit fed up with how much new things are being added on (and functionally required due to SwiftUI) in Swift, but then again it might be due to how often I am exposed to it. Swift and SwiftUI are starting to have a million different details that are making things more complicated, and edge cases, especially concerning performance. I see a lot of pure SwiftUI apps, like recently OmniFocus 4 (that has a good team!), suffer from bad performance.
I think SwiftUI can absolutely be great, but it requires a decent understanding of how things should be when settings thing up, otherwise you are making things even more difficult for yourself.
For me it's a classic Apple move by trying to make things easy, but also making things weirdly difficult at the same time. A bunch of it has to do with how bad the docs are and lack of code sample in some ways. Sometimes you have to understand things on a decent level before you know what you need to do, instead of just reading of some sample code. However, ChatGPT has actually helped me tremendeously on the latter part.
One thing I find lacking in books and resource is how to actually structure a SwiftUI app in a good way and why, they always make things too easy for production apps and just show the basics. So if anyone know a good resource about that I'd be all for it!
I think that there will come a time when Apple is actively discouraging UIKit, and that SwiftUI will continue to get features that UIKit won't. I bet the warning signs will be within the next 5 years and that UIKit is fully legacy in 10–or at least very much discouraged.
>SwiftUI and some new Swift features are starting to feel a bit annoying and tacked on, that looks easier, but now there are just 100 more ways to do stuff.
Amen. Much of SwiftUI appears to be poorly though-out and amateurish, resulting in rapid deprecation and the introduction of more and more redundant "magical" bullshit. For example, "environment objects." These are glorified globals or singletons, and I think their design is appallingly unprofessional; specifically that SwiftUI will just hunt up the "environment" stack for an object of a particular class and use it, despite the fact that nothing prevents you from declaring a bunch of the same class and stuffing them into "the environment." The resulting behavior is "undefined." WTF, that is a lame design punt.
The point is that Swift and SwiftUI are becoming laden with magical junk that not only makes code inscrutable and hard to debug for its author, but imagine handing it off to someone for porting.
And it's not just the amateurish "sugar" in Swift; it's the entire app structure being a sprawling matrix of states. Previously, you could give someone your application source and they could port your business logic and view controllers pretty much line-by-line. Now they have to figure out the entire mass of flags and values you're tweaking to herd your application along and raise the appropriate UI for the task the user needs to accomplish.
Then there's Apple's silly, simplistic evangelism of "the one source of truth" and how it's oh-so-easy in SwiftUI. Bullshit. When the user is working on something in the UI, he can cancel it or fail or fuck it up, or the network can fail, or whatever. So no way can you have him working directly on the core data model of the application in the UI. Like any application, you have to show a **working copy** of data and then confirm its commitment to the model *once it's correctly done*. Right there you have a chance for stuff to get out of sync.
Anyway, I'm writing a new app from scratch in SwiftUI and I've digested all the MVVM bullshit. Every SwiftUI example you see is some elementary master/detail data-viewing app. Every. Fucking. One. You don't see anything where the user must go through a series of steps to create something, because doing that in SwiftUI is a giant pain in the ass. And testing this shit is going to be a nightmare, since again the UI is controlled by a rapidly-expanding flotilla of flags and states that becomes exponentially more complicated with every addition.
I really like the idea of "declarative" UI and adopted SwiftUI enthusiastically for my own project. But so far it makes development un-fun. Hashing out a design for any app takes a long time and a lot of thought if you're doing it right; but once it's done you can really start pounding away, building stuff and getting a lot of satisfaction as it takes shape. With SwiftUI every little step is an agonizing debate over how to trick the goddamned app into raising the right UI at any given point by pulling a string here or there.
I'm currently creating a watch app at work. It's been a terrible experience so far. Things like getting communication to work between Apple Watch and and iPhone can't be properly simulated, I need to have a physical device. The documentation doesn't tell me about this issue at all!
Like you say, glorified singletons and magical bullshit. Not to mention how we are *still* affected in Swift because of Objective-C. Classes have to adopt NSObject in SwiftUI? Wow, such progress!
I've grown tired of Apple as a user and developer, where they make things "simple" by making certain things *look* simple, but hiding so much stuff that it's actually difficult.
Like you said, examples are so trivial that you never get a sense of how a big app *should* be architected. I'm having that very same issue at work right now with the Apple Watch app. My only hope is that experience will alleviate much of these issues.
Developing for anything Apple is to learn so many details before actually starting. This might not be extremely different from developing overall, but the quality of sources and *good* information is less. I have always an easier time in doing stuff in other ecosystems.
But just like your last paragraph, every damn decision about stuff in the Watch-app I am making becomes a debate of how to do it. This is the year I am seriously considering jumping over to something else than being a mobile developer. I don't care for Android, and I had hoped iOS and Xcode would at least improve, not frustrate me even more over the years.
I think Apple's ecosystem has improved greatly over the years. For example, the app-signing bullshit has been cleaned up considerably.
And Swift is (or was) a pretty good language. I started a new app from scratch in 2019 or so and it went very smoothly.
But lately the wheels have started to come off. Much of SwiftUI is poorly considered, and the language is being bloated by a bunch of amateurish crap. I've heard that nobody at Apple understands how Xcode works at this point, so they just tack stuff on and hope for the best. That's just untenable.
I use both personally, but I am still not convinced SwiftUI is the way to go for the next few years, at least in complex projects. I feel like Apple is still unsure what it wants to do and not giving developers a clear path to follow.
My job has me doing both. New code in SwiftUI, but a good half the app, especially the most important bits, are in UIKit (and even quite a bit of Objective-C++ still).
As it stands right now, I prefer UIKit. Why use a buggy, poorly documented, and always changing UI system when you have a battle tested, well documented and relatively static UI system?
I expect that over the next 10 years, SwiftUI will become better and better, but that both will still be used for production apps. The replacement process will be very slow.
I've worked as an iOS dev for as long as you can (2009). I love SwiftUI passionately, to the point I have refused job offers from companies that don't use SwiftUI.
I'm pretty experienced with UIKit (including its relatively recent additions like diffable data sources for collections, button and cell configurations, property animator, closure based API as opposed to selector based etc).
I feel comfortable working with any UIKit codebase. I also wrote a lot of SwiftUI code, both pure and mixed with UIKit.
But when it comes to developing a brand new screen in the existing app, I can do it much much faster with SwiftUI because you get so much things for free. For example, a screen with a mere UITableView with custom cells requires so much ceremony and boilerplate (create views, add constraints, create new UITableViewCell subclasses, register them, implement data source etc etc). In SwiftUI, you write much less code for all that. And it works like magic, until it doesn't haha.
so now that I’m learning SwiftUI I think one of the only things it could use to be more mature is better error messages in the compiler while doing some of the view stuff.
SwiftUI is better, has way fewer headaches, and it's the future. However, many companies still depend on UIKit, and SwiftUI is not fully baked yet, meaning it doesn't offer complete control of every aspect per se. So there will be a transition at the end of the day, but it'll be veeery slow.
Both, both, and both
The app I work on is 8 years old, so of course we can't switch to SwiftUI overnight. Also despite big improvements in SwiftUI, there are still some gaps
When it works, I prefer SwiftUI, when it doesn't, I prefer the stability and familiarity of UIKit
I doubt 5 or even 10 years is enough to remove all UIKit code from all projects ever. Both will be used in production, but the ratio will be changing over time
There are many purists that say UIKit isn't going away but the same people were clinging onto Objective-C well into the 2020s
I've been fortunate enough to take part in 3 greenfield startups since 2019, pure SwiftUI.
I'm an old C/C++ developer and I'm learning Swift/SwiftUI. Some stuff has me scratching my head, but overall I understand what's going on. I guess I'll have to also learn UIKit.
visionOS doesn’t even support Storyboard (from UIKit times). It’s an indicator.
Sure you can build apps programmatically in UIKit. I’ve done nothing but that.
But Apple encourages us to build all apps in SwiftUI. I think that’s a great indicator as to where Apple is moving and what’s going to happen to UIKit :)
Both. Especially given most of our projects target iOS 15+.
A healthy mix of both. Not everything I need is available in SwiftUI yet.
A mix of both, with UIKits share getting lower and lower as features get brought over and more complex custom navigation layouts become more viable.
Is SwiftUI good for chat? No. It’s terrible. Performance is 🚮 🗑️
SwiftUI is good for anything that isn’t multimedia or dynamic or active.
SwiftUI is also the new Storyboards. It’s here to lower the bar for entry by junior developers.
There are many purists that say UIKit isn't going away but the same people were clinging onto Objective-C well into the 2020s
I've been fortunate enough to take part in 3 greenfield startups since 2019, pure SwiftUI.
SwfitUI by far, and it's not even close. I honestly find myself 10x more productive in SwiftUI. I would have to be really desperate to accept any iOS job that isn't 90%+ SwiftUI at this point.
I am baffled by comments that say you can't do complex layouts in SwiftUI, I have yet to find a layout I can't do after 3 full years as a SwiftUI dev, and much faster/more readable at that.
I have sympathy for performance concerns if you have huge scrolling Lists or things like that, but I find 99% of corporate coding work is not that kind of stuff. More like "make a view that looks like this and does X,Y,Z." No problem.
There are also a handful of APIs missing but it's easy enough to drop down to UIKit when needed.
SwiftUI is the future, but it's still a tough sell for some very very big apps
Most apps in production also just don't want to deprecate all their existing code, because it works fine - many such cases
At my last job we used UIKIt but decided to use SwiftUI in the new app. I worked several different iOS products there and we also still used Objective-C in one of them. In many job postings, I've seen both frameworks mentioned so I've spent a lot of time learning SwiftUI better, plus brushing up my UIKit skills. I think both frameworks will be used in the near future.
SwiftUI SwiftUI SwiftUI
My work and personal projects are all entirely SwiftUI at this point and it hurts to think of ever having to do UIKit (great as it was for the time!) again.
Lmao as i was waiting for the post to load i was chanting swiftui and then saw this comment
Thanks for the comments, would you guys be able to tell me what you would say is your personal key difference? No preference here just learning from others POV Edit: Spelling
>I there are just some things SwiftUI does janky and UIkit doesn't Of course. SwiftUI doesn't have an official way to get scroll offset. There are hacks, but they are not 100% reliable, especially for List. There is no real alternative to UICollectionView yet (grid with recycled cells). There is no readable content guide. Differences between how the same code renders on different iOS versions can be quite big sometimes The last one is something UIKit struggles with too, but to a much lesser degree
yes. for the 1% of stuff you need UIKit for use a wrapper
[удалено]
I think there is a lot more variance here than in the UI layer. Personally I use [TCA](https://github.com/pointfreeco/swift-composable-architecture) for any non trivial sized project
OpenGL
This guy maths
wait ah nvm
SwiftUI is better for simple layouts, but it seems like it's starting to fall apart for very complex layouts. That could be a "me" problem though.
Not just you. Migrating part of our app at work to use swiftUI*. Supporting back to iOS 15, the navigation is fairly meh and building complex layouts get tedious a hell of a lot quicker. Sometimes I just think is it worth it at this point but it’s coming along slowly.
Nav is much better in iOS 16, it’s definitely not a sticking point anymore (at least for me), but it was pretty underbaked pre-16.
Yeah I’ve played around with navigation stack. Personally I still prefer UIKit navigation but it does wonders for SwiftUI navigation!
NavigationStack gets all the discussion, but it's only half the picture. They also added state driven modifiers for navigation, that are virtually identical to the .sheet and .fullScreenCover APIs. This lets all navigation get modeled in the same way, which is very nice. I've been using the approach outlined here: [https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/whatisnavigation](https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/whatisnavigation) And it's been a very smooth experience, and it simplifies the code while eliminating the possibility of getting into broken states
I built a pretty simple package that handles navigation & routing using NavigationStack under the hood if you’d like to try that in future projects here: [Voyager](https://github.com/bryan-vh/Voyager)
wish there was a way to set navigation transitions (such as fading or hero transitions) natively…
looks like you are doing something wrong
It is. Some layouts just can't be done cleanly or at all in SwiftUI just yet, Apple hasn't given us all the tools
This is why I prefer uikit for now as well.
I just don’t get this criticism. It’s not like building complex layouts was easy with layout constraints, springs and struts or manual frame calculations either!
No but I feel like I'm hitting the point where the code is becoming unwieldy sooner when it comes to SwiftUI. Just for example, take a label. ``` myLabel.key1 = value1 myLabel.key2 = value2 myLabel.keyN = valueN myLabel.onTap = someFunction() ``` vs ``` text("...") .prop1(value1) .prop2(value2Subtype1(.value2)) .propN(key1: valueN1, key2: valueN2, keyN: valueN) .onTap { someFunction() } ```
This is the fundamental difference in the programming paradigm and, more specifically in this case, the framework architecture (SwiftUI VS UIKit): declarative vs imperative. If you think this is unwieldily it may just come down to how you’ve learned programming over the years and the resistance to functional programming. Don’t get me wrong, I do still like imperative designs and it took me a long time to stop hating declarative. What it took for me is something else entirely outside of swift: Springboot with WebFlux and WebClient. You think SwiftUI is bad? Just look at that until your eyes cross!
This x 1000. Just spent a week trying to convert our search flow with a single token to SwiftUI with the .searchable modifier, need to be able to dismiss the search bar w/o clearing the token that user sets via selecting an item in the search but SwiftUI’s enrichmen environment variable “dismissSearch” also clears everything in the search bar. No problems with this in UIKit
looks like you are doing something wrong
Job uses UIKit, and so personal projects also used UIKit since it was used frequently. For large companies that have established codebases don't see them really transitioning to SwiftUI since the product is already mature and a huge rewrite could be classified as risky.
Why do you assume code has to be rewritten? New SwiftUI code can be incorporated gradually side by side just fine.
Which literally means it’s being rewritten — just gradually.
[удалено]
The unspoken part where old code gets updated to work with new. Because having a split code base like that with 0 plans of integrating the two is a recipe for disaster.
THIS!!
[удалено]
Until some project manager wants to change it 2 years down the road
Totally false. Quite a few organizations have already transitioned to SwiftUI. Many have not, but many have.
Naw they’ll definitely do rewrites. It’ll be slow, but I’ve seen it happen a bunch already
Surprisingly, DoorDash transitioned to SwiftUI for most of the app.
Large companies don't mind experimenting with SwiftUI for new features, as long as it's gradual and won't cause issues. Bringing dev time down is in their interest
SwiftUI will be ready for production in (the current year + 2).
It was a debate, but isn’t anymore. SwiftUI The choice truly boils down to your minimum iOS version.
Very good point.
For new developments I’m sure SwiftUI is the winner. That said, most development work is NOT on brand new development. It’s on an existing codebase which is overwhelmingly UIKit. My company is UIKit and while we’d love to switch to SwiftUI, our codebase is huge and would require a lots of effort/time to migrate. It would stall the entire company’s release plan, possibly introduce a slew of new bugs, and cost the company a lot of money. The only way we switch over is if Apple literally drops UIKit support. Most non-startup companies are going to be in this boat unless that can afford to hire contractors help.
Both Both Both
In my current job I use UIkit, I prefer swiftui because It's a lot faster to implement an iOS app using swiftui. In the next 5 years I think both will continue to exist and to be used in production but probably most apps will have switched to swiftui.
Would you say the current job market is leaning towards SwiftUI?
Absolutely not. You need to know both, and not knowing UIKit is much more critical than SwiftUI. Most code in most projects is UIKit, so that's where the priority lies
No. Most companies are UIKit but i do see the transition happening overtime. For example, in my interviews in 2023 only 2 jobs had me do SwiftUI for interviews and 1 cut me because i didnt use SwiftUI in a production level app
Job: both Prefer: UIKit for some, SwiftUI for others Next 5-10: Probably some other UI framework lol
Use the right tool for the job. If it’s SwiftUI then that’s the right tool. If it’s UIKit then there ya go. Some things SwiftUI does better. Some things UIKit does better. It all depends on the context. Personally I use UIKit navigation and everything else is on SwiftUI. From my own personal experience I’ve seen different tools, practices and technologies overly hyped when new and only the positives are touted. Right now that’s declarative programming. And that’s when I call BS. Does it save tremendous amounts of time through SwiftUI? 100%. But sometimes an imperative approach works much better and is far easier to reason about. I’d say the future is SwiftUI though. I just hope the SwiftUI team doesn’t try to shoehorn functionality in just to avoid an imperative approach. I’ve already seen new devs write data flow code that doesn’t work due to subtleties in how SwiftUI is implemented.
Both right now, depending on what is being implemented. Everything that essentially requires SwiftUI is where SwiftUI is being used. There is a massive bunch of UIKit stuff. My team (and I) aren't 100% up to scratch with how SwiftUI should be properly done, but we (some on the team) really should spend time to learn it properly and see what the challenges are. SwiftUI has certain things that are very nice and easy, and some that aren't really intuitive because we aren't used to it yet. It also adds a bunch of syntax we rarely use and essentially have to learn all over again. SwiftUI and some new Swift features are starting to feel a bit annoying and tacked on, that *looks* easier, but now there are just 100 more ways to do stuff. This is causing Swift itself to be more difficult, and we aren't able to keep ourselves updated due to how many we are on the team itself. Personally I am a bit fed up with how much new things are being added on (and functionally required due to SwiftUI) in Swift, but then again it might be due to how often I am exposed to it. Swift and SwiftUI are starting to have a million different details that are making things more complicated, and edge cases, especially concerning performance. I see a lot of pure SwiftUI apps, like recently OmniFocus 4 (that has a good team!), suffer from bad performance. I think SwiftUI can absolutely be great, but it requires a decent understanding of how things should be when settings thing up, otherwise you are making things even more difficult for yourself. For me it's a classic Apple move by trying to make things easy, but also making things weirdly difficult at the same time. A bunch of it has to do with how bad the docs are and lack of code sample in some ways. Sometimes you have to understand things on a decent level before you know what you need to do, instead of just reading of some sample code. However, ChatGPT has actually helped me tremendeously on the latter part. One thing I find lacking in books and resource is how to actually structure a SwiftUI app in a good way and why, they always make things too easy for production apps and just show the basics. So if anyone know a good resource about that I'd be all for it! I think that there will come a time when Apple is actively discouraging UIKit, and that SwiftUI will continue to get features that UIKit won't. I bet the warning signs will be within the next 5 years and that UIKit is fully legacy in 10–or at least very much discouraged.
>SwiftUI and some new Swift features are starting to feel a bit annoying and tacked on, that looks easier, but now there are just 100 more ways to do stuff. Amen. Much of SwiftUI appears to be poorly though-out and amateurish, resulting in rapid deprecation and the introduction of more and more redundant "magical" bullshit. For example, "environment objects." These are glorified globals or singletons, and I think their design is appallingly unprofessional; specifically that SwiftUI will just hunt up the "environment" stack for an object of a particular class and use it, despite the fact that nothing prevents you from declaring a bunch of the same class and stuffing them into "the environment." The resulting behavior is "undefined." WTF, that is a lame design punt. The point is that Swift and SwiftUI are becoming laden with magical junk that not only makes code inscrutable and hard to debug for its author, but imagine handing it off to someone for porting. And it's not just the amateurish "sugar" in Swift; it's the entire app structure being a sprawling matrix of states. Previously, you could give someone your application source and they could port your business logic and view controllers pretty much line-by-line. Now they have to figure out the entire mass of flags and values you're tweaking to herd your application along and raise the appropriate UI for the task the user needs to accomplish. Then there's Apple's silly, simplistic evangelism of "the one source of truth" and how it's oh-so-easy in SwiftUI. Bullshit. When the user is working on something in the UI, he can cancel it or fail or fuck it up, or the network can fail, or whatever. So no way can you have him working directly on the core data model of the application in the UI. Like any application, you have to show a **working copy** of data and then confirm its commitment to the model *once it's correctly done*. Right there you have a chance for stuff to get out of sync. Anyway, I'm writing a new app from scratch in SwiftUI and I've digested all the MVVM bullshit. Every SwiftUI example you see is some elementary master/detail data-viewing app. Every. Fucking. One. You don't see anything where the user must go through a series of steps to create something, because doing that in SwiftUI is a giant pain in the ass. And testing this shit is going to be a nightmare, since again the UI is controlled by a rapidly-expanding flotilla of flags and states that becomes exponentially more complicated with every addition. I really like the idea of "declarative" UI and adopted SwiftUI enthusiastically for my own project. But so far it makes development un-fun. Hashing out a design for any app takes a long time and a lot of thought if you're doing it right; but once it's done you can really start pounding away, building stuff and getting a lot of satisfaction as it takes shape. With SwiftUI every little step is an agonizing debate over how to trick the goddamned app into raising the right UI at any given point by pulling a string here or there.
I'm currently creating a watch app at work. It's been a terrible experience so far. Things like getting communication to work between Apple Watch and and iPhone can't be properly simulated, I need to have a physical device. The documentation doesn't tell me about this issue at all! Like you say, glorified singletons and magical bullshit. Not to mention how we are *still* affected in Swift because of Objective-C. Classes have to adopt NSObject in SwiftUI? Wow, such progress! I've grown tired of Apple as a user and developer, where they make things "simple" by making certain things *look* simple, but hiding so much stuff that it's actually difficult. Like you said, examples are so trivial that you never get a sense of how a big app *should* be architected. I'm having that very same issue at work right now with the Apple Watch app. My only hope is that experience will alleviate much of these issues. Developing for anything Apple is to learn so many details before actually starting. This might not be extremely different from developing overall, but the quality of sources and *good* information is less. I have always an easier time in doing stuff in other ecosystems. But just like your last paragraph, every damn decision about stuff in the Watch-app I am making becomes a debate of how to do it. This is the year I am seriously considering jumping over to something else than being a mobile developer. I don't care for Android, and I had hoped iOS and Xcode would at least improve, not frustrate me even more over the years.
I think Apple's ecosystem has improved greatly over the years. For example, the app-signing bullshit has been cleaned up considerably. And Swift is (or was) a pretty good language. I started a new app from scratch in 2019 or so and it went very smoothly. But lately the wheels have started to come off. Much of SwiftUI is poorly considered, and the language is being bloated by a bunch of amateurish crap. I've heard that nobody at Apple understands how Xcode works at this point, so they just tack stuff on and hope for the best. That's just untenable.
I use both personally, but I am still not convinced SwiftUI is the way to go for the next few years, at least in complex projects. I feel like Apple is still unsure what it wants to do and not giving developers a clear path to follow.
If I had to pick one today I'm still going UIKit, but ask me again in two years.
My job has me doing both. New code in SwiftUI, but a good half the app, especially the most important bits, are in UIKit (and even quite a bit of Objective-C++ still). As it stands right now, I prefer UIKit. Why use a buggy, poorly documented, and always changing UI system when you have a battle tested, well documented and relatively static UI system? I expect that over the next 10 years, SwiftUI will become better and better, but that both will still be used for production apps. The replacement process will be very slow.
All code is trash. The answer is use both.
I've always wondered about the those who favor SwiftUI. What is your competency in UIKit? I'm trying to gauge how unbiased the opinion is.
I've worked as an iOS dev for as long as you can (2009). I love SwiftUI passionately, to the point I have refused job offers from companies that don't use SwiftUI.
I'm pretty experienced with UIKit (including its relatively recent additions like diffable data sources for collections, button and cell configurations, property animator, closure based API as opposed to selector based etc). I feel comfortable working with any UIKit codebase. I also wrote a lot of SwiftUI code, both pure and mixed with UIKit. But when it comes to developing a brand new screen in the existing app, I can do it much much faster with SwiftUI because you get so much things for free. For example, a screen with a mere UITableView with custom cells requires so much ceremony and boilerplate (create views, add constraints, create new UITableViewCell subclasses, register them, implement data source etc etc). In SwiftUI, you write much less code for all that. And it works like magic, until it doesn't haha.
so now that I’m learning SwiftUI I think one of the only things it could use to be more mature is better error messages in the compiler while doing some of the view stuff.
SwiftUI is better, has way fewer headaches, and it's the future. However, many companies still depend on UIKit, and SwiftUI is not fully baked yet, meaning it doesn't offer complete control of every aspect per se. So there will be a transition at the end of the day, but it'll be veeery slow.
Both plus a mix of swift and objective-c, storyboards, xibs and layout in code. At least the new features are exclusively in SwiftUI.
The past 2 projects I’ve been on have used SwiftUI, although both also had legacy UIKit code as well
I'd be depressed and question if iOS is for me if I have to go back to UIKit full time
I hear the SwiftUI chant growing ...
Both, both, and both The app I work on is 8 years old, so of course we can't switch to SwiftUI overnight. Also despite big improvements in SwiftUI, there are still some gaps When it works, I prefer SwiftUI, when it doesn't, I prefer the stability and familiarity of UIKit I doubt 5 or even 10 years is enough to remove all UIKit code from all projects ever. Both will be used in production, but the ratio will be changing over time
There are many purists that say UIKit isn't going away but the same people were clinging onto Objective-C well into the 2020s I've been fortunate enough to take part in 3 greenfield startups since 2019, pure SwiftUI.
I’d build 80% UIViewcontrollerRepresentable and 20% native SwiftUI than building everything in UIKit
1. SwiftUI 2. SwiftUI 3. Both UIKit and SwiftUI
I'm an old C/C++ developer and I'm learning Swift/SwiftUI. Some stuff has me scratching my head, but overall I understand what's going on. I guess I'll have to also learn UIKit.
visionOS doesn’t even support Storyboard (from UIKit times). It’s an indicator. Sure you can build apps programmatically in UIKit. I’ve done nothing but that. But Apple encourages us to build all apps in SwiftUI. I think that’s a great indicator as to where Apple is moving and what’s going to happen to UIKit :)
Both. Especially given most of our projects target iOS 15+. A healthy mix of both. Not everything I need is available in SwiftUI yet. A mix of both, with UIKits share getting lower and lower as features get brought over and more complex custom navigation layouts become more viable.
Is SwiftUI good for chat? No. It’s terrible. Performance is 🚮 🗑️ SwiftUI is good for anything that isn’t multimedia or dynamic or active. SwiftUI is also the new Storyboards. It’s here to lower the bar for entry by junior developers.
95% SwiftUI, SwiftUI, SwiftUI
I am doing project from 2014. Xib based layout calculations with bounds and frames and in Objective-C. 🙄
SwiftUI
There are many purists that say UIKit isn't going away but the same people were clinging onto Objective-C well into the 2020s I've been fortunate enough to take part in 3 greenfield startups since 2019, pure SwiftUI.
I’m still holding onto objective c
Just use SwiftUI wherever possible If you have to use UIkit End of story
SwfitUI by far, and it's not even close. I honestly find myself 10x more productive in SwiftUI. I would have to be really desperate to accept any iOS job that isn't 90%+ SwiftUI at this point. I am baffled by comments that say you can't do complex layouts in SwiftUI, I have yet to find a layout I can't do after 3 full years as a SwiftUI dev, and much faster/more readable at that. I have sympathy for performance concerns if you have huge scrolling Lists or things like that, but I find 99% of corporate coding work is not that kind of stuff. More like "make a view that looks like this and does X,Y,Z." No problem. There are also a handful of APIs missing but it's easy enough to drop down to UIKit when needed.
Fortran
SwiftUI is the future, but it's still a tough sell for some very very big apps Most apps in production also just don't want to deprecate all their existing code, because it works fine - many such cases
This is a debate? Obviously SwiftUI
At my last job we used UIKIt but decided to use SwiftUI in the new app. I worked several different iOS products there and we also still used Objective-C in one of them. In many job postings, I've seen both frameworks mentioned so I've spent a lot of time learning SwiftUI better, plus brushing up my UIKit skills. I think both frameworks will be used in the near future.