Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

Post reply on HN
Print view View original

81–90 of 343 posts

Re: SwiftUI After 7 Years

#81

Post by CharlesW »

emehex wrote: post #55

I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.

> I've noticed that developers who started with UIKit really have a hard time working with SwiftUI.

I think this is true. SwiftUI became "very good" as of iOS 26 (in part because the performance gap mostly evaporated) and continues to get better in iOS 27. Over and over, I see UIKit developers trying to do things "the UIKit way" in SwiftUI, and they'd rather write TFAs instead of considering that they may need to skill up and learn to write effective and idiomatic SwiftUI.

Re: SwiftUI After 7 Years

#82

Post by VCFundedGenYer »

the-golden-one wrote: post #18

A similar story to WPF.

I think you might have meant UWP.

WPF is still around and have been spruced up as of late.

UWP was the DOA Windows 8/8.1/10 app format that was super restrictive, strange to develop for, and non-portable. It's basically MS's equivalent of SwiftUI.

Re: SwiftUI After 7 Years

#83

Post by archagon »

emehex wrote: post #55

I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.

It’s also not possible to make super bespoke interfaces without going against the grain of the framework: anathema to old school AppKit and UIKit devs.

Re: SwiftUI After 7 Years

#84

Post by cosmic_cheese »

kodebach wrote: post #68
cosmic_cheese wrote: post #12

I'm sure many will disagree, but I have doubts that pure declarative-reactive is the "right" shape for an all-purpose native UI framework. In my experience, Kotlin+Compose shares many of the same warts… its main redeeming quality is that it's better than Android Framework (most of the time), which is low bar to clear. These frameworks have a number of good ideas but they don't necessarily combine in a way that transc…

Do you have an example of where "the ideas don't combine well"? Or where an imperative approach is truly better? In my experience the solution is often to use the appropriate architecture underneath your UI layer. Basically you build a data structure that represents your UI and always hand this entire structure to the declarative UI layer. Underneath the UI layer, you can still use imperative code to manipulate the d…

One example of where I think imperative generally does better is UI that requires substantial setup or customization.

In SwiftUI, that means endless chains of modifiers, and in Compose this means monstrous constructors and modifier chains. Both get really ugly and painful to read quickly, and there's not a lot that can be done about it apart from breaking everything out into smaller views (which only goes so far). The amount of boilerplate saved isn't worth the trade, in my opinion.

In an imperative setup, there's still a lot of code but there are more options for organization, readability, and overall clarity. One can break things up with comments, break out setup into functions with self-explanatory names (that the IDE can then quick jump to, as a bonus), etc.

Yes, it's easier to get tripped up with imperative frameworks if one isn't thoughtful with managing their data, but much of the time that code only needs to be gotten right once.

Re: SwiftUI After 7 Years

#85

Post by steve1977 »

rudedogg wrote: post #57
monster_truck wrote: post #50

Earlier quoted context omitted.

Totally agreed. I kind of figured things were going to get shitty when the guy who made autolayout got hounded on so hard that he left. I sure hope they can figure out a way through. Whatever it is, SwiftUI isn't it.

> Whatever it is, SwiftUI isn't it. I think this opinion is heavily shared by Swift developers now, but the messaging every WWDC is always "Swift and SwiftUI is the best way to build apps for Apple Platforms", etc.. If you have to keep telling everyone what they don't believe is true, it's a sign there's a problem. It feels like someone with a lot of organizational power is disconnected from the pulse of the communit…

Well the problem now is Apple would need to admit they made a mistake. And Apple does not make mistakes.

Re: SwiftUI After 7 Years

#86

Post by frizlab »

spacedcowboy wrote: post #51

Apple had a real winner with ObjC and AppKit. Swift is horrendously complicated for the benefits it offers over ObjC, and SwiftUI is a massive step backwards from AppKit. Just MHO, and it’s not going to stop the juggernaut, but there’s just no appeal in moving there for me :( If (when ?) Apple drop ObjC, that’s the day I move to Linux

Having written actual apps with AppKit, it is horrendously complicated for simple things.

Swift is incredibly better than ObjC on so many ways it’s just not comparable. I used it since day one and never looked back. (And I was deep into the ObjC ecosystem, having written very low-level frameworks, and having loved it.) Yeah, first versions of Swift were raw, but now it’s just THE language; I used for everything (obviously Apple soft frontend, but also the web, the backend, etc. Even android dev I would do with Swift though I do not have the occasion for now.)

Apple will never drop ObjC support IMHO. But most new frameworks will be Swift-only.

SwiftUI is a step backwards from AppKit in the sense that we lose control over what’s possible when using it exclusively. But 1/ it’s much simpler for doing simple things and 2/ we can drop down to AppKit when needed. All in all, it’s good that we have it.

Re: SwiftUI After 7 Years

#88

Post by brailsafe »

emehex wrote: post #38

> real, production-grade UI framework What does this even mean? There are hundreds of thousands of apps in the App Store that are 100% SwiftUI. They are real. And they are very much "production grade". The only people still complaining about SwiftUI 7 years later are the UIKit holdouts that never took the time to properly learn how to use it.

> There are hundreds of thousands of apps in the App Store that are 100% SwiftUI. They are real. And they are very much "production grade"

The first is a statement of quantity, the second is a statement of quality, dubiously supprted by the first.

The Mac Settings app still lags between panes years after it was redesigned to look like iOS. I would think that if they had a viable way build a high quality and performant app with even relatively basic UI components (if they cared to do so) they'd do it for the 1 app that's deployed to every mac.

SwiftUI does work in certain circumstances, and does work for allowing people to shit out their ideas faster, but it has struggled with the aspects described in the video. Some companies don't care either, and turnaround time is paramount, but in this discussion it's about quality compared to what came before.

Re: SwiftUI After 7 Years

#89

Post by frizlab »

palata wrote: post #74

Maybe unrelated, but as an Android dev, a few years ago I wanted to look into SwiftUI. But now I feel like for most apps, I should be fine with Compose Multiplatform and Kotlin Multiplatform. I don't see the point of learning SwiftUI anymore.

Well you could do android apps using SwiftUI ¯\_(ツ)_/¯

Re: SwiftUI After 7 Years

#90

Post by frizlab »

emehex wrote: post #55

I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.

More or less the same happened with ObjC vs. Swift when it came out, I think.
Post reply on HN