4 ms·

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,

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.

flohofwoe 3y ago
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)
- ardit33 3y ago
  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.
  - novok 3y ago
    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.
    - cvwright 3y ago
      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”.
- SebastianKra 3y ago
  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.
  - mk12 3y ago
    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.
    - shilgapira 3y ago
      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.
      - mk12 3y ago
        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.
  - wpm 3y ago
    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.
    - 3y ago
- brailsafe 3y ago
  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.
PossiblyKyle 3y ago
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
- interactivecode 3y ago
  Mixing and matching 2-3 UI / state frameworks will always be an hassle.
- newZWhoDis 3y ago
  >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.
mpweiher 3y ago
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.
- andrekandre 3y ago
  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...
jrussino 3y ago
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.

flohofwoe 3y ago

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)

ardit33 3y ago
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.
- novok 3y ago
  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.
  - cvwright 3y ago
    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”.
SebastianKra 3y ago
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.
- mk12 3y ago
  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.
  - shilgapira 3y ago
    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.
    - mk12 3y ago
      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.
- wpm 3y ago
  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.
  - 3y ago
brailsafe 3y ago
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.

PossiblyKyle 3y ago

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

interactivecode 3y ago
Mixing and matching 2-3 UI / state frameworks will always be an hassle.
newZWhoDis 3y ago
>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.

mpweiher 3y ago

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.

andrekandre 3y ago
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...

jrussino 3y ago

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.