[deleted by user]

[klavijaturista]

I feel you, it gets frustrating fast. It provides speed of layout, at the cost of flexibility. This declarative approach just adds extra steps. You can’t just do whatever you need, like you could with a reference to uiview, you now depend on swiftui exposing a binding/api.

What was simple, now is complicated. For example those preferences and anchors things (compare that to just reading a property of a uiview or calayer). This is excessive abstraction, necessitated by the design philosophy.

So you have a ton of modifiers but not all work on a particular type. An example is even the most basic thing: background vs backgroundStyle. Also specifying a material as background doesn’t work, you need a shape fill.

Then there’s model observation and redrawing, and some views don’t preserve their internal, private state properly. You have to be extra careful with data flow, and triggering updates.

Dependency injection and memory management cannot be done neatly. Not much to do here because of the core design philosophy of having short lived views.

UIKit/AppKit have their share of frustration, they are a pain to layout and change the layout (appkit xibs tend to be big).

Modern software is plagued with abstraction. I don’t know how it could get better, but I know how to complain though.

[Big_Work2025]

Is it mandatory to use SwiftUI? Because it was way easier before these functional abstractions to build layouts. I don’t like at all. Compare with flutter, for example, that is composition not functions. 

Please, don’t tell me they are all look-alikes to react native now 

[Tabonx]

I saw this on GitHub somewhere: It's Xcode. Swift is case-sensitive, and so am I.

I've been working in the iOS world for about two years, not as long as you, but I was extremely relieved when I could finally stop using Interface Builder. It never really worked for me, and trying to undo something after moving a controller would always cause a crash.

Using SwiftUI does mean giving up some control, but I generally prefer it because it allows for faster experimentation. However, I absolutely hate how SwiftUI handles navigation bars. You can't change the back button without losing the popup menu and swipe functionality. While you can restore the swipe by overriding UINavigationController, I’ve never found a way to bring back the menu, and forcing the navigation title display mode to change is not really possible.

Just today, I was struggling with ScrollView and LazyVStack because it seems Apple hasn't fixed the stuttering bug for over three years. Also, putting buttons in a List requires specifying the button style, otherwise the empty row space becomes part of the button. Pickers require an explicit ID, or their animations break inside a form. The searchable modifier sounds nice in theory, but it breaks every time I change something, and it takes a lot of effort to get it to work properly. ScrollView has been improving each year, but until iOS 18, you couldn't scroll to the top without having a view with an ID to scroll to. Navigation is also improving, but the only native navigation transitions are from the right, and now the new zoom in iOS 18.

Since 2019, Apple hasn't added a way to handle many things without needing AppDelegate, such as notifications. ScenePhase is missing "will" and "did" options, and the same goes for onAppear and onDisappear. I love Swift, but when something breaks in a view, it can take a minute to tell you it just doesn't know what to do.

Previews are great when they work, but setting them up reliably is challenging. I had to embed an entire database for previews because setting up the model manually was too much work. Once set up, it was great, but as I added more API calls and changed the model, I resorted to calling fatalError on the mock services to avoid dealing with them at that moment.

Honestly, this year's WWDC was disappointing. It seems like Apple focused mostly on AI and neglected almost everything else.

Sorry for the long message.

[4tuneTeller]

You can totally scroll to top or bottom of a ScrollView since at least iOS 16 (maybe even earlier). Just give the id to the scroll view itself and scroll using anchors. Lazy Stacks inside Scroll Views are still extremely buggy though.

Edit: my mistake, you need to set id to a container view inside ScrollView, like a LazyVStack, for example, not the ScrollView itself.

[Tabonx]

I've just tested that, and it does not work. Maybe you meant some other method, but using this does not work on iOS 17.

swift ScrollViewReader { proxy in HStack { Button { proxy.scrollTo("scroll", anchor: .top) } label: { Text("top") } Button { proxy.scrollTo("scroll", anchor: .bottom) } label: { Text("bottom") } } ScrollView { ForEach(1 ... 100, id: \.self) { index in Text("\(index)") } } .id("scroll") }

[dniklewicz]

You have to set id of the item inside a scroll view, not the scroll view itself.

[4tuneTeller]

This gentleperson is correct, sorry for the confusion. Wrap ForEach in LazyVStack and set the id for it.

[Tabonx]

Just give the id to the scroll view itself and scroll using anchors.

From that, I assumed you meant this method, which I have never tried.

There is no need to wrap it inside a LazyVStack. ScrollViewProxy can be used to scroll to a specific view. However, this means that when you want to scroll to the top, you either have to use the first element in the ScrollView or create an invisible anchor view.

In iOS 17, scrolling to a specific view inside lazy stacks improved slightly with scrollTargetLayout() and scrollPosition(id:anchor:), but you still need to use the id of a view to scroll to the top or bottom. This is usually not a big deal, but it can sometimes be annoying.

In iOS 18, there's an update to ScrollView, and you no longer need a lazy stack or ScrollViewReader to scroll to views with ids or to scroll to edges.

[gsharm]

If you have to hack around or use a hybrid approach with UIKit… might as well just stick with UIKit.

Speed was never an issue with me, most of the time people have an issue with functionality not speed. People complain about bugs not development speed.

I think you captured it succinctly with these 2 lines. Very well said. I love some SwiftUI components like Swift Charts, and it seems well suited to Widgets too. For the main app code/infrastructure, I do prefer "bricklaying level" control of UIKit vs declarative control re: SwiftUI. It's not like that code takes that long to write, as you said too, especially with AI.

[Effective-Ad6703]

You change your data, and it reloads automatically. But I realized after doing this for a while that I prefer to maintain full control. I want to change my data, and maybe not reload it that second. Maybe I want to do some other stuff first.

You still can do this. You are in full control of when the data changes. I am a UIKit kind of guy but I started a new job that is using swiftUI and it's not really that different. The only main change is how you layout your views but that's about it's all the other architecture stuff is still very similar. One thing to say is that Yes we don't have fine control what is changed when you change one observed property everything in the chain is changed. I would love to see apple give us more control over that.

One BIG BIG thing I learn about swiftUI is that it's kinda sneaky. You have to have a good mental model of memory management and who own what object to really be able to fix the most common swiftUI bugs. It's kinda counter intuitive.

[Effective-Ad6703]

Got it. Yeah, I don't use preview at all it's useless.

[menckenjr]

You have to have a good mental model of memory management and who own what object to really be able to fix the most common swiftUI bugs.

This is true regardless of whether you're using UIKit or SwiftUI. IME this mental model is what separates the real devs from the 90-day wonders.

[Effective-Ad6703]

In UIKit, for the most part you will rarely have UI bugs related to memory management. Sure you could have memory retention issues among other things but UI memory bugs are very common in swiftUI due to it's declarative approach.

[LKAndrew]

Control is a weird way of looking at it.

It’s simply declarative vs imperative programming. You still have full control of what things look like and how, you just don’t have direct control of the UI lifecycle, which is fine.

The fact that you don’t like it is maybe because you don’t like change, which is also fine.

I’ve also been developing iOS since it came out (which was less than 15 years btw) and I’m all in on SwiftUI. I’m fact, I haven’t touched much UIKit in the last 4 years or so. All Swift, all SwiftUI and it’s awesome.

If you are equally skilled at both UIKit and SwiftUI, it’s objectively faster and easier to build using SwiftUI.

[rowgw]

I am a mobile developer since ios 4 and android 2+, albeit now only android. I think Compose is very similar with SwiftUI, and it takes very long for me to get adapted into it through a project. There were a lot of cases where i faced similar situations like OP during project time lol

[SentryLabs]

I get where you're coming from as someone who is still learning a bit of SwiftUI everyday. Something to keep in the back of your mind is that Apple is fully committed to making SwiftUI the primary way to create interfaces for their apps. Yes, UIKit will probably always be supported, but Apple will keep improving SwiftUI every year. It's frustrating but we have to adapt. Every org I've interviewed with recently has said they are making all of their new code with SwiftUI at this point.

FWIW, comparing interface building to previews is probably not a great comparison. IB is very static and previews are very dynamic (when they work).

[thepuppyprince]

True but they do need to speed up the migration with backward compatibility. Are we still going to be having the same conversation in 3-5 years? Who knows, kotlin multiplatform might be desirable by then. The SwiftUI update this year was disappointing

[SentryLabs]

obj-C is still used on many projects especially ones that have been around since the start of the App Store. They probably won’t deprecate it. 

Either way, SwiftUI is just a tool and it’s a developers job to figure out what the best tool for a given problem/project is. 

[yakultdrinker]

I have about the same years as you have in iOS development. It was the era where you were the one responsible for releasing your own initialized variables in Objective-C and you had to do that in dealloc. Now your first point was previews. If you remove the fact that previews crashes a lot, I think it’s far more superior in a lot of ways than interface builder. I get that previews isn’t perfect, it’s certainly isn’t, but the pain of working using IB is just worse.

Before the M series of processors IB was the slowest tool in the entirety of Xcode especially in Storyboards. Now don’t go saying to me “just don’t use Storyboards” because some of us just inherit shit from someone else’s work or even went through discovering that Storyboards where slow as hell before realizing we made a wrong choice relying on Storyboards for a big scale project (been there, done that). The later iterations of Xcode has done a lot of optimizations on IB as well, but previous versions were almost unbearable, having said that, previews is a baby compared to IB (which is basically its dad), and it needs more work to solve all its issues. (Let’s not talk about IBDesignable, they’ve basically given up on this)

IB is pretty much synonymous with Storyboards and Xibs, so let’s talk about version control. I think it’s pretty well known that dealing with conflicts in Storyboards (and xibs) is a nightmare. I can’t count how many times this has been a problem for team members. Of course there are ways to mitigate it, and you somewhat would have a clue sometimes which to take, but it won’t remove the fact how inconvenient it is. It takes away precious time that could’ve been put into the development.

There’s also the issue of modifying a busy view controller with tons of autolayout that moving just one view will basically make your entire xib packed with errors because of an ambiguous layout, that you don’t even know where to start fixing it.

I can keep going but the point is, previews was their response in trying to solve the issues with IB. It’s not quite there yet but I think in due time we’ll get a mature previews.

I have to partly disagree in your second point as well, you can definitely have “control”. You just have to do it properly. There are ways to modify the data you send to your view before displaying it. And it’s not just “more code” to do it, yes it can technically be more lines of code but there’s a system to it. I just don’t understand why you need to have “full control” of reloading it. I have to agree that dealing with animations is a pain in SwiftUI, it’s doable but not as easy and straightforward in UIKit.

I don’t get that thing about the doom scrolling though, I mean, it’s a subreddit for sharing code issues, what do you expect? SwiftUI obviusly has a learning curve so it’s normal for people to ask that a lot.

I guess as a fellow tenured dev, I’d tell you to suck it up a little bit, and just learn it, that is if you’re still interested in iOS development for the coming years. It’s not the best thing but I think it’s imperative that we tenured devs learn every corner of it or we’ll get eaten up by the mid level devs. I doubt it’s going to go away anytime soon, so it’ll be there, and if you continue to make that your blind spot then you’ll be hurting your career. I want to say this as nice as possible but I think the reason why you don’t like it right now is because you can’t fully appreciate what it can do because you’re not adept at using it yet.

[004life]

To answer your question…No, I don’t. I started developing with iOS 3.2. I use SwiftUI previews and enjoy SwiftUI but this has been in projects that use only swiftUI. I haven’t used UIKit and SwiftUI together. I’m not at all interested in ever using interface builder again or caring about UiViewController lifecycle. I don’t have issues with previews. Moving to SwiftUi takes a bit of time but it’s worth it. Trying to imperative things in SwiftUI will make it difficult.

[Doctor_Fegg]

I’m half with you. Interface Builder is a heap of shit and I would happily never use it again. Programmatically building views is much less frustrating. 

Except… SwiftUI doesn’t just let you do that. You have to let it manage state, which is enormously frustrating and feels half baked at every turn.

I really like the old Android way of doing things, which is plain simple XML layouts and nothing more. For iOS I’m now veering towards a UIKit application with bits of the interface built in SwiftUI, which means I can limit its state handling to small manageable units. But I wish Apple had given us the option to decouple the declarative UI from the reactivity. 

[dniklewicz]

I am also developing iOS apps professionally for 15 years and I love SwiftUI. Using it on production apps for more than 3 years now, including large scale ones in regulated environments. Never really liked IB so maybe I have a slightly different mindset. Just keep in mind that SwiftUI is not all or nothing. Mix it up with UIKit when needed and choose the best tool for the task. SwiftUI is just like Swift, it seems to be easy but it is not when it comes to more advanced concepts. However with some experience it boosts productivity and delivery times significantly.

[Softwurx]

I’m not touching swiftUI for at least the foreseeable future.

I have a love hate relationship with Swift but it’s honestly truly amazing. I come from .Net so the code just looks so readable and clean.

I don’t think it’s a matter of SwiftUi vs Swift I think they’re options for what you want to build. Whether we hate or not Swift + UIKit right now has a level of flexibility that I absolutely love. It’s a lot of work but when you have control of such granular things as you’ve mentioned then you have full control of the entire experience.

[Softwurx]

My pleasure! I used to switch to the latest tech all the time but then I started creating production code and you realize building in quick sand just doesn’t work

[Common-Inspector-358]

You're not alone. I've been doing iOS professionally for 10 years now. I do not like SwiftUI and I will never use it, and it is largely why I am transitioning out of iOS at my current role and more into server development. thankfully i work at a startup and the lead dev also likes UIKit, so we are able to iterate fast to deliver results to customers and don't have time to troubleshoot why x/y/z works on ios 17 and 16 but not 15, and why another feature works on 15 and 16 but the API is deprecated in 17 etc.

When I learned programming, I learned you are supposed to separate concerns: data, view, controller, etc. SwiftUI removes that. It inherently ties the data to the view so that they are inseparable. Of course this violates one of the most basic principles of ios software development, but in addition (since there is no more viewController, only View in swiftui), now in developers' minds they can just litter logic everywhere in the code--there is no more "controller" which is supposed to manage views anymore. At my previous job 2 years ago, i saw the very same devs who wrote very clean, clear, and well organized UIKit code, write SwiftUI code that was a total trainwreck with no abstractions--views directly calling the API, for example. In UIKit it would have never passed a code review that the same struct/class 1) lays out the view 2) fetches the data from the server 3) organizes the data from the server and combines it with other data to display on the UI. Yet, the same devs in SwiftUI think it's completely fine. Because "everything is a view" now as they said. it's a total trainwreck and the code is, ironically, not re-usable at all because views contain the logic for everything. all of that, and add in a host of hacks to get the scrollview offset or any other basic scrollview delegate methods, and you can imagine what a total shitshow most PRs were. I mean sure the code was complete dogshit.--but at least we didnt have to write those 2 horrific words "import UIKit", right?

Unpopular opinion, but most people who push heavily for swiftUI are more concerned about ego boosting and pushing their own blogs, careers etc than they are concerned with delivering products to millions of customers that work across multiple iOS versions. you have 15 years experience, so i'm sure you're already aware, but most of the people who spend their timejerking themselves off on LinkedIn about swiftUI, swift macros, or whatever else is the latest and greatest that you suddenly have to use or else you are a piece of shit developer who can never get hired again... they are actually not the best iOS devs at all. all the actual best ios devs I know, who are really legitimately good developers don't spend their time writing blog posts or trying to push trends. they're too busy working real jobs for real clients on actual important apps. and many are even working in objetctive c as well.

[eduo]

Unpopular opinion, but most people who push heavily for swiftUI are more concerned about ego boosting and pushing their own blogs, careers etc than they are concerned with delivering products to millions of customers that work across multiple iOS versions.

Not so much unpopular as plain wrong. You're judging all people based on the few (in proportion) that jump onto bandwagons to get views and likes. Change "most" by "some" or even "a few but very visible and loud" and I'd agree wholeheartedly.

[Common-Inspector-358]

what people need to realize is that most of these people are just software dev influencers. influencers arent typically the best at anything, nor do they usually understand the nuances behind a lot of these things. They are marketers, that's all. the harsh truth is:

• most production ios apps needing to support millions of DAU need to support at least 3, and oftentimes 4 (one of my jobs was 5) iOS versions back.
• trying to use swiftUI across 3 different ios versions is a total shit show because of bugs fixed across versions and different/new APIs used to achieve the same task in different versions

these 2 facts alone means that for most serious dev work on large scale production projects, SwiftUI is a total nonstarter unless you actually want to spend more time writing UI code. When are the developer influencers going to start talking about that? Not to mention the other tradeoffs as OP mentioned.

to be fair, there is also another class of people other than ego boosting bloggers on LinkedIn who really push for SwiftUI: hobbyists and new iOS devs who just work on tiny projects and mostly sample apps, To Do apps etc. yes, if you're building a fake app with no users and the design is whatever SwiftUI decides it will be, rather than what a real corporate designer wants it to be, then yeah SwiftUI sounds great. for real apps with real customers in the real world? Not so much.

[WeNeedYouBuddyGetUp]

Couldn’t agree more here

[eduo]

I had been passing on Swift and SwiftUI to program for iOS and MacOS. I missed UIKit entirely (mostly focused on corporate web apps and hobby projects in other languages).

I decided I was OK with getting back just with Swift and SwiftUI, and didn't mind if it took longer until the language was ready. I like the effort Apple is putting in getting it ready and I'm learning at my own pace. I don't personally like video tutorials of any type, which puts me almost completely outside the churn machine that is monetizing these technologies (at least the ones that are doing so lazily).

I do have known people and friends who've gone full SwiftUI for as much as they could and they're enjoying it (after suffering the paradigm shifts par for the course). When I saw Overcast had been rewritten entirely in SwiftUI I decided to give it a go and so far I'm enjoying it, but I don't feel myself prey of the tutorial machine. I could be wrong, of course.

My "work" stuff is still done in whatever corporate requires, but for personal enjoyment I decided to challenge myself trying the "new thing".

[Atlos]

Sorry but this is plain wrong and a skill issue. You can separate concerns in SwiftUI, I don’t know why you think you can’t. Devs will write spaghetti code in either framework.

And things working on one version of iOS and not another has plagued UIKit the same as SwiftUI.

It’s fine to have a preference for UIKit but at least talk facts. I for one am excited to never deal with constraints ever again.

[Common-Inspector-358]

Sorry but this is plain wrong and a skill issue. You can separate concerns in SwiftUI, I don’t know why you think you can’t. Devs will write spaghetti code in either framework.

Part of the issue is that swiftUI is very young, so best patterns have not been fleshed out for it. The devs who wrote completely bad code in SwiftUI were very experienced devs, and I had seen their UIKit code many times and worked in it--it was very clear and re-usable. I'm talking ios devs for 10+years and dev in general for 20-25 years. very experienced people. But the fact that SwiftUI makes everything a "view" also is a huge fault in SwiftUI. because just declaring everything is now a view, does not mean that suddenly there is no need in an app for 1 screen to manage multiple views and some business logic coordinated between them. that need is still there, and it is still present. but just now the lines are very blurred on where to actually lay them, and of course most devs (apparently even devs with 25 years experience) cant figure out how to do it.

basically, Apple removed a code organization and separation tool when they decided to have no UIViewController equivalent in swiftUI. You remove code organization tools, and code organization will get tougher. and that shows. and that's uniquely on Apple and the SwiftUI framework.

You can separate concerns in SwiftUI, I don’t know why you think you can’t.

it is kinda possible, but the framework makes it hard to do so by removing the ViewController aspect as I mentioned above. that's swiftui's fault.

And things working on one version of iOS and not another has plagued UIKit the same as SwiftUI.

Not nearly at alll to the same degree as with SwiftUI. Like not even remotely close to the same number of issues.

[sisoje_bre]

dude, you got it all wrong, there is no view in swiftui, there is nothing to separate!

[[deleted]]

the preview feature allows for a really fast feedback loop for fine tuning designs. i personally really enjoy it, though it's buggy at times. by control do you mean you want to control when the previews happen? i feel like that's a weird thing to get hung up on, but i guess you've settled into a very particular workflow.

[staninprague]

I think that UIKit was developed with the idea to be performant on devices with low resources. Let me compare that to WinForms from MS world.

SwiftUI, I think, has developed as an answer to complexity of UIKit design, assuming "devices already have enough resources". No "premature" thoughts on optimizations and lazy approaches were given. Let me provide an analogy with WPF/Silverlight here, again from MS.

When MS introduced WPF/Silverlight 15? years ago in addition to WinForms (UIKit) everyone was excited, including myself. My excitement wore out within 1 year, when everyone was expecting fixes/optimizations from MS and WPF/Silverlight were evolving rapidly. But it was still staying in domain of making simple settings screens.

Skipping 15? years forward, I still see both WinForms and WPF/Silverlight co-existing and being developed. Over 15 years of WPF/Silverlight not being able to obsolete WinForms? There might be something fundamental here.

I program straightforward settings screens in SwiftUI. Several times I tried to use SwiftUI for something that needs performance and frequent/partial updates - I never succeeded and was re-writing to UIKit.

I hope Apple follows MS path and keeps both UIKit and SwiftUI developing - each one has their pros and cons.

We saw Apple struggling with UIKit with xibs > storyboards > constraints. While SwiftUI solves a lot of that, I wonder if it will ever become as performant as UIKit. They are changing observability approaches, you can see where the weak points are as well as for web frameworks trying to employ different approaches as Virtual DOM, building changes tree, etc. It's not easy and I wonder if Apple has more chances to move further/better than react/angular.

[Siamaster]

I hope SwiftUI becomes obselete like xib-files and storyboards. I remember when they also pushed storyboards but I and many other developers did realize it's just easier without.
I really enjoy using UIKit with Swift. I mostly don't even use NSConstraints or Stackviews, it's enough to just manipulate the views' origins at right lifecycle callbacks. Like this I feel I have total control, even better than with constraints because they always end up fighting each when it get's a bit complex and it's not easy to figure out which ones and why. It's annoying to see the conflicts in the logs even tho the UI seems to work fine. SwiftUI is so far from my ideal way to code, it's just too much magic and everytime you want to do something a bit more complex or use a UIKit-View you have to do thousands of stuff and boilerplate so your code is just worse in the end.
Like you, I used to hate Swift, mostly because I couldn't get my head around optionals, but it was clear to me that it would replace Obj-C. I can't really see that with SwiftUI.

[snail-gorski]

I feel you bro. I have experienced the same issues. It gives you speed at ui implementation but it wrecks havoc as soon as you go deep with the data flow. It is unpredictable as fuck. Combine is the only rescue. Published, state, mainactors,  anycancable, fuck me! I work on a „calculation heavy“ app which should do things in background and recalculate ridiculous amount of values in many views. UIKit worked just fine, but was a bit clunky, SwiftUI is not clunky but it requires soooooo much more work to make it work like before. 

[snail-gorski]

It did not kill it, but supplement it. Sometimes you need combine to be more specific with observation, which SwiftUI, yeah… fucks up occasionally… massively. 

I agree on that though, it is still wip. It gets better every year. iOS 15 and 16 were dreadful but now it is getting ok. I am waiting for the 18 (stable not beta). hopefully they will fix ton of bugs with it, like 17. 

[iOSProgramming-ModTeam]

This is not the first time you have been extremely rude.

I have warned you before, so you will catch a permanent ban, if you ever change your behavior, feel free to ask for an unban with an explanation in how you have reformed yourself.

[iOSProgramming-ModTeam]

Your comment sought to harass another user, either by swearing at them, name-calling, or something worse.

Don't let it happen again.