Thanks for the answer. In fact, even when my app is working on other programs simultaneously after the contention, it feels smooth (I'm currently thinking that this is simply a difference in CPU usage). So it wouldn't be a good idea to intentionally induce contention, and thus low share, would it? I think it's dangerous to approach the problem with this mindset, because a lower share simply feels "good". But even if I solve the contention problem, I'm also feel its hard to solve the high CPU utilization problem in more ways. It's a tough problem, but at the same time, I feel like I need to solve the contention problem first. Thanks for the good advice.

I've encountered another issue. Within Xcode, when checking via the CPU report, it indicates a decrease in usage. However, when observing through the activity monitor, there's no noticeable reduction. I'm curious as to why this might be the case.

To solve this problem, I tried to implement logic to have multiple instances of the menu bar (with animations) recognize new monitors and assign them, but it didn't seem possible to have multiple instances per external screen in a single NSMenuItem, so I stopped.

The core of the problem was not properly handling the textSettings property during migration. To solve this, I made the TextSetting (newly added in SchemaV2) in the model to optional. extension SchemaV1 { @Model public final class FSViz { @Attribute(.unique) public let id: UUID public var textColor: TextColor init(textColor: TextColor) { self.id = UUID() self.textColor = textColor } } } extension SchemaV2 { @Model public final class FSViz { @Attribute(.unique) public let id: UUID public var textSettings: TextSetting? init(textSettings: TextSetting) { self.id = UUID() self.textSettings = textSettings } } } Rather than go into more detail, I hope you might this answer helpful.

same here, sonoma 14.3.1, Xcode Version 15.3 (15E204a)