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

111–120 of 343 posts

Re: SwiftUI After 7 Years

#111

Post by asa400 »

mpweiher wrote: post #80
kodebach wrote: post #59

Earlier quoted context omitted.

The goal of the reactive/declarative approach was never to be more performant than imperative code. The goal is to more easily build UI that is performant enough and functions correctly . With imperative UI code it is incredibly easy to forget an edge case in your update logic.

Not if you actually do MVC, so solved around 50 years ago. 1. The UI tells the model to change. 2. The model does the change and possible related changes. 3. The model notifies the UI that something has changed. 4. The UI updates itself from the model. Alas almost nobody does MVC, despite calling what they do MVC.

Funny, this almost reads like a description of how Elm works.

Re: SwiftUI After 7 Years

#112

Post by cosmic_cheese »

archagon wrote: post #83
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.

It's not just super bespoke that SwiftUI can't do well, there's lots of little things that are standard in UIKit and AppKit) widgets that inexplicably never made their way over to their SwiftUI counterparts. It's not unusual to have to drop down to the UIKit version for some little thing that Apple couldn't be arsed to port over.

This is incredibly frustrating, particularly now that more UIKit and SwiftUI widgets share underlying implementations.

Re: SwiftUI After 7 Years

#115

Post by mintflow »

As a solo app developper for two years mainly for apple platform(previously do networking infra software using C/Go)

After two many trial and fail, now it's quite clear to me that for simple UI I will use swiftUI(such as help sheet or simple toggles), for complex and performance first, I will just use UIKit instead, it save a log of time and actually the imperative UIKit is also quite easy to read and review

the feasibility of review is important because code is not mainly written by agent, though as my understanding of UIKit grows I can smell the bad part and let it rewrite

Re: SwiftUI After 7 Years

#116

Post by wk_end »

mpweiher wrote: post #80
kodebach wrote: post #59

Earlier quoted context omitted.

The goal of the reactive/declarative approach was never to be more performant than imperative code. The goal is to more easily build UI that is performant enough and functions correctly . With imperative UI code it is incredibly easy to forget an edge case in your update logic.

Not if you actually do MVC, so solved around 50 years ago. 1. The UI tells the model to change. 2. The model does the change and possible related changes. 3. The model notifies the UI that something has changed. 4. The UI updates itself from the model. Alas almost nobody does MVC, despite calling what they do MVC.

I see an M and a V in this description, but no C.

Is the UI updating itself automatic or manual? Because if it’s manual, that’s precisely the error-prone part that you’re saying this approach somehow solves - you’ve done the “How to Draw an Owl” meme. If it’s automatic, that doesn’t seem especially different from the React/Redux/Elm/SwiftUI approach (as a sibling points out).

Re: SwiftUI After 7 Years

#117

Post by Exoristos »

cloogshicer wrote: post #73
mpweiher wrote: post #56

Earlier quoted context omitted.

Not just does the computer not do functional. UI is also very much not functional, and in fact the lack of progress in UI the last 30-40 years can largely be traced to trying to create UI with procedural/functional programming languages, an instance of linguistic-architectural mismatch. Further reading: Programs = Data + Algorithms + Architecture: Consequences for Interactive Software Engineering -- Stéphane Chatty.…

Thanks for those links! Some of it was great reading. What is your thesis then? What is UI?

Declarative–reactive. Like SwiftUI.

Re: SwiftUI After 7 Years

#118

Post by _s »

sandoze wrote: post #62

This seems to be a popular ‘controversial’ topic. I’ve been using SwiftUI for production applications and games since 2021. I drop down UIKit, Metal, or core animation when needed. But that’s no different than when I was making games in UIKit and would drop down to core animation or glyph renderers written in C etc. Data Flow: The author claims there’s no way to know when things update. Not only does experience help…

I was just thinking more or less along these lines - I haven't been in mobile apps for a few years now, but back then my impression was -

SwiftUI is great for "surface level" UI, that has some basic data bindings - think a basic CRUD app, which needs some navigation, and the ability to scale across the smallest iPhone to the largest macOS screen, from touch gestures to mouse input.

If you ask anything more of it, then you need to start branching off into specific libraries / tools / frameworks (UIKit, CoreAnimation etc) - which is much easier now too, but you'll always have a bad time if you try to mix the two in a single "view" / "frame".

I'm not surprised that's still true today.

Re: SwiftUI After 7 Years

#119

Post by Exoristos »

sandoze wrote: post #62

This seems to be a popular ‘controversial’ topic. I’ve been using SwiftUI for production applications and games since 2021. I drop down UIKit, Metal, or core animation when needed. But that’s no different than when I was making games in UIKit and would drop down to core animation or glyph renderers written in C etc. Data Flow: The author claims there’s no way to know when things update. Not only does experience help…

It's a popular controversy here much the way React is a popular controversy here: people dabble in the new idiom but don't solidly master its basics; chaos ensues and consequently resentment.

Re: SwiftUI After 7 Years

#120

Post by interpol_p »

SwiftUI has a lot of failings, but it can also do a lot of things that are really tricky in UIKit.

I can render Metal shaders trivially in SwiftUI. Rendering glows, and blurs, and animated effects is much easier in SwiftUI than in UIKit, just use `.blur(radius:)` or `.blendMode(...)`

I have used AppKit and then UIKit since its inception. Creating visual effects like layer masks that modulate the opacity of underlying views is trivially easy in SwiftUI — far easier than the boilerplate and constant bookkeeping that CALayer's mask requires.

So a lot of the advanced full-screen animations in some of my games and apps are SwiftUI, because they are performant, provide the cool effects and animations, and work great. A lot of the simple get-the-job-done views and tool palettes in my apps are also SwiftUI, again because they don't ask much and get the job done, and look great.

However, where SwiftUI falls down is exactly what was demoed in the video: large collections of thumbnails that fetch asynchronously? Use UIKit. Multi-thousands of items in large, complicated lists? You can try SwiftUI, but you'll need to learn how to optimize it.

Other things, not mentioned in the video, that are more annoying in SwiftUI: want to take control of a transition between views, end-to-end? Not really possible in SwiftUI. There are bugs with ZoomNavigationTransition that affect all of Apple's own apps, and you aren't gonna be able to fix them without switching to UIKit.

Post reply on HN