SwiftUI in 2022 • Hacker News Board

Re: SwiftUI in 2022

#71

Post by lapcat » Wed, May 25, 2022, 3:01 PM UTC

PStamatiou wrote: post #58

lapcat wrote: post #54

Earlier quoted context omitted.

> You could write an opposite article featuring people using SwiftUI that have never touched UIKit or iOS code before and it would be nothing but glowing praise. How can one properly evaluate it with no point of comparison? If you've never tasted chocolate, then vanilla might seem like the greatest flavor ever.

The point of comparison is that it has given people the ability to develop their own iOS apps from scratch, when previously they could not as UIKit was too daunting and the tools were not as advanced (live preview with swiftui/etc).

Fair enough. In fairness to the blog author, iOS developers with more experience are more likely to be known to him and others.

Re: SwiftUI in 2022

#72

Post by cageface » Wed, May 25, 2022, 3:02 PM UTC

ChrisMarshallNY wrote: post #44

I'm really looking forward to what comes of it, but I have chosen to do my current major project in UIKit. A couple of reasons: 1) The documentation for SwiftUI, when I started (about two years ago) was awful . I was shocked at how bad it was. I believe that it has since improved. 2) I knew of no major apps (even Apple ones) that had been done with it. I already knew that UIKit was up to the task, and held my nose, w…

Yeah UIKit is deeply MVC. It may not be the most conceptually elegant but in my experience you're almost always better off cutting with the grain of the underlying platform's abstractions instead of trying to superimpose a new leaky abstraction on top of them.

I worked on one large iOS codebase that went all in on the VIPER architecture and it was one of the most unweildy and baroque codebases I've ever had the misfortune to work in.

Re: SwiftUI in 2022

#73

Post by kitsunesoba » Wed, May 25, 2022, 3:03 PM UTC

makecheck wrote: post #64

Lots of great and specific points in these threads, many of which I have personally seen. SwiftUI was really promising at first, and even fun to use (nothing like ripping out entire UI files or pages of code). Yet, issues were almost immediately apparent. A major concern is that it seems to take Apple a really long time to address even basic issues, e.g. years go by and things still broken since day 1 are there, whil…

> Yet another major concern is that SwiftUI is very dependent on Combine which is not necessarily the future given other developments in the Swift language. So what if they just decide to, say, deprecate Combine and move further toward actors and async APIs? How much of SwiftUI might just fundamentally change in, say, WWDC this year, completely invalidating years of effort people have put into it?

If you’re talking about Combine vs async/await, I think they’ll continue to coexist because they fill different niches. In the UIKit app I’m responsible for I use both — async/await for things like network calls and Combine for keeping UI state in sync with data.

Re: SwiftUI in 2022

#74

Post by mark_l_watson » Wed, May 25, 2022, 3:03 PM UTC

I wrote a simple app last summer using SwiftUI and put it in the AppStore. Fairly easy after taking a short online class.

I agree with many of the negative comments in the article and Apple should get busy resolving issues.

That said, I really like the idea of Swift and SwiftUI and especially Apple’s awesome deep learning support in apps.

Re: SwiftUI in 2022

#75

Post by madeofpalk » Wed, May 25, 2022, 3:03 PM UTC

ChrisMarshallNY wrote: post #44

I'm really looking forward to what comes of it, but I have chosen to do my current major project in UIKit. A couple of reasons: 1) The documentation for SwiftUI, when I started (about two years ago) was awful . I was shocked at how bad it was. I believe that it has since improved. 2) I knew of no major apps (even Apple ones) that had been done with it. I already knew that UIKit was up to the task, and held my nose, w…

> 2) I knew of no major apps (even Apple ones) that had been done with it.

Probably not ‘major’ as in ‘complex’, but I believed the Apple Pay sheet is now Swift UI

Re: SwiftUI in 2022

#76

Post by ChrisMarshallNY » Wed, May 25, 2022, 3:04 PM UTC

cageface wrote: post #72

ChrisMarshallNY wrote: post #44

I'm really looking forward to what comes of it, but I have chosen to do my current major project in UIKit. A couple of reasons: 1) The documentation for SwiftUI, when I started (about two years ago) was awful . I was shocked at how bad it was. I believe that it has since improved. 2) I knew of no major apps (even Apple ones) that had been done with it. I already knew that UIKit was up to the task, and held my nose, w…

Yeah UIKit is deeply MVC. It may not be the most conceptually elegant but in my experience you're almost always better off cutting with the grain of the underlying platform's abstractions instead of trying to superimpose a new leaky abstraction on top of them. I worked on one large iOS codebase that went all in on the VIPER architecture and it was one of the most unweildy and baroque codebases I've ever had the misfo…

> the VIPER architecture

Re: SwiftUI in 2022

#77

Post by tarentel » Wed, May 25, 2022, 3:04 PM UTC

ChrisMarshallNY wrote: post #44

I'm really looking forward to what comes of it, but I have chosen to do my current major project in UIKit. A couple of reasons: 1) The documentation for SwiftUI, when I started (about two years ago) was awful . I was shocked at how bad it was. I believe that it has since improved. 2) I knew of no major apps (even Apple ones) that had been done with it. I already knew that UIKit was up to the task, and held my nose, w…

> I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed explicitly for MVC. I have learned that those ugly-ass UIViewControllers are really important, and I circumvent them at my peril.

I agree with everything you've said but this. I've worked on 3 very large app, one which is 85% using mvvm, the two others were still in experimentation phases with it and I am not sure where they've ended up. It's been a joy. The app is designed in a very reactive way and the data flow paths are very clearly defined and easy to follow.

Don't get me wrong the other two apps were heavily MVC with a lot of delegation and that was fine. I could easily switch back to an architecture like that but it's very possible and quite easy to switch over to an mvvm pattern.

Re: SwiftUI in 2022

#78

Post by ChrisMarshallNY » Wed, May 25, 2022, 3:06 PM UTC

madeofpalk wrote: post #75

ChrisMarshallNY wrote: post #44

I'm really looking forward to what comes of it, but I have chosen to do my current major project in UIKit. A couple of reasons: 1) The documentation for SwiftUI, when I started (about two years ago) was awful . I was shocked at how bad it was. I believe that it has since improved. 2) I knew of no major apps (even Apple ones) that had been done with it. I already knew that UIKit was up to the task, and held my nose, w…

> 2) I knew of no major apps (even Apple ones) that had been done with it. Probably not ‘major’ as in ‘complex’, but I believed the Apple Pay sheet is now Swift UI

I think that most of the smaller Apple apps are now SwiftUI (and Catalyst).

But the app I'm writing is a good deal more complex than most of the utility apps, and I seriously doubt that the complex apps are SwiftUI. I would not be surprised if many of them are still ObjC.

Re: SwiftUI in 2022

#79

Post by bowsamic » Wed, May 25, 2022, 3:06 PM UTC

The problem with SwiftUI is what Apple seems to consider its advantage: that it hides complexity from the developer (see their “Avocado toast maker” analogy in one of the WWDCs). The reason this is a problem is because sometimes you do need to break out of the paradigm, and doing so is basically always painful. At least with UIKit and AppKit you are always in full control. Complex apps will break out of the SwiftUI box all over the place, destroying the benefits. You can usually hack things to make it play with SwiftUI nicely, but it always feels like a hack.

One example I had was trying to put an ObservableObject into UserDefaults for persistent storage. There’s not really a nice way to do this. SwiftUI only knows how to store basic scalar values in UserDefaults. That kind of makes sense, because UserDefaults is only meant for small amounts of data, but what if I want to save a struct that has two fields? Trying to do this in SwiftUI is actually quite painful and that is a very simple example. Another pain point is app navigation which basically does not work properly at all.

Though one very nice thing is that it’s quite easy to use a SwiftUI view from UIKit

Overall though, somehow a far worse experience than using something like React

Re: SwiftUI in 2022

#80

Post by tarentel » Wed, May 25, 2022, 3:06 PM UTC

cageface wrote: post #72

ChrisMarshallNY wrote: post #44

I'm really looking forward to what comes of it, but I have chosen to do my current major project in UIKit. A couple of reasons: 1) The documentation for SwiftUI, when I started (about two years ago) was awful . I was shocked at how bad it was. I believe that it has since improved. 2) I knew of no major apps (even Apple ones) that had been done with it. I already knew that UIKit was up to the task, and held my nose, w…

Yeah UIKit is deeply MVC. It may not be the most conceptually elegant but in my experience you're almost always better off cutting with the grain of the underlying platform's abstractions instead of trying to superimpose a new leaky abstraction on top of them. I worked on one large iOS codebase that went all in on the VIPER architecture and it was one of the most unweildy and baroque codebases I've ever had the misfo…

I apologize to the people who bought into this pattern but what was anyone thinking? Just reading through how it was supposed to be done set off so many red flags I never even considered it. There is so much useless abstraction it makes no sense.