macOS Newbie question: Cocoa vs. Carbon from user perspective

[akm3]

Hey, I see lots of threads where people say something like "I hope iTunes 9 is Cocoa based" or "this would be a great app but they need to get off of Carbon", etc, etc.

As a user, I've never thought 'wow, this app is Carbon yuck.' Can someone explain to me why anybody cares which framework their app was created in? (Not counting that 64bit now equals Cocoa by default, and they may want 64bit applications)

From a USER perspective what does Cocoa vs. Carbon matter?

 

[Catfish_Man]

It doesn't matter much. There's a tendency for Carbon apps to not be as nice for two main reasons: they're often ports from other platforms, and it's much harder to write Carbon apps.

Going forward though, Carbon apps will effectively get worse and worse relative to their Cocoa brethren. No 64 bit support, no QTKit, no Core Animation, etc... new APIs will tend to be Cocoa-only.

 

[lee1210]

If apple makes a carbon app, the interface is probably going to be more consistent with how things are "supposed" to look in OS X. This is, from my perspective, where things often go wrong with carbon apps. People build their own controls, etc. and things just don't look and feel consistent.

Beyond that, I don't really know the difference. You don't really feel an impact of someone using a deprecated method or API until it breaks terribly with an OS update. Again, apple wouldn't break itunes with an OS update (or they'd ship it with a new version of itunes, etc.).

There may be some things, like having to load some libraries into memory, that might be avoided by having a "cocoa-only" system, with all of the shared libraries in memory once, etc. but most users probably aren't going to notice a few MB of memory used for a library.

-Lee

 

[gnasher729]

Hey, I see lots of threads where people say something like "I hope iTunes 9 is Cocoa based" or "this would be a great app but they need to get off of Carbon", etc, etc.

As a user, I've never thought 'wow, this app is Carbon yuck.' Can someone explain to me why anybody cares which framework their app was created in? (Not counting that 64bit now equals Cocoa by default, and they may want 64bit applications)

From a USER perspective what does Cocoa vs. Carbon matter?

It's mostly fanboyism. People who actually write code know that writing Cocoa applications takes less effort than writing Carbon applications, but leaving a Carbon application alone takes much much much less effort than rewriting it in Cocoa. People who want to replace perfectly good Carbon code with Cocoa are the same people who convert MP3 files to AAC because they think AAC sounds better.

By the way, there were always many things that were available in Carbon but not in Cocoa. Over time, Apple has taken all these things and declared them to belong to "CoreFoundation" or "CoreServices", and not part of Carbon anymore. So those parts of Carbon will stay around for a very, very long time; they are just not called Carbon anymore.

 

[Sander]

So you can see how old a program is by the APIs it uses. This is called "carbon dating".

 

[MorphingDragon]

Carbon was designed to port Apps over from Mac OS Classic. Cocoa was designed during the NeXTSTEP Era and was more advanced than anything else in existence at the time. At a programming level, Cocoa is better. At a user level, just use Photoshop and see for yourself how a Carbon app works.

 

[gnasher729]

Carbon was designed to port Apps over from Mac OS Classic. Cocoa was designed during the NeXTSTEP Era and was more advanced than anything else in existence at the time. At a programming level, Cocoa is better. At a user level, just use Photoshop and see for yourself how a Carbon app works.

And surely you can give an example of something that doesn't work well in Photoshop and would work better if it was written using Cocoa?

 

[yoavcs]

And surely you can give an example of something that doesn't work well in Photoshop and would work better if it was written using Cocoa?

Oh come now Gnasher, let us not be hypocrites.

Yes, it is true that the user experience is not determined by means of the toolkit used to program an application. But. We both know that Cocoa automates so much more of the UI creation process, and gives it so much more consistency that in general, as a whole, Cocoa based apps will tend to have the nicer, more consistent, more Mac-like UI as opposed to Carbon apps.

Add to that that most non-Mac programmers porting over non-Mac programs have used Carbon in the past, and you end up with the "myth" of Cocoa based apps being more Mac-like and nicer.

 

[After G]

And surely you can give an example of something that doesn't work well in Photoshop and would work better if it was written using Cocoa?

Try and compare Photoshop (Carbon) and Pixelmator (Cocoa). Of course Photoshop has more features, but for the features that line up, I'd argue that Pixelmator does a lot of them faster and/or better, given equal experience with both apps.

 

[foidulus]

Actually there are differences in the end user experience

but honestly they are things that a lot of mac users don't even know are there. For instance, all Cocoa text fields have an automatic undo, but Carbon(and Java for what its worth) don't have that capability built-in.

Apple doesn't actually publicize a lot of those little features largely because they don't want to have to try to teach consumers what the difference is. I guess they could implement in Carbon, but Apple is trying as hard as they can to bury Carbon(at least for GUIs anyway)