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/). 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.
Probably very little if it is built on top of CoreAnimation, since that set of OS APIs is extremely heavily optimized specifically to enable animation-rich UIs that are light in terms of CPU and battery use.
Indeed. As far as I know, Core Animation was originally created as part of work on the first version of iOS (née iPhoneOS), where the target device, the original iPhone, was pretty severely memory and CPU constrained.
> [The] advent of Core Animation probably means that we'll have to endure some amount of gratuitously animated software created by "overly enthusiastic" developers. But the same was true during the introduction of styled text and color graphics. Mac developers learn quickly, and Mac users are good at rewarding restraint and punishing excess.
Right, it was introduced publicly as an API in Mac OS X Leopard, but my understanding has always been that it was actually conceived as part of iPhoneOS, then ported to Mac as well. The iPhone shipped a few months before Leopard, though of course UIKit wasn’t made public until the next year when the iPhone SDK was first released.
There’s a similar story around SwiftUI. It was initially created by the Apple Watch team at Apple, then extended to all the other OSes (all this was long before it was made public).
CALayer is part of the OS toolkit, so probably not much. It’s the same system the OS itself uses, so probably a shared lib, and it’s heavily optimised. Similar to animating your web page with only CSS animations. It’s all baked into the existing rendering system already.
If anyone digs in and profiles Bike 1.0 you'll unfortunately find that it is wasting some CPU with a timer. This will be fixed soon and is not related to underlying architecture or animations. It's me coalescing events from user defaults with a Combine API that I didn't fully understand.
