5 ms·

Swift UI makes simple UIs easier, moderately complex UIs harder, and very complex UIs impossible. The moment your UI is more complex than a stack of stacks, the

Swift UI makes simple UIs easier, moderately complex UIs harder, and very complex UIs impossible. The moment your UI is more complex than a stack of stacks, the elegance and comprehensibility falls apart compared to autolayout. It starts to feel like CSS all over again, using trial and error to try out combinations of elements and properties with unclear interactions. The pattern it enforces is theoretically great, but you will get much more mileage out of learning to write in a "reactive" style manually (When state changes, update view to match. It doesn't need to literally be a function of state to make it a function of state. E.g. don't leave ifs without elses.) A perfect combination would be a SwiftUI-style UI editor (sans bugs) to define UI, constraints included, but traditional layout management at runtime. Well, that or a ground-up redesign of SwiftUI's API.

robin_reala 2y ago
How is CSS like trial and error?
- happytoexplain 2y ago
  Because, compared to some modern layout systems, it takes longer (to put it lightly) to internalize the exact logic behind the implementation of all CSS properties and be able to simulate how they interact in complex UIs in your head.
  - mitemte 2y ago
    Can you provide some examples of modern layout systems? I’d be curious to see what’s on offer. I have experience with various iterations of UIKit’s auto layout, Yoga, as well as CSS and some Swift UI. I’ve found CSS to be considerably easier to work with, particularly when using flexbox and grid.
    - meindnoch 2y ago
      Ok, then please implement the following in CSS: Outer +---------------------------------+ | | | Left Middle Right | | | +---------------------------------+ Everything should be vertically centered. Left should stick to the "left" of the outer div, "middle" should be centered, "right" should stick to the right. Left/middle/right can have different widths and heights. In AutoLayout this is achieved by 6 constraints: - left.left = outer.left - left.centerY = outer.centerY - middle.centerX = outer.centerX - middle.centerY = outer.centerY - right.right = outer.right - right.centerY = outer.centerY I'd like to see how you implement it in CSS. (note: extra wrapper divs are not allowed)
      - robin_reala 2y ago
        Assuming your div has a class of outer it’s: .outer { display: flex; justify-content: space-between; align-items: center; } …and that’s it. (This is assuming your items are of equal width of course. It gets a little bit more complicated if not.)
        meindnoch 2y ago
        I've literally told you the items can be of arbitrary width and height. `space-between` won't keep the middle item centered.
      - qazxcvbnm 2y ago
        Either put left, right as absolute (like the following) and leave middle in the flex, or do the opposite. One may decide which option to use based on whether the centre or the left/right is more semantically important in the layout. We did have to use some CSS "tricks" (transform for absolute centring), but once you've learnt those then CSS is indeed quite sane. outer { flex-direction: row; justify-content: center; align-items: center; } left, right { position: absolute; top: 50%; transform: translateY(-50%); } left { left: 0; } right { right: 0; } (This kind of layout, which is common in eg top nav bars, is slightly deceptive. robin_reala's solution does not conform to requirements that left and right can be different widths, which would cause middle to be not centred under simple justify-content: space-between.)
rockbruno 2y ago
Apple has historically not cared about mid-level companies and above, and SwiftUI is just another example of that. Everything they do is geared towards absolute beginners / very simple projects, even Xcode itself becomes basically useless once you reach a certain level of complexity. I don't understand why they do that.
- ChrisMarshallNY 2y ago
  > Apple has historically not cared about mid-level companies and above I wouldn't say that. I've worked for a couple of marquee corporations that did a lot of work with Apple. They do things like assign direct contacts to larger corps. They don't really rely on their "popular" culture docs to support bigger companies. It's pretty natural to use their popular front as an "onboarding" system for smaller acts, with the plan to integrate them more tightly, if they get successful enough. That said, their App Store is quite restrictive, and can be a big fat pain to deal with; even as a bigger corporation. Quite doable, though. I've released over 20 apps to the iOS/Mac App stores, over the last dozen years.
- iosguyryan 2y ago
  Myopic take. Major tech companies adopted SwiftUI. Vision Pro is all SwiftUI and mixed declarative and imperative RealityKit.
  - rockbruno 2y ago
    > Major tech companies adopted SwiftUI Source? I haven't heard of any large company with complex projects fully adopting SwiftUI in their main product and not immediately regretting it. Successful adoption seems to be achieved only if the product is really simple or when using it in a very specific / isolated place of their main product (also simple). Everything else is UIKit because SwiftUI sucks at complicated logic.
mromanuk 2y ago
> Swift UI makes simple UIs easier, moderately complex UIs harder, and very complex UIs impossible. The moment your UI is more complex than a stack of stacks, the elegance and comprehensibly falls apart compared to autolayout. It starts to feel like CSS all over again, using trial and error to try out combinations of elements and properties with unclear interactions. Sadly, this has been my experience. I built a moderately complex app, only to bump into more and more problems, and I find myself fighting the framework, building hacks, and implementing workarounds. When you venture into more advanced UIs, the leaky abstraction comes back to haunt you.
rkangel 2y ago
I haven't used Swift UI, but I have used Elm, React (a bit), and Flutter (a fair amount). My understanding is that it's a similar model. In those frameworks (particularly Flutter, which generally has less ceremony), I have found simple UIs easy, and complex UIs slightly harder to build, but then they're much more predictable (fewer surprising edge case bugs) and much much more maintainable.
- yen223 2y ago
  The more I think about it, the more I think SwiftUI is inspired by Angular - two-way data binding and observables everywhere. Two-way data binding makes for shorter demos, but it doesn't scale nearly as well as one-way data binding. I've found in SwiftUI the way state gets updated across components becomes very messy very quickly. Jetpack Compose is definitely inspired by React, hooks and all. I much prefer working with Jetpack Compose for this reason.
Hamuko 2y ago
>Swift UI makes simple UIs easier, moderately complex UIs harder, and very complex UIs impossible. Having tried to make a NavigationSplitView with multiple lists in the sidebar, I can fully agree with this sentiment.
jitl 2y ago
I’m a lot happier with UIKit/AppKit plus SwiftUI than with just SwiftUI alone. I wrote a couple of small sized apps trying to use only SwiftUI “the right way” to learn the framework and as you say whenever I wanted to do something specific with a lot of control I’d hit a wall with SwiftUI and have to go crazy with wild work arounds and trial-error throw spaghetti at the wall or just give up. Now I’m writing another app and making heavy use of NSViewRepresentable use AppKit from SwiftUI, and NSHostingView to embed SwiftUI in AppKit views. I’m using mostly SeiftUI at the “leafs” of the view hierarchy, and AppKit towards the root; all my windows use a NSWindow subclass and/or a view controller. Much happier with this!
- JKCalhoun 2y ago
  I like what you're describing, but still wonder if good ol' auto-layout for the leaves would have been equivalent and just as simple.
  - jitl 2y ago
    I find creative visual styling of views like drawing paths/shapes, drop shadows, quick stacks/rows, grid panels, etc all much easier and faster with SwiftUI and SwiftUI #Preview.
Cthulhu_ 2y ago
I suppose it's a compromise; the lower you go, the more control you have. I used to work on an app where we used the UI builder at the time (I forgot the name) at first, but my colleague asserted that building the UI in code resulted in a faster app, because (according to him) parsing and rendering the XML output took longer than interpreting the code. I don't know if he was right, but a while later Apple introduced devices with different sizes (iirc the iphone 5 which was a little taller and the ipad) and doing all the layouting became impossible. Anyway when I rejoined later it was a (I believe) healthy mix of the UI builder tool and custom code for some graphic / coded elements (think a fancy progress indicator). I suspect it'll be the same for SwiftUI.

robin_reala 2y ago

How is CSS like trial and error?

happytoexplain 2y ago
Because, compared to some modern layout systems, it takes longer (to put it lightly) to internalize the exact logic behind the implementation of all CSS properties and be able to simulate how they interact in complex UIs in your head.
- mitemte 2y ago
  Can you provide some examples of modern layout systems? I’d be curious to see what’s on offer. I have experience with various iterations of UIKit’s auto layout, Yoga, as well as CSS and some Swift UI. I’ve found CSS to be considerably easier to work with, particularly when using flexbox and grid.
  - meindnoch 2y ago
    Ok, then please implement the following in CSS: Outer +---------------------------------+ | | | Left Middle Right | | | +---------------------------------+ Everything should be vertically centered. Left should stick to the "left" of the outer div, "middle" should be centered, "right" should stick to the right. Left/middle/right can have different widths and heights. In AutoLayout this is achieved by 6 constraints: - left.left = outer.left - left.centerY = outer.centerY - middle.centerX = outer.centerX - middle.centerY = outer.centerY - right.right = outer.right - right.centerY = outer.centerY I'd like to see how you implement it in CSS. (note: extra wrapper divs are not allowed)
    - robin_reala 2y ago
      Assuming your div has a class of outer it’s: .outer { display: flex; justify-content: space-between; align-items: center; } …and that’s it. (This is assuming your items are of equal width of course. It gets a little bit more complicated if not.)
      - meindnoch 2y ago
        I've literally told you the items can be of arbitrary width and height. `space-between` won't keep the middle item centered.
    - qazxcvbnm 2y ago
      Either put left, right as absolute (like the following) and leave middle in the flex, or do the opposite. One may decide which option to use based on whether the centre or the left/right is more semantically important in the layout. We did have to use some CSS "tricks" (transform for absolute centring), but once you've learnt those then CSS is indeed quite sane. outer { flex-direction: row; justify-content: center; align-items: center; } left, right { position: absolute; top: 50%; transform: translateY(-50%); } left { left: 0; } right { right: 0; } (This kind of layout, which is common in eg top nav bars, is slightly deceptive. robin_reala's solution does not conform to requirements that left and right can be different widths, which would cause middle to be not centred under simple justify-content: space-between.)

rockbruno 2y ago

Apple has historically not cared about mid-level companies and above, and SwiftUI is just another example of that. Everything they do is geared towards absolute beginners / very simple projects, even Xcode itself becomes basically useless once you reach a certain level of complexity. I don't understand why they do that.

ChrisMarshallNY 2y ago
> Apple has historically not cared about mid-level companies and above I wouldn't say that. I've worked for a couple of marquee corporations that did a lot of work with Apple. They do things like assign direct contacts to larger corps. They don't really rely on their "popular" culture docs to support bigger companies. It's pretty natural to use their popular front as an "onboarding" system for smaller acts, with the plan to integrate them more tightly, if they get successful enough. That said, their App Store is quite restrictive, and can be a big fat pain to deal with; even as a bigger corporation. Quite doable, though. I've released over 20 apps to the iOS/Mac App stores, over the last dozen years.
iosguyryan 2y ago
Myopic take. Major tech companies adopted SwiftUI. Vision Pro is all SwiftUI and mixed declarative and imperative RealityKit.
- rockbruno 2y ago
  > Major tech companies adopted SwiftUI Source? I haven't heard of any large company with complex projects fully adopting SwiftUI in their main product and not immediately regretting it. Successful adoption seems to be achieved only if the product is really simple or when using it in a very specific / isolated place of their main product (also simple). Everything else is UIKit because SwiftUI sucks at complicated logic.

mromanuk 2y ago

> Swift UI makes simple UIs easier, moderately complex UIs harder, and very complex UIs impossible. The moment your UI is more complex than a stack of stacks, the elegance and comprehensibly falls apart compared to autolayout. It starts to feel like CSS all over again, using trial and error to try out combinations of elements and properties with unclear interactions. Sadly, this has been my experience. I built a moderately complex app, only to bump into more and more problems, and I find myself fighting the framework, building hacks, and implementing workarounds. When you venture into more advanced UIs, the leaky abstraction comes back to haunt you.

rkangel 2y ago

I haven't used Swift UI, but I have used Elm, React (a bit), and Flutter (a fair amount). My understanding is that it's a similar model. In those frameworks (particularly Flutter, which generally has less ceremony), I have found simple UIs easy, and complex UIs slightly harder to build, but then they're much more predictable (fewer surprising edge case bugs) and much much more maintainable.

yen223 2y ago
The more I think about it, the more I think SwiftUI is inspired by Angular - two-way data binding and observables everywhere. Two-way data binding makes for shorter demos, but it doesn't scale nearly as well as one-way data binding. I've found in SwiftUI the way state gets updated across components becomes very messy very quickly. Jetpack Compose is definitely inspired by React, hooks and all. I much prefer working with Jetpack Compose for this reason.

Hamuko 2y ago

>Swift UI makes simple UIs easier, moderately complex UIs harder, and very complex UIs impossible. Having tried to make a NavigationSplitView with multiple lists in the sidebar, I can fully agree with this sentiment.

jitl 2y ago

I’m a lot happier with UIKit/AppKit plus SwiftUI than with just SwiftUI alone. I wrote a couple of small sized apps trying to use only SwiftUI “the right way” to learn the framework and as you say whenever I wanted to do something specific with a lot of control I’d hit a wall with SwiftUI and have to go crazy with wild work arounds and trial-error throw spaghetti at the wall or just give up. Now I’m writing another app and making heavy use of NSViewRepresentable use AppKit from SwiftUI, and NSHostingView to embed SwiftUI in AppKit views. I’m using mostly SeiftUI at the “leafs” of the view hierarchy, and AppKit towards the root; all my windows use a NSWindow subclass and/or a view controller. Much happier with this!

JKCalhoun 2y ago
I like what you're describing, but still wonder if good ol' auto-layout for the leaves would have been equivalent and just as simple.
- jitl 2y ago
  I find creative visual styling of views like drawing paths/shapes, drop shadows, quick stacks/rows, grid panels, etc all much easier and faster with SwiftUI and SwiftUI #Preview.

Cthulhu_ 2y ago

I suppose it's a compromise; the lower you go, the more control you have. I used to work on an app where we used the UI builder at the time (I forgot the name) at first, but my colleague asserted that building the UI in code resulted in a faster app, because (according to him) parsing and rendering the XML output took longer than interpreting the code. I don't know if he was right, but a while later Apple introduced devices with different sizes (iirc the iphone 5 which was a little taller and the ipad) and doing all the layouting became impossible. Anyway when I rejoined later it was a (I believe) healthy mix of the UI builder tool and custom code for some graphic / coded elements (think a fancy progress indicator). I suspect it'll be the same for SwiftUI.