Designing GitHub for Mac

Interesting, and I think he lists indeed 2 things that are difficult in Cocoa:

- generate your interface in code; he dismisses IB in one sentence :-) He's right that complex UIs can't all be done in IB, but IMO the thing that's hard to learn is when to use and not use IB, and find the right balance (so yes, in the end, that's difficult)

- 'skinning' of Cocoa widgets - for better or for worse, built-in widgets are not designed to be customized very much

I can see how these 2 points are hard to get past when coming from html/css for instance.

So are these things more difficult than they need to be? By supporting more explicit customizing out of the box, Apple would have to add more hooks and settings in their widget classes, and then be forced to support those... All with the result of bringing more inconsistency in the UI of resulting apps. Instead, they prefer to spend their engineering effort into making the default widget look good and behave well and consistently. In other words, it would be more difficult for them to make it easier for you to customize the UI. Not saying it's good or bad, just trying to rationalize their perspective.

@charles Through their own apps and the apps that they choose for ADAs and prime App Store placement, Apple is promoting inconsistent interfaces that use custom widgets/skins and image files instead of actual drawing.

I can see where he's coming from: the web, with an influence from Twitter clients (which, while native, are very web-influenced). So yeah, for doing the kind of thing pervasive in web apps: styling/custom interfaces (and not just buttons, but visual infrastructure like borders and gradient backgrounds) and dynamic interfaces, Cocoa is indeed suboptimal (I guess that's the nice way to put it). That being said, I couldn't help spilling metaphorical coffee on my metaphorical monitor when I read "Cocoa is dying for a framework"; Cocoa is a framework, it is the framework; it's just that what he considers basics are not the basics (traditional buttons, fields and tables applications) Cocoa considers the "defaults". Cocoa could certainly be improved to provide default support for what he's trying to do (and then he could use Interface Builder again, and change would become easy), but I don't think Cocoa needs another framework on top of it (unless, maybe, it's Webkit).

To me it makes sense for Apple to reward applications that go "the extra mile", which build upon the understood defaults of Cocoa but don't stop there and add something that is not provided but makes sense. But then the logical thing to do is improve Cocoa/Interface Builder so that this improvement becomes better supported in Cocoa to benefit the platform (e.g. like they did with the Panic toolbar design), but they don't seem to have done this a lot. I hear there are some such improvements in Lion.

It's really a shame he couldn't get good performance with custom drawing. How come drawing gradients and shapes with Quartz isn't almost as efficient as loading prerendered bitmaps of same and blitting them? I don't get why drawing in code is painful, though; Quartz is concise enough that specifying the appearance with custom drawing code is almost declarative.

@michael true, the paradigm is changing, and they might be in fact adapting, see some of the changes in iOS SKDs, with more options for 'skinning' the UI. Not sure that will make it into OS X. For now, we are left with that paradox...

@Pierre Cocoa is supposed to be the framework, but I think some longtime developers may have ingrained that marketing a bit too much. In certain areas there really could be another framework on top (or better default behaviors). I mean the basics, not the custom UI stuff. As Neath writes, “The gap between simple example apps and a fully functional application is huge.” There are so many areas where you have to customize to get looks and behaviors that users deem standard. This has improved a lot since 10.0, but there’s still a lot more that could be done.

Heh, I realize Cocoa is not the be-all and end-all of frameworks (I used modern Carbon a bit), it's just the fact he said this without much of a qualification, as if Cocoa wasn't a framework; had he said something like "I know Cocoa is supposed to be a framework, but it sure doesn't look like one, it's dying for a modern app framework on top of it." or "Cocoa may be a framework, but it's a framework for circa 2000 applications, it's dying for a modern app framework on top of it.", it would have been fine.

Personally, I feel that an actual framework on top of Cocoa would be so high level that it would basically duplicate the web, so it probably indeed needs better (maybe opt-in) defaults to update itself to the user standards of the 2010's.