| When comparing Carbon and Cocoa, only a fool would choose to write an app in Carbon. But initially there were a few problems: - On old 90s hardware, Carbon could be faster (due to the C API) - Apple didn't invent AppKit or Objective-C. That technology was inherited from NeXT and from what I understand there was push-back both within Apple and from the Mac developer community about adopting a language with an unusual syntax that nobody used. Apple tried to transition Objective-C to a modern C++ style syntax, and failed. Apple tried to get developers to use Java with AppKit (hence, the name Cocoa) and failed. Apple tried to get developers to adopt garbage collection, and failed. In the end, they didn't need to do any of that. Mac developers eventually became quite enthusiastic about Objective-C and AppKit and it quickly because the one true way to write Mac apps. However, it took many years for Cocoa and AppKit to become fully formed. Up until 2009 and OS X 10.6, there were still many things that couldn't be done in Cocoa and required the Carbon APIs, mostly related to the Mac-specific features of the file system, like persistent file references, icons, metadata, etc. For example, if you want to implement a UI for copying a file, you're going to want to display a progress bar and have the ability to cancel the operation. Up until OS X 10.6, that simply couldn't be done with Cocoa (NSFileManager, NSURL, etc.). You had to use gnarly Carbon APIs. (Actually, it still can't be done with NSFileManager, but Apple added that ability to the Darwin file system APIs.) That's why the Finder was initially implemented in Carbon. And little bits if Carbon still live on in the modern 64-bit Mac world. If you want to implement global Hot Keys in your app you have to use the Carbon API and convert the Carbon key-codes to their AppKit equivalents. |