No problem, my bad. I should have provided the full context and not assumed that someone without my context could infer the information. Regarding the implementation of the library, while I do agree that there is some complexity involved, I wouldn’t necessarily say that it is poorly implemented. As far as I understand it, part of the hierarchy complexity comes from the way the file is decoded. I don’t have enough information about that part to draw a meaningful conclusion, but I’m pretty sure there is a good reason for it to work this way. That being said, I think I now have a better understanding of what you were trying to explain. While one solution would be to keep the current implementation and try to optimize it at the CoreAnimation level, that would just add more complexity to the existing solution & would work against the way the framework is intended. A better approach would be to optimize the configuration(as you have suggested in a previous message) that creates the complexity in the first place. With a simpler tree hierarchy, the issue I mentioned will most likely not even appear in the first place. I will try and see what I can obtain in that regard. Appreciate your time and explanations! Vlad.

One small clarification regarding the example above: when you see something like CoreAnimationLayer, that's a CALayer subclass. Also, the example was intentionally linear, meaning layer 1 is the parent of layer 2, layer 2 is the parent of layer 3, and so on. A more realistic layer tree would have multiple children attached to each parent. That said, I think I may have deviated a bit from my original question. While your input is valuable and I really appreciate it, what I was primarily curious about is whether CoreAnimation supports any kind of offloading to worker/background threads. If it does, I'm particularly interested in understanding what the execution model looks like: which parts of the work can happen off the calling thread, when that work is scheduled, and how it relates to the layer tree & transaction model. From what I understand from your answer, the kind of offloading I'm describing shouldn't really happen. If so, the question I have is why. I've looked through quite a few resources on this, but I haven't been able to find a clear explanation of the underlying model. If you don't have the time for the explanation part I would appreciate if you have any good resources on this topic. Thank you! Vlad.

Apologies, I was in a bit of a rush and sent the wrong link for the discussion above: https://github.com/airbnb/lottie-ios/discussions/1886. This does not represent what I want to achieve, I sent the wrong reference. There was a separate discussion around this topic, but to be completely honest, I can’t seem to find it anymore. In any case, I had several private discussions with one of Lottie’s code owners about this. The main idea was to explore ways to make the main thread more responsive when working with large files, primarily by moving as much work as possible off the main thread (this includes only the UI work not decoding the json file work). For the Bouncing Ball, that is the correct link. I thought it was pretty popular so I did not sent the link for it. I should have done that and assume nothing, apologies. Regarding the number of layers, I’ll shortly show the layer hierarchy and the animations that Lottie creates for that file. As you can see, the BouncingBall file has 7 layers (8 in total, but one belongs to the container where the animation is added) and 8 animations. The setup and associated overhead become significantly more costly as the complexity of the file increases. 1. CALayer 2. LottieAnimationLayer 3. CoreAnimationLayer - animations: 1 4. ShapeLayer 5. BaseAnimationLayer - animations: 2 6. GroupLayer frame - animations: 4 7. ShapeItemLayer 8. CAShapeLayer - animations: 1 Putting tasks on a background thread because they take too long, especially configuration tasks, is a bad idea. Typically Apple solves these kinds of issues by eliminating the configuration task and configuring structures on-the-fly, as needed. I’ll definitely look into this, but if you have any good resources or examples you’d recommend, I’d really appreciate it if you could share them. Thx! Vlad.

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.