I think the architecture needed to support them means the total package is less than most apps. For example consider scrolling: In Bike it's fast enough that w

I think the architecture needed to support them means the total package is less than most apps. For example consider scrolling: In Bike it's fast enough that when you scroll it just updates what you can see on the screen. This means you only pay memory for visible text. For most macOS apps scrolling performance is achieved by pre-rendering before and after the visible scroll area. So you pay for that cache and you also pay for the background processing required by pre-rendering. Also consider simple things like window resize. In Bike that only effects visible text. If you open a large document in TextEdit you will see that resize is quite slow and processor and memory intensive. (you can test with https://www.hogbaysoftware.com/posts/moby-dick-workout/ https://www.hogbaysoftware.com/posts/moby-dick-workout/). And then after that resize there's lots of background processing to refill a bunch of layout caches I guess. On the other hand resize is instant and only does work for visible text in Bike. I don't think the animations are expensive, but it's hard to test because that work happens in Mac OS window server and I'm not an expert there. If they really are a problem and you are on battery then you can turn off animations in preferences.