Live data from Hacker News

SwiftUI in 2022

mjtsai.com

61–70 of 216 posts

Re: SwiftUI in 2022

#61

Is anyone using this really? My team is pretty excited about using it but I've been a little more hesitant mostly because I've not read of anyone using it at any sort of scale with success. Even for smaller project it still doesn't seem production ready.

I'm using SwiftUI extensively when I get the opportunity. The team that I'm on has decided to shift our UIKit+Storyboards app towards leveraging SwiftUI more. It won't work for 100% of the app, but that's alright because there are easy-to-implement escape hatches back into UIKit.

The worst part of the dev experience is that we are currently supporting back to iOS 13 (which is when SwiftUI was introduced). That means we can only really use the oldest SwiftUI components and modifiers; it's not too bad, but finding usable examples online is tricky sometimes (they often assume the latest).

Re: SwiftUI in 2022

#62
post #39

> Adam Kaump: “Hey I got 90% of what I wanted really quick! Neat!” “…oh turns out that last 10% is basically impossible, eh?” This seems to be the story of apple in general. Very beautiful and easy to use as long as you stay on the path and don’t go too far along lest you discover the 2nd mile is still under construction.

That last 10% is easily accessible by reaching into UIKit. Crossing that boundary is much easier in practice than one might expect at a first glance of the docs for doing so.

Re: SwiftUI in 2022

#63
post #28
post #2

I looked a bit of the posts on Twitter, and wow, it’s really polarized. People seem to either love it or hate it. Is SwiftUI still that controversial, or is it just an effect of people posting on Twitter?

My experience of SwiftUI is that all of the love and all of the hate is simultaneously correct. It makes some tasks much much easier, e.g. low vision users really benefit from variable font sizes, which Storyboards can do but it feels unnecessarily hard to do in a non-fragile way. I can also see the benefits of reactive UI over the Storyboard approach, especially with UICollectionView and UITableView. But… The code e…

> It makes some tasks much much easier, e.g. low vision users really benefit from variable font sizes, which Storyboards can do but it feels unnecessarily hard to do in a non-fragile way.

Code-only UIKit (no storyboards or XIBs) with autolayout handles this case pretty well in my experience. There’s a few gotcha’s but no more than with SwiftUI. You mainly just need to remember to use UIFont’s preferredFont(forTextStyle:) when setting up labels and controls.

Re: SwiftUI in 2022

#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, while other things are randomly introduced. And of course, “Feedbacks” have the usual dice-roll effect: will you even get a response, much less see any indication that the reported bug will ever be fixed? (Or will Apple just wait 2 years, close your bug as “probably fixed in this OS update, please confirm”, and repeat the whole thing?)

And the thing is, this is not hard to believe. If you auto-complete in SwiftUI (what else can you do, there is rarely good documentation?), some of the APIs are truly scary: levels of complexity and variation that really make me wonder if they can truly test, much less support, every variation of every API. I would strongly argue that some things just have way too many options instead of a handful of clear starting points.

SwiftUI also occasionally changes behaviors (e.g. subtle or gross layout differences). Worse, it is easy for Apple to not call any of these changes “breaking” because apparently you are just supposed to let SwiftUI figure out what is needed in any situation. Except that kind of “trust us, we’ll come up with something” approach is not great for writing stable production software.

The auto-generated hierarchies can do truly weird things. For example I realized at one point that an “auto-saved” window layout auto-generated preference names based not on a simple string but the entire SwiftUI view hierarchy, which was huge and indecipherable and of course would become a different value if any part of the window or view hierarchy was modified. So I discovered I had dozens of preference settings scattered throughout my defaults, 99% of which were completely obsolete because they were based on previous incarnations of the view I was developing, and they all had names that were almost impossible to type (so how do I delete them while preserving the rest?). What do you even do with that?

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?

Re: SwiftUI in 2022

#65
My team has two green field apps that we started a few weeks ago. The leads on the iOS team and Android team both spent a week evaluating the new UI systems in each platform, SwiftUI and Jetpack Compose.

The conclusion was that Apple made a huge mistake tying it the iOS version and effectively limiting updates and it's real world use for years at a time.

Both leads liked the design paradigms, but we are only going to use Jetpack Compose since it's made of multiple libraries that are all backwards compatible with our minimum supported version. iOS will stick to UIKit since it works and is backwards compatible

Re: SwiftUI in 2022

#66
post #49

I'm confused by this post. Is it just a random smattering of Twitter sentiment collected into one place?

You’re not wrong; that is the blog’s style. I enjoy the format for exposing me to a cross-section of opinions from across the internet, on topics I find interesting, with very little work on my part. That’s probably more an indictment on Twitter’s product stagnation than a shower of praise on this blog and it’s author.

Re: SwiftUI in 2022

#68
post #55

SwiftUI was a mistake. The jury is still out on Swift itself.

As someone who got his start in programming with Obj-C and AppKit, I’m totally sold on Swift. I’ll still do small tools and the like with Obj-C sometimes but for projects with any complexity, Swift is my go-to. The number of stupid mistakes the Swift compiler catches and little QoL things like not having to maintain header files make it worth its comparative downsides.

Re: SwiftUI in 2022

#69

...no comparison with Flutter or at least remarks of what would also apply to it?

Flutter is almost exclusively used by web developers in my professional and personal experience which is odd considering the lack of JS.

The types of companies that hire iOS developers and build iOS apps also hire android developers and build android apps, again, IME.

Re: SwiftUI in 2022

#70
I've tried both SwiftUI and Jetpack Compose (the equivalent framework for Android). While conceptually they are very similar frameworks, in practice I found that Jetpack Compose + Kotlin had a far superior development experience than SwiftUI + Swift.

I genuinely cannot think of a single thing that SwiftUI does better than Jetpack Compose.

There are a lot of fundamental design decisions in SwiftUI that are questionable, like their reliance on two-way binding (which makes non-trivial event handling very difficult to implement), or having Views be structures rather than functions (which then necessitated special ForEach views, because you can't use regular control flow mechanisms).

Post reply on HN