Follow Slashdot stories on Twitter


Forgot your password?
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×
Apple Businesses

Which Coding Framework for Mac OS X ? 334

DrStrangeLoop asks: "I am in the progress of getting into coding for Mac OS X, and I am wondering which GUI framework/language i should focus on. Apparantly, there are at least three options: the Cocoa Objective-C API [I don't want to learn Objective-c, but it seems that's how Apple wants me to code], the Cocoa Java API [gets compiled to PPC binaries, lots of APIs available [think Google], but absolutely no decent documentation to be found] and Swing Java classes [look 'n feel of Cocoa, but portable]. However, the most important feature for me is a clean and easy IPC with BSD layer processes. I figure sockets will work with all options, but what about the other mechanisms? Any suggestions?" Update: 10/13 22:08 GMT by C :For those curious about the Cocoa/Carbon debate, you can find an article that discusses this very issue, here. Thanks to the folks over at Freenode's #macdev for providing the link.
This discussion has been archived. No new comments can be posted.

Which Coding Framework for Mac OS X ?

Comments Filter:
  • by ageitgey (216346) on Sunday October 13, 2002 @02:20PM (#4441320) Homepage
    I think you are missing a vital point. You can't just say "I'm getting into coding, is X or Y better?"

    What is it exactly that you are writing? If you are writing a 3-D game, then the Java-Cocoa API is probably out. If you are porting your java-based massive application to Mac, than ObjC is probably out.

    Basically, choose the one that fits your application's needs. If you just want to mess around though, go with Java-Cocoa just because it's more immediate.
  • by akac (571059) on Sunday October 13, 2002 @02:26PM (#4441349) Homepage
    Though I prefer Cocoa, Carbon is just as native as Cocoa is.
  • use Cocoa (Score:5, Insightful)

    by d3xt3r (527989) on Sunday October 13, 2002 @02:40PM (#4441406)
    As another person just getting into the OS X programming game, I was wondering the same thing. After looking around Apple's web site, and playing around with the different frameworks, it became apparent to me the Cocoa + Obj-C was the way to go.

    Objective C is easy to learn and can be intermixed in the same source files with C++ (and obviously C). It's one of those "use the right tools for the right job" things. The GUI is most easily programmed with Cocoa using Objective-C, but if there's a nice library you want to utilize that's written in C++, there's nothing stopping you from using it.

    Once you get comfortable with Objective-C, you realize that it is almost as easy to use as Java.

    Now for the alternatives:

    1. Java Swing on OS X: I have a database tool that I am creating as a cross platform app that is written entirely in Java using Swing. It runs beautifully on OS X and looks (almost out-of-the-box) like a native application. However, it is still slower than a native app. Users who expect a snappy GUI will be disappointed with a Java Swing app on OS X. While it performs admirably better on OS X than Windows or Linux, I'd stay away from Java Swing if cross-platform binary compatability is not a major requirement.
    2. Carbon: From what I could understand from Apple's web site, Carbon exits for one reason: to give developers a migration path from OS 9 to OS X. Carbon is a gateway API since Cocoa simply is unsupported on OS 9. It is obvious that Apple's go-forward plans are for Cocoa and Objective-C.
    3. Java and Interface Builder: I serisouly recommend not using this combination. You are going to force your Mac OS X only application to run in a Java VM without the cross-platform benefits of Java. This approach only seems logical if your backend is written Java and you want to create native GUIs on all platforms. I would stay away from this for an OS X only application.
  • Re:Mozilla (Score:5, Insightful)

    by Lao-Tzu (12740) on Sunday October 13, 2002 @02:41PM (#4441410) Homepage

    As a co-author and currently sole developer of a Mozilla component application, I feel I'm qualified to voice an opinion on this. (MOOzilla [www.moo.] being the application)

    Mozilla is really damn cool. You can do some amazing things by combining existing Mozilla code with your application. For example, yesterday I discovered a way to dump an entire MOO/MUD session into an HTML file by using a function in nsContentAreaUtils.js. This was funky. It was not, however, exactly what I wanted, so I now need to write similar code myself. The point is that Mozilla is great...

    But I can't see using it for anything that doesn't somehow relate to web browsing or networking. I know there have been efforts to do elaborate things like writting Office suites in Mozilla, but I don't think it's really feasible because the API availble through XPCOM is more geared towards this kind of web-based development. In MFC, for example, you have access to beautiful serialization and dynamic runtime creation and other nifty stuff that makes coding easy.

  • by Sahib! (11033) on Sunday October 13, 2002 @02:43PM (#4441422) Homepage

    Make no mistake - nobody's going to code the next operatig (sic) system in [Objective C].

    Funny, that's just what Apple did.
  • by Have Blue (616) on Sunday October 13, 2002 @02:44PM (#4441426) Homepage
    If you are developing a GUI application from scratch and portability is not a concern, learn Cocoa. Interface Builder is hands down the best GUI-building tool in the industry.

    If you are already a C++ expert and have no desire/resources to learn a whole new language, or you want to use a more traditional toolkit that's easier to port, or you are porting an app written for Windows or OS 9, use Carbon. It's essentially identical to the Mac Toolbox, with a few types changed and memory hacks replaced with accessors.

    If portability is very important, use Java. OS X's implementation of the various Java GUI toolkits provides the Aqua interface automaticaly, as well.

    It is possible to use all of OS X's native APIs (Cocoa, Carbon, and Posix) in the same project, if you really must. The libraries are already quite interdependent and any potential conflicts are noted in the documentation (i.e. don't use NSThreads and pthreads at the same time).
  • by critic666 (317551) on Sunday October 13, 2002 @02:48PM (#4441440)
    Truthfully, Objective-C takes ~2 hours to learn. In fact, check out the first chapter of my (needing-to-be-updated) tutorial, Using Objective-C++ on Mac OS X here [] for a comparison of ObjC to C++.

    I used to be a C++ programmer, and then I spent some time playing w/ Cocoa, learning how the system works, and now, if Cocoa goes away, I think I'll quit programming. Its simple elegance and power is astounding, and freeze-dried objects in the NIBs are just cool. Just play w/ some of the tutorials (e.g. currency converter) before you discount it.

    However, Cocoa-Java is kind of worthless. It's a kludge, and some of Cocoa's coolness comes from the weak-typing (id is slick--sort of a void* you can send messages to). Take a look @ cocoadevcentral, too.

    Carbon, though, is klunky by comparison. Programming for that is just like programming for Windows/'s an API, and you can do nifty stuff, but it's not slick. Cocoa is slick. 'nuff said :)

  • Use Cocoa (Score:3, Insightful)

    by Anonymous Coward on Sunday October 13, 2002 @02:54PM (#4441464)
    Let's get this straight: you want to learn an entire framework, and your primary complaint is about learning a minor extension to C?.

    Objective-C is a small, elegant object-oriented version of C. It's very easy to learn, easy to document, and easy to modify. Compared to the size of Carbon and Cocoa, this is absolutely the least important part of your framework-learning experience.

    So here's the deal. Cocoa is an elegant, brilliant, clean and simple framework derived from the (rightly praised) NeXTSTEP/OpenStep libraries. Carbon is an evily patched hulking pile of OS9-compatible goo. The difference between these two libraries could not be more stark.

    Apple's proclamations otherwise (made to make Adobe and Microsoft happy), Carbon exists for exactly one purpose: as a porting library for legacy code. The nastiness of Carbon lends some insight into the hideousness of developing for OS9, one of the reasons Apple simply could not get the Copeland project working.

    Use Cocoa.

  • by lemkebeth (568887) on Sunday October 13, 2002 @02:56PM (#4441475)

    You wrote:

    Truth hurts, doesn't it, fanboys? If it isn't true, explain to me why what are free utilities for Windows machines are $20-$30 extortionware for the Mac.

    :stares in disbelief:

    um actually, stuff that is Free under the MacOS/MacOS X costs money on Windows for the same thing from another developer.

    I use Windows at work and getting the same function as provided by a freeware Mac app costs money on Windows.

    Mind you there are always exceptions to the rule.

    My theory is that all Windows developers code fro money while some developers on other platforms code to give something back or just for the love of the platform (be it Linux, BSD, Mac, or something else).

  • by Twirlip of the Mists (615030) <> on Sunday October 13, 2002 @02:59PM (#4441484)
    Cocoa is alright, except that it uses Objective C. Objective C is a bastard child of C and C++, and it doesn't really mesh too well.

    Spoken like a true C++ programmer. Objective C is not a "bastard child of C and C++;" in fact, Objective C and C++ share nothing in common at all except for the C language, of which both are supersets.

    Objective C is a much simpler language than C++. Oft-troublesome C++ features like templates, overloading, multiple inheritance, virtual functions, and "friends" aren't implemented in Objective C. Mastering C++ can take years, while mastering Objective C is a task for a couple of afternoons.

    Now Nextstep, that's a whole different ballgame. ;)

    No, it's not. Cocoa is essentially NextStep.
  • by Twirlip of the Mists (615030) <> on Sunday October 13, 2002 @03:03PM (#4441503)
    A well-designed application will separate logic from presentation, at least to some extent. Because the Cocoa API is most easily called from Objective C, programmers are free to write their logic in straight ANSI C, and use Cocoa user interfaces for the presentation layer.

    The same is true of Java; in fact, many programmers may prefer this. You can write all your application logic in pure Java, and use Cocoa/Java code for the user interface. If the need ever arises to implement a different user interface toolkit, you can just replace the Cocoa/Java code-- which will probably be only a small fraction of your total code base-- with Swing/Java or whatever you please.

    The important thing to remember, here, is that, on the Mac platform, native GUI applications are always-- always-- superior to non-native GUI applications. If you don't use native APIs for the interface, you're crippling yourself from the outset.
  • Why not wxWindows? (Score:3, Insightful)

    by kollivier (449524) on Sunday October 13, 2002 @03:05PM (#4441514)
    wxWindows is a cross-platform GUI toolkit which emulates the native look n feel of the platform it is running on. It's written in C/C++ and runs on Windows, Mac, and Linux. The url is []. It gives you the cross-platform benefits of Java, as well as access to the underlying BSD layer.

    I have started using wxPython (Python bindings for wxWindows) as my primary development platform, and am quite happy with it. It enables me to develop my application on OS X, even though my primary target audience is using Windows. =)
  • by Dr. Awktagon (233360) on Sunday October 13, 2002 @03:15PM (#4441551) Homepage

    I just started programming Mac OS X (I did a little Mac programming in the System 7 days and HATED it, since I was programming Unix at the time). But OS X is great.

    I'm focusing on Cocoa myself, but here are some data points for you:

    Objective-C is a lovely language. I looked it at back in the NeXT days and thought "cute, but it'll disappear and be replaced by a better version of C++". Well, Objective-C is still here, and C++ never got any "better". So you ought to learn Objective-C, it's very much like Smalltalk mixed with C, very elegant. I might start writing Linux and BSD programs in it. Also, it interfaces easily with the BSD side of Mac OS X. For instance, you want math libraries? You just use the standard math.h stuff! That's nice.

    Don't use the Java Cocoa stuff. It STINKS. I think they just added it for a "bullet point". The documentation isn't as complete. It's very slow. Objective-C is a nicer language anyway, since it is dynamic. With Java you have to use a lot of reflection hacks to get the same results, not nearly as elegant.

    Java DOES NOT (correct me if I'm wrong) compile to native code with ProjectBuilder. ProjectBuilder simply wraps a launcher around the java bytecode. If you drill down into the application package, you'll find the regular jar files.

    The use of the Java Swing (non-Cocoa) stuff is simply to get your existing Java apps up and running fast. It took me just a few minutes to turn a Java program I wrote on Linux with Forte into a double-clickable (but slow) Mac OS application. Don't bother using this for new stuff. Your program might LOOK like an Aqua app, but it's really Swing.

    Carbon let's you use C/C++. But it isn't a "compatibility layer" .. it's not obsolete or "going away". It's simply a cleaned-up version of the original Mac API. So if you choose this route, don't feel like you'll have to stop using it one day or something. I think Apple will support it indefinitely, alongside Cocoa.

    Cocoa is a little slower than Carbon, because Objective-C is a dynamic language, and it has to decide things at run-time (like, say, Perl). Not a big deal these days, but raw speed is not a selling point of Cocoa GUIs.

    AppleScript Studio: if you like applescript, you can write full applications in it. Just like on Linux you might want to throw together a simple Python script, etc., with a GUI. It doesn't hurt to learn applescript, especially if your Cocoa apps will be scriptable.

    Interface Builder is just soil-your-pants awesome and let's you create, instantiate, and hook together non-GUI objects, right along with GUI objects. Also note that IB actually creates the GUI and other objects and serializes them to a disk file. It doesn't create any code or do any other tricks. And XML is used throughout for properties, etc..

    So IMO your best choices are: Cocoa/Objective-C, or Carbon/C (or C++, blech). And I think everyone should learn Objective-C .. I'd like to see it used more for non-Mac stuff too.

    Everything you need, including books and tutorials, comes on the Developer CD. Go through the Cocoa/ObjC tutorial.

    Also note that if you sign up for the Apple Developer stuff, you have to agree to some pretty disgusting terms, including giving Apple the right to search your place of business on 24 hours notice. I shit you not.

  • by relay_mod (525998) on Sunday October 13, 2002 @03:25PM (#4441594)
    First of all, there's a "fourth" alternative that you did not mention: Carbon. It's a C API that represents a subset of the old Mac OS 9 APIs. It will give you access to Cocoa and CoreGraphics goodies while also giving you access to all of the wonderful Mach and BSD APIs.

    However, Carbon is no fun, IMHO. It's just not as easy to work with as something like Cocoa or Swing.

    Second, why do you say that Cocoa/Java is not well documented? Just look at and read all about it... Besides, all Obj-C Cocoa APIs have equivalents in Cocoa/Java. So it shouldn't be that hard.

    But, why use Java? Maybe you like it, in which case, go for it... But I think that if you have C and C++ experience you'll find Objective-C to be much more robust for Mac programming, simply because: 1) you can learn it quickly if you already know C/C++, and 2) you get a well thought-out API (Cocoa, formerly NeXT's AppKit) with access (both via Objective-C and via libc and other C APIs) to Mach, BSD, and Mac OS X specific goodies.

    And, for the love of all that is good, pure, and holy, don't use Swing. It's disgusting. Someone needs to beat it into the ground and start from scratch. The only reason that I would see for using it (and, granted, it's a good reason) is for portability... But in that case, I highly recommend Qt ( It works nicely on Windows, Linux, and Mac OS X... Only problem is it isn't necessarily free. =(

    Personally, I learned Objective-C in a couple of evenings after reading Apple's (formerly NeXT's) excellent book on Objective-C. It's available for download in PDF format from

    So I say go for that, I'm sure you'll be impressed with the results you get.
  • by tim1724 (28482) on Sunday October 13, 2002 @04:14PM (#4441804) Homepage Journal

    There are two separate issues here: which GUI toolkit to use, and whch language to use. First, choose the GUI toolkit, and then choose one of the programming languages which can be used with that toolkit.

    1. Choose a GUI toolkit
      • Carbon - a cleaned-up version of the original Macintosh Toolbox. It's big and complicated (as should be expected for something which has been evolving over 18 years) and may be somewhat annoying if you don't have previous Mac Toolbox experience.
      • Cocoa - the OpenStep API with a few new features. Clean and simple object-oriented interface designed around the Objective C language. Good for rapid development of GUIs.
      • Swing - Apple provides a Mac OS X implementation of Swing. With a little work, you can make a Swing program look almost native. (But not quite.. a few things end up looking or behaving slightly wrong.) A good choice if you want cross-platform Java code.
      • QT - The Mac OS X version is based on Carbon, so it should look like any native program. A good choice for cross-platform portability.
      • Tk - as in Tcl/Tk .. there's a Carbon port of Tk, but I've had some problems with it.
      • other cross-platform toolkits - There are a few others (wxWindows, for exmaple) but I don't know much about them. As far as I know, they're all built on top of Carbon.
      • Mac-specific libraries built on top of Carbon - things like PowerPlant (a C++ library from Metrowerks) make dealing with Carbon a bit easier.
    2. Choose a language

      Most of the toolkits support multiple languages.

      • Carbon: It's intended to be used from C (although you'll still find a few remnants of its Pascal roots) so it's not object oriented. You can use it from C, C++ (directly or via object-oriented layers like PowerPlant), RealBASIC, and probably a few others.
      • Cocoa: It was designed around the Objective C language, but Apple also provides Java bindings. Java isn't a particularly good fit for Cocoa (better than C++ would be, though) so I don't recommend it. There is a Perl binding called CamelBones which works rather well (Perl and Cocoa go together very well in my opinion). I think Python and Ruby bindings may be available as well.

    For new development, I'd strongly recommend using Cocoa with Objective C. Don't be afraid of Objective C! It's a very simple extension to plain old ANSI C. The additional syntax is minimal (unlike C++) and most of the code you write will be plain old C. Once you've learned Cocoa using Objective C, you may want to use it in Perl via CamelBones. But I'd strongly recommend using Objective C to learn Cocoa, otherwise you won't understand a lot of the reasons why things work the way they do. Don't use Cocoa with Java, unless you don't know C. And even then I'd recommand learning C so you can use Cocoa with ObjC.

    If you want a plain old non-OO API, Carbon isn't all that bad. You'll need to get a good reference, as there are a lot of functions and types to learn about. (Whereas Cocoa is predictable enough that you can usually guess method names!) Or you can use one of the C++-based wrappers such as QT or PowerPlant.

  • my experience (Score:4, Insightful)

    by g4dget (579145) on Sunday October 13, 2002 @05:46PM (#4442146)
    Unfortunately, there really is no ideal solution.

    I would not be scared of learning Objective-C--it is a very simple language and easy to learn, and its object model is very convenient. But in other ways, Cocoa using Objective-C is a somewhat outdated programming environment: the GUI design tools were great in the 1980's, but they are pretty dated by today's standards. And resource management in Objective-C and Cocoa is a lot more work and a lot more error prone than in Java or C++. On the plus side, Cocoa is what Apple really wants you to use, and that's where they seem to be putting a lot of their efforts.

    Cocoa using Java is probably in a certain sense "the best" programming environment for the Mac: it's modern, easy to develop in, and mostly safe. It's also pretty well supported. But it retains many of the warts of the Cocoa APIs and, as you observed, is not all that well documented.

    With either Cocoa-based solution, you also have to ask yourself whether you believe that Cocoa has a future and whether it's worth learning it. I don't see much of a future for Cocoa, at least in its current form. Apple has made no moves to standardize it or open it up, so it is Mac only. Even if Apple pushed for more widespread adoption, they'd have to make big changes to make it palatable to industry, like adding precise garbage collection and better error checking to Objective-C, with the resulting changes to the APIs. An example of work in that direction can be found here [] (yes, that is "", but it's a site about programming, really).

    Swing Java is probably the least hassle: it's well documented, it works very well on Macintosh, and you still get the native look-and-feel. It has modern resource management and modern layout management. Knowing Swing is useful and helps you on other platforms as well. And its object system is fairly similar to that of Objective-C. But some of the more advanced features have been buggy in the past (e.g., audio input, etc.). You can, however, combine Swing and Cocoa APIs, using Swing for the GUI and dropping down into native APIs only when Sun's cross-platform APIs fail you.

    If you use one of the Java-based solutions but find the Java type system too constraining, you can use Jython [], a Java-based implementation of Python. You can choose to run it interactively or compiled. It's great for exploring the Cocoa APIs (or the Swing APIs).

    Another choice you may want to consider is wxWindows []. Recent versions run very well on MacOSX and look native. If you want to see an example of an application written in wxWindows, take a look at Audacity [].

    I tried all these different approaches, and I ended up doing most of my Mac programming in Java/Swing and wxWindows.

  • by sweetleaf (128859) on Sunday October 13, 2002 @06:08PM (#4442225)
    This is truly absurd. You will _not_ be a master of C in two days. You will be the programming equivalent of a tourist speaking broken english with a travel dictionary.

    C, like any language, has its idioms and design patterns and these will take time to learn. Buying a book like K&R will help but I imagine there are more useful introductions to C. K&R is an incredibly terse, albeit a useful reference - and iirc it does not have much of the c library spelled out in detail)

    In summary, C is great, but don't expect to be a master of it anytime soon. And anyone who claims they are a master after 2 days is not.
  • by BitGeek (19506) on Sunday October 13, 2002 @07:19PM (#4442433) Homepage

    Cocoa puts you in the MVC pattern, meaning that you have rather good portability if you decide to go to a different view-- just subclass your controler and tie it to the new UI.

    Objective-C is portable because GCC is portable.
  • by BitGeek (19506) on Sunday October 13, 2002 @07:52PM (#4442518) Homepage

    Carbon only exists to support people who have existing Mac OS applications that they want to move to OS X.

    If you're beginning, learn Objective C and use cocoa.

    There is no reason to use carbon for new applications. You can access every API that exists in carbon from within cocoa apps and objective-c, but the reverse isn't true.

    With Cocoa you get everything Carbon has, but with Carbon you don't get everyhting Cocoa has-- especially the superiority of Objective-C and the Appkit and Foundation frameworks.

    Anything you really need to do, you can do in carbon, its just a lot harder.

    There's no reason not to use Cocoa for Mac applications.

  • Re:Mozilla (Score:1, Insightful)

    by Anonymous Coward on Monday October 14, 2002 @03:28AM (#4444181)
    Mac users want native apps. XUL apps don't feel like proper native OS X apps. This explains why Chimera (Cocoa front end, Gecko back end) has become so popular so fast.

    (More Chimera bugs are resolved as DUPLICATE than as FIXED, which clearly indicates that Chimera is popular. :-)
  • by Anonymous Coward on Monday October 14, 2002 @06:43AM (#4444571)
    > There's no reason not to use Cocoa for Mac applications.

    Unless you also want to tap into the legacy market -- there are still a lot of OS 8, 9 machines out there....

Related Links Top of the: day, week, month.

Real Programs don't use shared text. Otherwise, how can they use functions for scratch space after they are finished calling them?