Fun fact: the creator of CoreAnimation is one of the creators of SwiftUI!
The decision to run animations in the app process rather than the render server (as CoreAnimation does) was one of the earliest and most fundamental decisions we made when designing SwiftUI.
Some of the most distinctive experiences of using an iPhone, like UIScrollView rubber banding and SpringBoard app switching are only possible as client-side animations.
But these experiences aren’t easy to build with UIKit!
This is because if you want a UI to be fully interactive and interruptible by the user while it’s animating, it has to be running in the same process as the event handling.
In fact, in iOS 18 we added new APIs to AppKit and UIKit to adopt the SwiftUI client-side animation model.
There are a lot of valid critiques of SwiftUI. The fact that SwiftUI doesn’t use CoreAnimation for its animations is not one of them.
SwiftUI isn’t native and here’s why SwiftUI apps may sometimes feel janky. It ditches the key element that made animations run so smoothly on iOS since the original iPhone: Core Animation.
In SwiftUI animations run in-app without CA backing. Block the main thread: SwiftUI ball stalls while UIKit’s keeps moving on the render server.