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

SwiftUI in 2022

mjtsai.com

Post reply on HN
Print view View original

131–140 of 216 posts

Re: SwiftUI in 2022

#131

Post by cokeandpepsi »

tarentel wrote: post #80
cageface wrote: post #72

Earlier quoted context omitted.

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.

It's sometimes impossible to fight the architecture astronauts, they can be deeply appalled at how software maps to their thinking and wish to bend it towards nonsense until it does

Re: SwiftUI in 2022

#133

Post by dcow »

ChildOfChaos wrote: post #93

I haven't done much programing as a kid and i'm just starting to learn Swift/SwiftUI through the hacking with swift course, interesting to read the comments here as I didn't realize it was so hated? Seems fine to me for building apps but I don't really know enough.

I don’t think it’s hated.. don’t get the wrong idea. You’re just reading different anecdotes about how well it's worked for people in various different scenarios. There’s no perfect solution.

Re: SwiftUI in 2022

#134

Post by jkirsteins »

I recently wrote a full app (Wordle clone) in SwiftUI using the iPad Playgrounds app as a personal challenge. I didn't have a lot of experience with UIKit, and literally 0 with SwiftUI.

There was definitely a lot of time spent looking why basic things are not working as expected. There are many counterintuitive things to it, I think, and some bugs.

But overall, as a newbie to iOS development, it was a fairly nice experience. I am skeptical I could've iterated/developed something complete (despite the issues) as fast with UIKit.

I only wish they made it open source. It feels like it would really benefit from being run more like the open source Swift frameworks, rather than this opaque update-once-a-year thing.

Re: SwiftUI in 2022

#135

Post by pcr910303 »

eunoia wrote: post #113
pcr910303 wrote: post #108

Earlier quoted context omitted.

That’s more of a compatibility solution than an escape hatch. An official SwiftUI escape hatch should have access to the underlying imperative object, call methods on it, etc… Unfortunately the underlying ‘things’ in SwiftUI is implementation detail, inspecting the view hierarchy and finding the UIViews that implement a SwiftUI view is a hack.

As I understand it, what you’re asking for is fundamentally incompatible with the paradigm itself (at least in a clean way). The whole programming experience of declarative UIs is predicated on the fact that you’re manipulating lightweight structs (really just state representations) that are rendered into heavyweight views by the system only where necessary (determined by diffing the state changes). React’s refs are…

> you’re manipulating lightweight structs that are rendered into heavyweight views by the system

Yes, and I’m arguing that not exposing the ‘heavyweight views’ to the programmers at all is a mistake.

Re: SwiftUI in 2022

#136

Post by spike021 »

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

>(live preview with swiftui/etc)

I have a similar experience (started working from scratch on an iPhone app back in January with SwiftUI). Live preview is really awful. I had to basically disable it throughout my project. It'll crash for no reason and require a manual click on a button to reload, errors it spits out tend to be unintelligible, etc. I definitely wouldn't use live preview as an example of SwiftUI being advanced and not being daunting to use.

Re: SwiftUI in 2022

#137

Post by jmull »

This has pretty much been my experience:

> “Hey I got 90% of what I wanted really quick! Neat!” “…oh turns out that last 10% is basically impossible, eh?”

(Not impossible, but it's like transitioning from a pleasant stroll on a comfortable downhill trail to slogging through mud, and dense brush, with mosquitos and biting flys everywhere.)

Re: SwiftUI in 2022

#138

Post by mamcx »

akmarinov wrote: post #14

Has anyone gotten SwiftUI previews to work at all with a project that has more than 20 files or some dependencies? My project utilizes Firebase as the backend and as soon as you add that dependency - SwiftUI previews never compile, due to build time outs.

> Has anyone gotten SwiftUI previews to work ... has more than 1

Not JetPack or SwiftUI works for even a simple view!. Is incredible slow and still not true to how it will show up!

I miss the way Delphi do it...

Re: SwiftUI in 2022

#139

Post by eunoia »

pcr910303 wrote: post #135
eunoia wrote: post #113

Earlier quoted context omitted.

As I understand it, what you’re asking for is fundamentally incompatible with the paradigm itself (at least in a clean way). The whole programming experience of declarative UIs is predicated on the fact that you’re manipulating lightweight structs (really just state representations) that are rendered into heavyweight views by the system only where necessary (determined by diffing the state changes). React’s refs are…

> you’re manipulating lightweight structs that are rendered into heavyweight views by the system Yes, and I’m arguing that not exposing the ‘heavyweight views’ to the programmers at all is a mistake.

Yup, and my understanding of the problem is that if you expose the heavy weight views to the state layer (structs) and allow direct manipulation, render calls lose incompetency, the structs are no longer the source of state truth and the whole abstraction gets terribly leaky.

Edit: once again I think it’s important to look at the limitations and advantages of prior work in this area and I believe React refs to be a good case study in that.

Re: SwiftUI in 2022

#140

Post by sethd »

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

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

Exactly this. SwiftUI on iOS 13.x is practically unusable for anything above simple implementations, with some fairly major bugs that weren't fixed until iOS 14-15. Bugs aside, the lack of StateObject in SwiftUI (iOS) 13.x makes it a non-starter.

Post reply on HN