It can draw stuff directly rather than going through UIKit. Example via WWDC by Sundell: https://wwdcbysundell.com/2019/swiftui-relationship-to-uikit...

  struct ContentView: View {
      var body: some View {
          VStack {
              ForEach(0..<3) { _ in
                  HStack {
                      Text("Leading")
                      Text("Trailing")
                  }
              }
          }
      }
  }

> Looking at the above code sample, it’s easy to jump to the conclusion that the resulting UI will consist of a vertically aligned UIStackView — which’ll then contain a set of horizontally aligned, nested stack views, which in turn each will contain two labels rendered using UILabel. However, none of those assumptions are actually true — as SwiftUI instead draws our labels directly using the private CGDrawingView class.

I don’t think so, the look and feels is different.

Under the hood it will use some UIKit like UIScrollView but the whole architecture is different.

On UIKit, the objects you create stay retained as long as they are used and all you do is to change properties when using.

On SwiftUI, everything is released and retained every time there’s a change.

That’s why you need to address the life cycle differences when you use UIKit and SwiftUI together.

For now, it mostly wraps existing UI frameworks yes. In the future if Apple decides to, they can depreciate AppKit and UIKit without changing the SwiftUI APIs and have it drawing directly. I see that as a very, very long way away though, UIKit/AppKit will be around for years to come.

I asked a similar question on StackOverflow recently.

https://stackoverflow.com/questions/64049757/are-swiftui-com...

That’s not really the right question to ask. Yes in some cases it is backed by UIKit, for now, but that can change at any time.

It is a completely new paradigm, that’s it. Implementation details are just that.

Sometimes yes, sometimes no. For most things, no.