The beta version of iTunes 10.5 released to developers last week is the first version of iTunes to run in 64-bit mode. The distinction is perhaps a bit minor for an app like iTunes, but has been the source of much discussion over the years. What's perhaps of more significance is the belief that this 64-bit support must mean that iTunes has been ported from Carbon to Cocoa, though that line seems to be rather blurred.
The primary advantage afforded 64-bit applications is the ability to address more than 4GB of memory which can be a distinct advantage for applications which use large data sets. Adobe, for example, received some criticism in 2008 that their Photoshop products were slow to adopt 64-bit mode on the Mac. 64-bit Photoshop for Mac ultimately arrived with CS5.
The reason for the long delay was the fact that Apple dropped support for 64-bit mode in Carbon back in 2007, requiring developers to port their existing Carbon applications to Cocoa in order to take advantage of 64-bit mode. This primarily affected older applications such as Photoshop and iTunes which had existed prior to Mac OS X and were still using Carbon, Apple's legacy API. Meanwhile, Cocoa was Apple's native API for Mac OS X and offered some additional user interface advantages. For better or worse, many users saw Cocoa applications as superior to their Carbon counterparts due to historic baggage of many of the Carbon applications.
The latest iTunes 10.5 developer beta does run in 64-bit mode in Mac OS X Lion, but still runs in 32-bit mode in previous versions of Mac OS X. Discussions in the forum, however, point out that there is still some debate about the "Cocoa vs Carbon" status. Despite the changeup, iTunes reportedly feels very similar to the previous versions, and doesn't come with dramatic changes. So those hoping for a complete revamp will be disappointed.
A couple of notable changes, however, include the fact that iTunes for Lion now supports Full Screen Mode and also returns the close/minimize/maximize buttons to their usual horizontal location.
Top Rated Comments
(View all)I didn't realize that switching to Cocoa resulted in a palpable difference in an Application's UI :p
Actually, it does. If you go back to Xcode 3.2, open Interface Builder, and create a Carbon application window, the set of widgets it gives you to work with is largely different than when creating a Cocoa window. Also, the way the system draws windows is different between Cocoa and Carbon - for instance, Cocoa stretches the titlebar's gradient across the width of the titlebar while Carbon tiles it.And of course, features that we've taken for granted in Cocoa applications are not present in Carbon counterparts - at least without extra effort on the developer's part. These things include spell checking, grammar checking, the Command-Ctrl-D dictionary popup among several other things.
Also, while it's not true in all cases, many carbon applications have ancient codebases with years of code fragments and bloat scattered throughout, sometimes leading to a more "clunky" experience for the user.
I know this is only a beta, but I'm going to say this flat out: iTunes 10.5 is crap. Full screen mode is glitchy. Traffic lights don't perform properly when iTunes is behind another application (no scroll over effect). Not all of the scroll bars have that "rubber band/springy" effect. And, a host of other minor issues. Basically, it feels subpar for a native application.
Not only is it a beta, but it's a beta designed only for developers to test their stuff. Chill.
And you are either in breach of an NDA or using a pirated application.
Who the hell cares. You're on a website whose purpose is to post news about people leaking information.
Whether or not iTunes 10.5 is Cocoa depends on your definition, but let's check instead of speculating. It's easy to attach a debugger (returning from ptrace calls to avoid NOATTACH) and inject F-Script Anywhere. Using FSA, you can navigate the view hierarchy.
It turns out that iTunes 10.5 is Cocoa in that it uses AppKit windows containing views. The toolbar in Preferences is even an NSToolbar, and after enabling customization using FSA, you can even move the items around! Views in the main window seem to be NSView wrappers ("ITBackingHostView") for something implemented in C++ ("ITView"), presumably to be able to share code with Windows (for which I guess they use another wrapper).
So yes, it is Cocoa. Partially wrapping non-native controls.