Thanks for the answer! I appreciate the suggestion, and I definitely understand the reasoning behind first checking whether the layer construction actually causes noticeable hitches before trying to optimize it. In this particular case, I'm looking at this in the context of the Lottie library, where the layer hierarchy can become quite large and convoluted, with many layers and animations being created/configured. So I'm trying to understand whether there is a way to move as much of that work as possible off the main thread. (More context here: https://github.com/airbnb/lottie-ios/discussions/1886?utm_source=chatgpt.com). To come back to your question, I don't have an exact number at the moment. I would say, though, that even one of the simplest Lottie files, Bouncing Ball, creates a hierarchy of around 10 layers with 7 animations added. Of course, that's still a very small hierarchy and isn't an issue to construct on the main thread. I'm mentioning it mainly as a reference point, since more complex Lottie files can result in significantly larger and more convoluted hierarchies, especially when nested compositions are involved. The Task.yield() suggestion is interesting and may well be a good solution for keeping the main thread responsive. That said, the library's current implementation doesn't really support this approach, so it would require a significant change for this. Before considering it, I'd like to focus on optimizing the interaction with Core Animation itself, if that's possible. Vlad.