1. 16
  1.  

  2. 6

    I started using SwiftUI last week, and I do agree with most voices, both negative and positive, in the parent link.

    SwiftUI looks really nice in well-prepared presentations, but the tooling is, even nearly three years after its public revelation, piss-poor. Totally opaque error messages, which may show up in source code, in the preview pane, in the build log or just in system logs, if at all. When previews fail, getting them up and running again requires as much creativity as I would like to spend on creating good user interfaces. In comparison, NIBs and storyboards are really rather robust.

    I also have colleagues who enjoy using SwiftUI, so mileage may vary, but it’s when the tooling fails that you are in for a very frustrating climb back just to a state where you can write code and make user interfaces, instead of debugging a black box that has the same kind of error handling you expect of beta software or school projects.

    1. 5

      I’ve started shipping features with SwiftUI recently and this does not really reflect my experience. I’ve been doing UIKit + Objective-C and Swift on the same iOS app since 2008 (obviously not Swift the whole time). I’ve found it much faster to ship SwiftUI views than UIKit. I can’t speak for macOS as I don’t really dabble there.

      There was definitely a learning curve, but as I have topped that curve the pay offs from the learning are increasing for me.

      1. 3

        This is a relief to see. I only started working with Swift and SwiftUI recently to write my first iOS app, and have found SwiftUI difficult to use and difficult to find solutions for when I run into problems. Things as simple as updating a view from a background thread or making a UIActivityViewController seem unnecessarily complicated and Apple’s examples and docs aren’t great so I’ve been mostly reliant on StackOverflow.