8

What is the difference between carbon and cocoa ? For what type of applications we should use carbon and for what type of applications we should use cocoa ? Which is the best of both for developing applications in Mac OS ?

srikanth rongali
  • 1,463
  • 4
  • 28
  • 53
  • 3
    This thread probably has the answers you're looking for: http://stackoverflow.com/questions/151711/carbon-vs-cocoa-is-carbon-a-dead-end-with-os-x – Stephen Jennings Dec 13 '09 at 07:06

4 Answers4

15

Short answer: For a new application, use Cocoa. Some legacy code may still use Carbon and if you don't need any new capabilities, it will continue to work.

Cocoa has an Objective-C API, and can be accessed from C and C++ code easily. Carbon is a pure-C API. There are both Cocoa and Carbon bindings for many other popular languages, but there are often some limitations.

Carbon is evolved from the original API for the original Apple Macintosh (and Apple Lisa) in the early 1980s. Specifically, when Mac OS X was released, Apple was unable to support some of the legacy Mac OS API functions, but provided a subset of legacy APIs called "Carbon", to ease the transition for developers who had pre-Mac OS X applications. They added thousands of new APIs and continued to fully support Carbon for several years, before finally deprecating it more recently. They have always said that Carbon is a dead-end and all developers should move to Cocoa.

Cocoa has evolved from the NextStep framework that Apple acquired and used as the basis to create Mac OS X. It's the "native" API for Mac OS X and the only way to access some of the newest capabilities.

dmazzoni
  • 12,866
  • 4
  • 38
  • 34
10

Carbon was created to ease the movement to and from Mac OS 8 and 9. If your code needs to run under OS 8 or 9, then Carbon is the way to go. (Source)

However, if your software is designed for OS X, then you should emphasize Cocoa over Carbon.

Chip Uni
  • 7,454
  • 1
  • 22
  • 29
4

Carbon is deprecated (it does not and will not exist in 64-bit).

For new application development, use Cocoa (I'm talking about native OS X application development the Apple-sactioned way. Obviously other alternative choices exist, such as Java, Python, Ruby, etc, which may be effective depending on your project type if a native UI is not required)

wadesworld
  • 13,535
  • 14
  • 60
  • 93
  • 7
    Cocoa and Carbon are APIs, not languages. Java, Python, and Ruby are not "alternatives" to Cocoa. While there are some serious caveats, you can access both Carbon and Cocoa from all three of those languages. – dmazzoni Dec 13 '09 at 07:32
  • 2
    Never said Cocoa and Carbon were languages. Additionally, Java, Python and Ruby are certainly alternatives to Cocoa-application development if your project does not require a native UI. My point was, there are other options *depending on his project type.* – wadesworld Dec 13 '09 at 07:37
  • 2
    @Wade You're still conflating APIs with languages. While Cocoa is indeed best used with Objective-C, Java, Python, and Ruby all have access to it as well. They are not "alternatives" to Cocoa. – phoebus Dec 13 '09 at 08:40
  • 1
    Huh? Cocoa _is_ an Objective-C API, not a Java, Python or Ruby one. It's written in Objective-C and used with Objective-C. It can be used from other languages though bridging, but that's more a bridge between those languages and Objective-C than a bridge specific to Cocoa. All those languages use Cocoa _through_ Objective-C, they are not equivalent to Objective-C regarding the Cocoa APIs. – Adrian Dec 13 '09 at 11:22
  • 2
    Guys, I understand PERFECTLY the difference between Cocoa and a language. I just didn't want to write a dissertation. My point was - for native application development in the Apple-sanctioned way, use Objective-C & Cocoa. If your needs are different, Java, Ruby or Python might solve your problem. I didn't want the original poster to think Obj-C/Coca was the ONLY solution to solve a problem. To be even more clear, Python & Ruby for instance have ways of accessing Cocoa. – wadesworld Dec 13 '09 at 15:54
0

It depends on the scope and the functions of the application you're going to develop. I'm going to be building an application that makes use of MacInTalk capabilities and the new OSX 10.7 international set of voices. The official documentation states that fine-tuning is provided only under Carbon APIs, while Cocoa APIs are more limited.

Specifically, these Speech channel settings are alterable via API in Carbon: rate, pitch, pitch modulation and volume attributes. This possibility seems to be unavailable via Cocoa.

On a side note, the most updated documentation of the Speech Synthesis Programming Guide dates back to 2006 and it might be the case that Cocoa access to the same functionality is out there, but it's not yet documented.

Anton Maria Prati
  • 181
  • 11