> I tried to get the layout transitions to animate, escalating it to an Apple Developer Support incident, but was basically told, “we’re aiming to reproduce the functionality of UICollectionView… but we’re not there yet.”
What a f###ing joke.
I admittedly haven't tried out NSCollectionView since 10.5, when it was, shall we say, not very good. But I remember they revamped it, maybe five years ago, to match the UICollectionView API. Do I remember correctly?
Frankly, UICollectionView failed to meet my animation demands as well. They weren't even able to conceive of the uses for animation I was attempting, for example on scroll, which they eventually copied for Messages.app on iOS.
Is the problem that they more or less completely abandoned development on AppKit?
Or is the problem cultural? I endured a lot from Apple employees and developers on Freenode and could attest to that.
The API may not support what I would do, perhaps requiring swizzling and subclassing, and I cannot be specific since I abandoned Mac development long ago. But if I were you, I would animate relatively. That is, I would use additive animations with a destination value of zero. I developed this pattern precisely for animating a flow layout like this.
It is important that on resize items only animate position when the number of columns change. Otherwise, item position should instantly change along with the mouse event. Relative animation works well for this.
I am not sure what I would do when switching from your regular to mini sized items, I would have to experiment. But if performance, code complexity, or time constraints prohibit it, relative animation also works well with instant changes to width in cases like this, an acceptable compromise.
There is also plenty that could be done with staggering, but that is much too involved to speculate about.