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

31–40 of 343 posts

Re: SwiftUI After 7 Years

#31

Post by Razengan »

ardit33 wrote: post #25

SwiftUI it is the type of framework that makes the easy things easier to accomplish but the harder things harder. It is a newbie trap. It is great at producing simple apps, or things that don't require intense scrolling, or anything with heavy animations and precise layouts, but when you do something smooth, it is not it. It feels more of a React Native competitor, than a true UIKit replacement. Also, almost everythi…

> With AI coding... SwiftUI lost its edge/advantage

On the contrary, I think AI has made it EASIER to approach SwiftUI now, because AI makes up for SwiftUI's biggest weaknesses: the many ways of doing everything, Apple's wonky documentation and the need to know when to fall back to AppKit/UIKit.

Re: SwiftUI After 7 Years

#32

Post by steve1977 »

Razengan wrote: post #5

I fell in love with SwiftUI the day it was announced, but as a solo dev I still haven't been able to make a full app with it yet, mostly because of the lack of documentation, and the gaps where you still need to drop down to AppKit/UIKit. I went through Visual Basic, .NET, WPF, Cocoa, and other random frameworks all professing to be the promised panacea for UI, but I think SwiftUI+SwiftData is the best environment ev…

> There's no way I'd dare to take on a full Apple-platform app project alone on my own

And that's really sad, because earlier Mac OS X (and even OPENSTEP to a degree) was an Eldorado for boutique developers, not least due to frameworks like Cocoa and Objective-C (despite all the hate it seems to get).

If you knew C, it was not hard to grasp Objective-C (at least it was much easier than say C++ and MFC on the Windows side of things).

Re: SwiftUI After 7 Years

#33

Post by norbert515 »

rumori wrote: post #14
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…

I think open source is the right move here. The great thing about Flutter is you get the declarative UI to build a lot of standard screens easily but you can always drop down to lower levels, inspect the standard components, mix and match with your custom implementation. You can mix UKit and SwiftUI but there’s way more friction due to the closed nature of the SDK.

Fully agree (been an early Flutter adopter!). It's always the right too for the right job, declarativness makes a lot of sense for most UIs. UIs are surprisingly more complicated than one might think, there is accessibility/ theming/ keyboard traversal etc., just declaring UI and letting the framework figure out the rest has held up pretty well.

And because of the open source nature you can always drop down in layers, just a few weeks ago I made a very specific engine optimization, all while the application code on-top can stay declarative!

Re: SwiftUI After 7 Years

#34

Post by mpweiher »

poly2it wrote: post #20
skydhash wrote: post #16

Earlier quoted context omitted.

I think the main issue is the functional approach. Having a functional approach to state can be quite elegant, but ultimately the computer does not do functional. You have to implement a lot of plumbing to have stuff that is a bit performance (clojure), or just add a veneer of functional over what is essentially a normal state machine (emacs). React works well, because it's only an abstraction over the real DOM. Reac…

Functional doesn't mean stateless. I'd argue functional programming is superior for representing state in user interfaces. For a success implementation, see Jane Street's Bonsai: https://github.com/janestreet/bonsai

Not sure how you define "success" here. Is Bonsai used much outside of Jane Street?

Re: SwiftUI After 7 Years

#37

Post by rumori »

danscan wrote: post #6
formvoltron wrote: post #2

Is the right way to develop mobile apps flutter? or Kotlin multiplatform plus native UIs?

There is no right way :) SwiftUI is good, albeit not without issues, as long as you tolerate them. The same is true for any approach. My most recent app was built in SwiftUI because I have been using React Native in my professional work for so long I wanted a change of scenery. Each approach has its issues, and it all boils down to a matter of preference and which tradeoffs are appropriate for the project.

I’ve worked on some award winning apps in the past, our experience with SwiftUI is it makes it really easy to develop a basic average looking app. As soon as you need something non-standard, you have to drop down to UIKit and figure out how to play nice between the two, which is often non trivial and hard to estimate. You file radars, which at best will be fixed in the next OS release and rarely back ported if at all. In the end some of the more complicated apps just ditched SwiftUI altogether or applied a myriad of workarounds.

Re: SwiftUI After 7 Years

#38

Post by emehex »

> 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.

Re: SwiftUI After 7 Years

#39

Post by skydhash »

poly2it wrote: post #20
skydhash wrote: post #16

Earlier quoted context omitted.

I think the main issue is the functional approach. Having a functional approach to state can be quite elegant, but ultimately the computer does not do functional. You have to implement a lot of plumbing to have stuff that is a bit performance (clojure), or just add a veneer of functional over what is essentially a normal state machine (emacs). React works well, because it's only an abstraction over the real DOM. Reac…

Functional doesn't mean stateless. I'd argue functional programming is superior for representing state in user interfaces. For a success implementation, see Jane Street's Bonsai: https://github.com/janestreet/bonsai

> Functional doesn't mean stateless.

I didn't say that.

User interfaces representation are mostly trees. And with functional programming you basically have Tree2 = f(Tree1). Until f is done you can't do anything really. React has a lot of escape hatches to improve performance, but they are escape hatches, not an endorsement of the architecture.

With imperative programming (and OOP), you only have that single `Tree`, which you update at will. Less elegant yes, but we have modularization to help us there. What Emacs does is to keep that `Tree` as a single mutable object, but have the code be functional, while the results are imperative.

Post reply on HN