This drawOn symbol effect is easy to take for granted, but it was actually a lot of work to get right. 1. SF symbols are not strokes. If you look closely at the signature, not all portions of the path are the same width. 2. Moving along the path and naively filling it would look awful! Consider filling along curves where one side of the path is shorter than the other. You want the animation to fill gracefully, but there's nothing that connects the two sides of the path. The solution was to annotate each symbol with these "railroad track" guides

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.

On the SwiftUI team we had a joke: "all bugs are bridging bugs." It's hard to build a declarative layer over UIKit! There's a lot of undefined behavior, especially in the subtle timing of the update cycle. And it's always changing. Even sitting in the same hallway, with an explicit goal of keeping the two frameworks in sync, we couldn't do a perfect job. I can only imagine how hard it's been for the React Native team.