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).
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.