“Since Mac OS X shipped, announcements regarding new versions of software applications designed to run natively on the new OS have become a daily occurrence. Some of these announcements mention that the application is Cocoa-based while others mention that the application is Carbon-based. The smart developers mention neither, knowing that the average Mac user doesn’t know the difference and doesn’t care. Apple has been talking to developers about the benefits of Cocoa and as a result, many Mac users have started to get the idea that applications that are Cocoa-based are somehow better than applications that are Carbon-based. API or framework choices have much more impact on developers than on end users. This white paper explains what Carbon and Cocoa are, how they differ, and what impact they have on users of REALbasic.” Read the rest of the story at Real Software, developers of the Real Basic.
What is the Difference Between Carbon and Cocoa
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I much prefer Carbon apps to Cocoa apps. In fact I try to avoid Cocoa apps altogether. The only Cocoa app which I like thus far is OmniWeb 4.1.
There are various reasons I prefer Carbon apps, but there are two main reasons:
1) Some Cocoa apps assume file paths are constant.
2) I hate the behavior of NSLayoutManager.
The assumption of file paths being constant can only be fixed by changing the source so that either all file i/o is done exclusively by NSDocument objects, or the programmer uses non-Cocoa APIs in order to use FSRefs as file primitives instead of paths.
The NSLayoutManager problem could be fixed by Apple without any source or binary changes by 3rd parties. I’m not just going to bitch that NSLayoutManager doesn’t behave like mac text fields, but the current behavior is inferior. Nearly every time I select a line of text I do not want to select the trailing line feed. The behavior of Cocoa apps is such that it’s far too easy to select the linefeed when selecting right or down. Cocoa apps also make drag+drop text absolutely useless due to inserting a delay (selected linefeeds also get in the way). Either disable drag+drop text or enable it, the delay makes no sense and also makes it impossible to add a custom delay gesture which can be used for contextual menus.
Carbon apps can also use services (like BBEdit), but I’ve found them useless thus far because the kotheys keep changing. ugh
Cocoa is a lot better behaved since early OS X dev. releases when it behaved more like OPENSTEP or windows, but it has quite a way to go in my opinion.
isn’t this a lovely example of a marketing blurb? “should I care about all this if I use REALBasic? of course not”
Although I’m not an Objective-C dev (I personally like C++), I think that the Cocoa API is rather nice. In addition to just being nice, it gives the apps on the OS a complete feeling. There is a noticable difference between the two APIs, and is most noticable in handling of text.
I’m the first to admit it, but I’m a perfectionist and anal retentive when it comes to presentation. I want all my text anti-aliased (to an acceptable degree, 8px is just too small for it to work), and proper typography and typesetting on webpages, etc., and you cannot achieve this in Carbon. Notice how beautiful the text in OmniWeb is compared to IE. Or, when you type an IM message in Adium (AIM replacement), how the text automagically changes to the proper ligatures (fi is replaced by the fi ligature … it displays as only one character, but the underlying information notes that it is indeed two values).
Plus, please remember who this is coming from. REALBasic is implemented in Carbon, so if people think that Cocoa is the only way to go, they’re not going to use REALBasic. Also, there are some misconceptions in their article. There are some things that Cocoa accesses that Carbon cannot, such as better handling through Quartz, while QuickDraw is implemented, it is not native Quartz (as demonstrated by the AIM vs Adium and OmniWeb vs IE examples).
Wow, that was a bit long, but just my opinion. Let me also not that if you like the “everything’s an object” approach to OOP, then you can create Cocoa apps using Java.
— Rob
Objective-C (an all new language developed at NeXT).
I guess that depends what you mean by “developed”.
They didn’t actually invent the language.
…the only language that could communicate with Rhapsody was Objective-C (an all new language developed at NeXT).
This is incorrect in so many ways… I’ll be happy with this: NeXT did NOT develop Objective-C. Objective-C (circa 1983) predates NeXT (founded 1985) by some time.
It’s like saying Borland in the 1980s developed an all new language called Pascal (or even, say, UC Berkeley developed it in the 1970s).
In Cocoa :
– the mouse wheel is working everywhere
– the services are working in all apps
– the cursor is correctly displayed in all panels (save, open… when editing the name with the arrow)
– the filename can have more than 32 characters
– the arrows of sliders are working well (you can click on one and move to the other, it will work).
– the font panel is used instead of a long list of fonts in the main menu
– the texts are prettier
…
In Carbon :
– Some apps can have some of the Cocoa functionality, but not working everywhere and not working every time. For example IE can use the wheel of a mouse, but only on the main window (not working on Open panel ou Preferences panel..)
Actually, the typography in Carbon is correct and Cocoa is wrong – or to be more precise – Quickdraw is correct and Quartz is wrong. Quickdraw renders the fonts the way they were designed to render on screen, so it uses the hinting which a wise font designer gladly put in the ttf file for you in hours of hard work. Quartz on the other side believes that it knows better thant the font designer how a font should look like, thus ignores all the font hinting in the file and renders everything on the screen like it was a print preview. Which is wrong, the typefaces most commonly used on the web are specifically designed to be rendered with hints and not to be scaled up and down.
– the mouse wheel is working everywhere
– the services are working in all apps
– the cursor is correctly displayed in all panels (save, open… when editing the name with the arrow)
– the filename can have more than 32 characters
– the arrows of sliders are working well (you can click on one and move to the other, it will work).
– the font panel is used instead of a long list of fonts in the main menu
– the texts are prettier
Carbon applications can do the same, if the developer uses the API properly. Bad programs originate from bad programmers, not from APIs.
Internet Explorer is just a very bad example on how programs should not be written. If you want an example of good Carbon programming, take a look at <a href=”http://www.panic.com/audion/“>Audion.
Quickdraw renders the fonts the way they were designed to render on screen, so it uses the hinting which a wise font designer gladly put in the ttf file for you in hours of hard work. Quartz on the other side believes that it knows better thant the font designer how a font should look like, thus ignores all the font hinting in the file and renders everything on the screen like it was a print preview.
Not quite. Cocoa and OS X uses OpenType, which is an extension to ttf (IIRC; it may be a wholely different format, but quite similar). OpenType fonts have tables that list what ligatures can replace what collections or groups of characters. This is something that is built-in to the font, and available to any program that can access these tables. From what it looks like, Carbon apps do not use these tables natively, while every Cocoa app has them in use by default.
I’d use OS X on my PowerBook more often if Apple actually came through with their drivers. No accelerated video, and no hardware DVD decorder support makes it no fun to use.
This isn’t a bad overview of Carbon and Cocoa, but it really comes across like it’s designed to reassure existing and prospective REALbasic developers that the compiler’s use of Carbon rather than Cocoa is not really a limitation. If I were interested in developing with REALbasic I’d probably be mollified, but, well, I’m not.
What’s telling about the true motivations here, perhaps, is the dig he took at Objective-C. “Just look at Apple’s example currency converter and now do the same thing in REALbasic! See how much easier it is in RealBasic?” A-ha! The real battle here isn’t Cocoa versus Carbon, it’s <strong>REALbasic versus ProjectBuilder</strong>. He makes it sound like the Objective-C program is much longer and more complex, but given that Objective-C has a lot of Smalltalk-like high level constructs (and that we don’t have a REALbasic tutorial to compare it to), one suspects the “ease” is simply that REALbasic has the syntax of, well, BASIC.
By focusing on Carbon versus Cocoa, he can gloss over the features that Apple’s development tools have that REALbasic doesn’t–from formatter objects to localization to Cocoa’s concept of a “document-driven application” (if your application is focused on documents, like a word processor or spreadsheet, a lot of the work involved in opening, saving and managing documents and their displays is handled for you). And, oh yes, he doesn’t seem to mention that Apple’s RAD tools for Objective-C are free… and REALbasic isn’t.
While I don’t know a lot about Carbon/Cocoa, the author mentioned that the 68000 used in the original 1984 Mac was not powerful enough for preemptive multitasking.
The original Amiga, released only a year after the Mac and using that same 68000 processor had preemptive multitasking (but not memory protection).
Amiga had some help from the custom chipsets to help with multitasking since they took load off the CPU for certain tasks IIRC.
The custom chips in the amiga are for audio and video.
It had a copper and a blitter, the last one could blit
bitmap images independend from the processor, the copper
did some tricks with the display, like show this chunck of memory on that scanline.
These technigues found there way in the later videocards
we all know today.
Audio was limited to 4 channel 8 bits 🙂 But in those
days it was really nice.
The AmigaOS itself was getting faster which each release
as more functions were optimized in assembler.
(or the c comiler improved)
If you ran Shapeshifter, you could run MacOS in a window (or screen) as fast as the real machine on simular hardware.
MacOS always felt a lot slower then AmigaOS..
last version I tried was MacOS 7.5 or 7.6
Amiga had some help from the custom chipsets to help with multitasking since they took load off the CPU for certain tasks IIRC.
That doesn’t disagree with his point, though. His point though is that the problem with multitasking on the Mac was NOT the 68000, as the author alleged.
The problem was the design of Mac OS. Several OS’s that ran on the 68000 multitasked preemptively; OS-9 (which started on a less capable processor, the 6809) comes to mind. That was a realtime OS, too.
The custom chips in the amiga are for audio and video.
They also handle I/O and DMA.
IMHO no computer had as pleasant a feel to it as an Amiga. I’d still own one if I could do my work on it (research in mathematics). I’ve used classic Mac and mucho versions of Windows; now I have a Mac OS X iBook. Their design just seems to get in the way more often than help, and inelegantly at that…
V/GER must know why Carbon-based units infest Macintosh.
A lot of the complaints seem to be based around apps that aren’t properly ported over to Carbon from the Classic APIs. IE was ported enough to make it work under OS X. iMovie 2 is a straight port from the Classic version as well.
I am writing a new app from scratch using Carbon, and loving it. It is a good citizen under OS X, only using the CPU when an event tells me there is something to do. With a little good design, I have gotten a UI that is responsive under both OS 9 and OS X, and hasn’t locked up on me once.
Sure you can do the thing in Cocoa too, and possibly faster, but my mindset is a little more of a procedural one rather than object-oriented, so Carbon is better for my programming, and produces apps that are just as capable.