Is it just me or does Apple’s previous acquisition of CoverFlow mean more than just its implementation into iTunes, or for that matter its inclusion in Leopard’s Finder? CoverFlow, the beautiful interface used in iTunes to let users flip through their album art, provides more than just a sleek way to view your albums; it actually provides a very usable and intuitive UI. For instance, CoverFlow on the iPhone just makes sense. Flick your finger and the covers go flying and stop by friction. It’s eye-candy, but a tried and true metaphor that works very well for computer OS’s.

Apple owns this great technology. I’m also assuming it has some strong patents protecting this, yet doesn’t it make sense for Apple to open this a bit. Shouldn’t all developers have access to CoverFlow in their apps. Something like an NSFlow class that lets developers create their own very easily. If Apple created the Aqua GUI and button sets, but then only let them be used in 1st Party Apple apps, the Mac OS would be dead. It’s like if Apple didn’t offer NSButton. We developers want and need NSFlow (just a possible name).

I see very little disadvantage to Apple. With Leopard’s move to a unified OS look, shouldn’t the opening of CoverFlow be right alongside it? All it will do is let a bunch of new apps look even cooler and more unified. That’s a big selling point for the Mac. If you can show potential buyers all the cool applications that have this sweet CoverFlow look, it only helps.

And in all honesty, the implementation and API can be very simple. I can see them having an object NSFlowItem, which will contain an NSImage pointing to the image to be displayed, an NSString for the name of the item, and a Selector pointing at the method to call when the item is selected. Then you just have NSFlow have a few methods like

-(void)setFlowItems:(NSArray *)items
Removes all items in the flow and sets the flow’s items to all the objects in the array.

-(void)addFlowItem:(NSFlowItem *)item
Adds an item to the flow, sorts the flow, and redraws the view.

Obviously there will be some remove methods and accessor methods like selectedIndex:, etc. The NSFlow can also have a delegate which will receive notifications when the NSFlow has been moved left or right or an item has been selected, etc.

I see this being extremely useful for developers and a fairly easy task for Apple’s dev team considering they’ve already written most of the code for iTunes and Finder.

I’d be really interested to hear other developers thoughts of agreement or disagreement, so please leave a comment with your opinion.