> it took them about 5 years too long to transition from Carbon to Cocoa, even though it was clear from the very first OS X version that Carbon was going to be replaced and would never have a 64-bit version
Yet, they still managed to do it before Apple got around to making iTunes use Cocoa ("oh, the irony", right?). The reality of the situtuation is that sometimes, even for flagship products, even for first-party products, sometimes portability is a critical concern, and Cocoa's reliance on Objective-C makes it very difficult to nigh-unto-impossible to not simply end up with tons of code duplication.
I am not certain what you mean by "C code runs on Cocoa": "Cocoa" describes a set of Objective-C libraries that form a framework developers can use to build applications for Mac OS X. While you can technically drop to the Objective-C runtime functions (the Objective-C equivalent of JNI) the result is often horrific.
When using Cocoa, you will find yourself constantly needing your data in the form of some random Objective-C classes. Carbon, on the other hand, stores all of its core data structures in C objects defined by a library called CoreFoundation.
This library, CoreFoundation, is something that you actually will find a copy of along with your Windows version of iTunes in the form of CoreFoundation.dll. Along with another few easily ported C libraries, this allowed iTunes to maintain the same networking and storage backends on Windows and Mac OS X.
Yet, they still managed to do it before Apple got around to making iTunes use Cocoa ("oh, the irony", right?). The reality of the situtuation is that sometimes, even for flagship products, even for first-party products, sometimes portability is a critical concern, and Cocoa's reliance on Objective-C makes it very difficult to nigh-unto-impossible to not simply end up with tons of code duplication.