Dark Side of the Mac: Appearance and Materials
Frankly, I’m not sure I trust Apple to support this appearance API over time.  They’ve been down this road before.<p>It’s kind of funny/sad to see how Apple operates with APIs.  None of these concepts are really “new”: they were <i>there</i>, in Carbon, prior to Mac OS 8, in the days when that OS was meant to support really elaborate themes.<p>The original theme APIs were huge, and 3rd parties were expected to adopt them as needed (e.g. using appropriate theme selectors for fonts and background patterns).  For about a year, things looked really cool: you could create a great Platinum-esque UI for any custom control, and it would fit right in.<p>Then, they threw it ALL away for Mac OS X, ironically right about the time when an appearance-agnostic API would make a lot of sense.  They didn’t even bother to update their API implementation to ease migration: really trivial changes that would have been helpful, like “update the damned font/color/pattern value returned for X to resemble Aqua”, were not done.  This meant that an app full of seemingly-appearance-agnostic code would look like <i>crap</i> under Aqua, and you had to <i>rip it all out</i>.<p>And it’s not like Mac OS X didn’t change its look.  Heck, for a <i>long</i> time you could find 3rd party app bundles chock full of images that were there <i>just</i> to implement the Apple-Look-and-Feel-of-the-Week, because the SDK didn’t offer <i>any</i> reasonable way to do half of what they came up with.<p>So yeah, <i>14 versions later</i>, the Mac wants to be appearance-agnostic again.  Sounds great.  My advice: always have the option of doing your own UI as a backup.