When Apple introduced the iPhone they required automatic reference counting to be used in Objective-C rather than tracing garbage collection (the language supported both) due to performance reasons (iPhones were significantly slower than Macs). At least Apple seems to think that reference counting is faster than tracing garbage collectors. The compiler can do a lot to remove unnecessary releases and retains. Additionally each retain is just incrementing an integer, and each release is just decrementing an integer and comparing the integer to 0, so the overhead is pretty small.

Metal — it’s a proprietary graphics API made by Apple

Quartz is a layer beneath SwiftUI or AppKit. SwiftUI is still using Quartz under the hood. The way you use Quartz directly from SwiftUI vs AppKit is a bit different, though still fairly similar. A more fair comparison of the SwiftUI code would be:

struct HelloWorldView: View {
  var body: some View {
    Canvas { context, _ in
      context.draw(
        Text("HelloWorld")
          .font(.system(size: 24))
          .foregroundColor(.black),
        at: CGPoint(x: 20, y: 20)
      )
    }
  }
}

Alternatively an AppKit solution (not using Quartz directly) would be something like:

class HelloWorldView: NSView {
  override init(frame frameRect: NSRect) {
    super.init(frame: frameRect)
    let text = NSAttributedString(
      string: “Hello World”,
      attributes: [.font: NSFont.systemFont(ofSize: 24), .foregroundColor: NSColor.black]
    )
    let label = NSTextField(labelWithAttributedString: text)
    addSubview(label)
  }

  required init?(coder: NSCoder) {
    fatalError()
  }
}

In either AppKit or SwiftUI, you can access Quartz directly to implement custom views. However, most of the time the UI code you write in either SwiftUI or AppKit won’t call Quartz directly at all, but will instead be composed of built-in views, like (NS)TextField or (NS)Button. Under the hood, SwiftUI is mainly just using the AppKit components at the moment, but provides a significantly nicer way to use them (especially in regards to layout and data synchronization).

Swift. Mostly because it’s by far what I’m most familiar with. Two things come to mind for what I most like about it. 1. Progressive disclosure: I found learning Swift to be simple since I didn’t have to directly concern myself with advanced features, but as I learned more I could take advantage of these more advanced features. 2. Clarity: I find Swift far more readable than most other languages. I think this is a combination of language features (argument labels for example) and consistency across the standard library and popular third party libraries. I think Swift finds a good middle ground between brevity and expressiveness; there’s never too much boilerplate to write, but the code is usually fairly self documenting.