Difference Between Implicit and Explicit Animations in SwiftUI | Hacker News Reader

Difference Between Implicit and Explicit Animations in SwiftUI

holyswift.app

68 pointsleopug31 comments

Awesome article. SwiftUI is still 'not there yet'. It makes the easier things, much easier compared to UIKit. But, as soon as you get to more advanced views, it shows its immaturity.

I know Apple is pushing it, and at some point it will be the default UI framework for iOS (it is for Vision Pro), but it has long way to go to the maturity that UIKit has.

For 'small apps', and for simple views SwiftUI is great. For more complicated interactions, UIKit is still the better framework.

If the new macOS settings panel is indicative of SwiftUIs overall qualities, I really hope it wont be the future (eg if even Apple themselves can't get such a trivial thing like a settings panel right, I don't even know what the point of SwiftUI is after so many years in development)

Yup... I liked the old one much better.

My guess, over time, they will fix the issues, but that's the typical hickups of a framework that is still too immature.

It took Swift (the language) about 6-7 years to mature up. I think the language became 'mature' only around version 5.5. Whoever used it earlier, got to hit all kinds of weird issues and instabilities.

SwiftUI, will have a similar arch. My opinion is that it is about 2-3 years to be mature enough, to replace UIKit altogether.

In iOS 2 UIKit was far more 'mature' of a framework than SwiftUI was, and it wasn't full of missing stair steps like basic navigation pushes working without it being a whole irritating song and dance, lazy loading table cells & navigation views, being able to hide the tab bar when you push a screen on one tab with things like "hidesBottomBarWhenPushed", etc.

Overall I think SwiftUI when released, and even today in some corners, is a general overall theme of incompleteness with features available in iOS 2's UIKit.

Did early iOS have it's irritating parts? For sure, but they were there for performance reasons mostly and it wasn't an 'incomplete' framework like SwiftUI is.

Overall I really like SwiftUI. As a total iOS newbie when it was new, I don’t think I would have bothered if the only option was to slog through UIKit.

But all the complaints about its incompleteness are spot-on. How did they think it was ok to launch without basic stuff like NavigationStack? Standard Apple “piss on my head and tell me it’s raining”.

I don't get why people have zeroed in on the Settings app. Outside of some very specific sections, it's fine.

Meanwhile, the Home app can't be closed when viewing an accessory because they made it a modal, the Music app sometimes can't be searched because the search field looses focus on every keypress, and the AppStore may crash outright.

The Settings app is inexcusably bad. On my M1 Pro MBP there is reliably 500-1000ms delay between clicking a section and waiting for it to appear.

That was true in a significant number of preference pages in the old Settings.app as well. It's probably the same code paths under the hood of the new UI.

I don't doubt your experience but that doesn't match mine. Third-party preference panes were slow for me in the old app, but I never noticed any lag with the standard ones.

Because I need the Settings app to work. I’m not choosing burger toppings, I’m often in there to troubleshoot. I can’t have an app that straight up lies to me about my network or refuses to respond to button presses I know it saw (WiFi “Details…” button won’t show anything if you’ve already pressed it and closed it that session, have to quit and relaunch).

SwiftUIs text rendering also looks like ass, but that also could be the result of the choice of grey on grey the design B-team in charge of the redesign chose for text boxes.

I do agree though that the Home app is far worse. It sucks on iOS and they just copy pasted it over, and that UI with a mouse cursor is just painful and ugly. Unredeemable software.

> SwiftUIs text rendering also looks like ass, but that also could be the result of the choice of grey on grey the design B-team in charge of the redesign chose for text boxes.

Are you on a high DPI monitor? macOS stopped doing subpixel antialiasing a few versions ago. It’s not great for non-retina screens, but Apple seems to think everyone should have stopped using those by now.

The Music app is just iTunes, not a new swift ui app

But... it's not at all indicative of SwiftUIs overall qualities. Whoever developed the new settings app made choices that were not great using a framework that at this point could very easily support a better one, or the original one. Even down to the toggle control using more of an iOS style, that's just a SwiftUI modifier that can either render more traditional macOS style checkboxes or a toggle switch.

It definitely has some tricky bits to get used to, some strange paradigms, but it's actually pretty good atm.

SwiftData integration (and notably the Observable macro) seems like a huge step in the right direction for it. The problem we’ve found is that integrating SwiftUI in existing UIKit apps that also rely on stuff like RxSwift isn’t easy. So far it’s only good at brand new presentations for us. Another thing is that a lot of the great new features are locked behind iOS targets that are plainly too new to be realistic for products

Mixing and matching 2-3 UI / state frameworks will always be an hassle.

>The problem we’ve found is that integrating SwiftUI in existing UIKit apps that also rely on stuff like RxSwift isn’t easy

Your RxSwift codebase should have converted to Combine 3 years ago, and today you’d map the observable streams to SwiftUI with a simple @Published property wrapper (now called macro… ugh)

It’s really not that hard, and Combine can push your state to both new and legacy views with a few lines of hookup.

The genius of AppKit in particular was that it made the easy things easy, often trivial or automatic, and the advanced things straightforward.

Almost every other technology I've ever seen for making things easier hits a wall once you're outside a usually very narrow path.

agree, appkit is really great

its hard to put my finger on it, but even compared to uikit, i feel much more productive there for some reason...

Wish I had read this a few days ago; I had an idea for a pencil-only iPad app and spent a good chunk of the weekend going down a SwiftUI rabbit hole before realizing that it might not be the right tool.

This is the kind of thing that belongs in Apple's official documentation.

It's essential knowledge, but unreliable since Apple might change the behavior.

Apple documents the happy path, while they work out details. They now have many duplicate API's - SwiftUI, Foundation Essentials - in hopes of eventually retiring old API's. So for the next few years, developers will have to choose between legacy complicated API's and simplistic but unreliable new API's. To do that, we'll need a host of practical experiments to uncover the behavior of Apple's black boxes.

Reply on news.ycombinator.com