Having been at WWDC and played with it for a few weeks, I'm not sure I'd call LLVM a hands-down winner.
While there's a lot of win in terms of code readibility and the great interfaces it exposes if you're going to write an IDE that understands the code, I'm not convinced it's there yet in terms of binary performance.
My apps run around 5%-15% slower, on average, than the GCC -march= setting.
It's one of the main ones, but two additional ones, depending on the person, are: 1) some people don't like GNU and/or Stallman having influence on their OS, either for political reasons or due to personality clashes; and 2) some people don't like GCC's design as a technical matter.
Probably because the GCC architecture itself no longer allowed for more optimization. Or to put it another way, it had been optimized as much as economically possible. Trying to optimize it further would get us to the realm of diminishing returns. At this point it is easier and more cost effective to simply re-design the whole architecture which will inherently improve the performance. LLVM was designed from scratch with performance being a top priority.
Since Cocoa programming on the Mac, sometimes in the cocoa-dev list the question "how do I design interfaces in code instead of using IB?" popped up, and the general consensus was always: "why do you want to do that? You are fighting against the environment. Use IB".
I've tried designing UIs without IB. I went thorough years of mailing list archives, several questions on StackOverflow and I don't know how many blog posts. Trust me, writing an app without IB is a stupid, stupid idea. IB is central to Cocoa development.
Not seeing the problem with IB here. I use it extensively for generic UI elements, with custom views and windows, use it to target the FirstResponder, use it to hook up actions, connect controllers, and to bind objects together - all of things IB (and now Xcode 4) were made to handle.
- It's incredibly brittle. Good luck if you need to make significant changes to your hierarchy, or change that NSOutlineView of yours to an NSTableView. You'll have to rebuild and re-hook up all of the connections on an object. With no warnings or errors if anything is wrong. In HTML, you can just copy and paste, change some tags, and make some adjustments. Now HTML isn't ideal for application layout - but another markup language could be (MXML isn't bad).
- Doesn't play well with source control. Only one user can work on a .nib at once. Just yesterday another programmer and I both made changes to UI. Of course, it was completely unmergeable by machine or by hand - what do you expect when you have GUI generating a 7000-line file for relatively simple UI. So one of us had to re-do several hours of work. This isn't a problem with, say, HTML.
- Most significantly, it only solves a small part of the problem. It completely falls down when you're dealing with dynamic / variable UI - you'll have to resort to code anyway. And a lot of the layout you need to do is actually inside cells - say, trying to build a source list like iTunes, or a table view with icons inside of it. IB can't help here at all. Then, you end up laying out the actual UI in code. And what code it is:
Are you serious? This is 2010. You should not need to be manually calculating the positions of UI elements. There should be a layout language. HTML, MXML, whatever.
IB encourages you to use a very low level of abstraction. There's a lot of repetition, and the closed nature of the tool means it's very difficult to build up higher levels of abstraction. But then again, I guess Objective-C loves loves making programmers repeat themselves.
There's a reason most professionals don't use dreamweaver to make websites, either. And they are much the same.