Slashdot Mirror


Which Coding Framework for Mac OS X ?

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.

8 of 327 comments (clear)

  1. Seems like you answered the question yourself. by tqbf · · Score: 5, Interesting
    If you need "clean and easy" integration with "BSD IPC" (the native programming interface of the underlying Darwin operating system), you need to be able to use its C-language calling interface. Of the 3 kits you mentioned, Cocoa/Objective-C is the only one that offers that.

    The ready-made integration offered by your two Java alternatives may not be useful for hardcore I/O anyways. How do you get a handle on an fd-based resource (/dev/bpf*, for instance) and then integrate the fd with your event loop?

    My moving-forward plan has been to maintain my application logic in standard C/C++, and use Cocoa/ObjC to build UI (and nothing else) on top of that. Since most good BSD code is asynchronous, and Cocoa/CoreFoundation lets you control the event loop at the "select()" level, this works fine for me.

  2. Mozilla by Fished · · Score: 5, Interesting
    I asked myself the same question a few months ago, and came to the conclusion that unless/until I have an application that requires a native API, I would do everything in Mozilla. In practice, this means a combination of XPCOM, XUL, RDF and javascript. It's like developing a really advanced web page, but you're not stuck in a browser framework.

    Several advantages:

    1. Easy cross platform. Your app will run on any platform Mozilla/Netscape run on.
    2. Easy development. Subjectively, development goes a lot faster than under a traditional framework.
    3. Something you probably already know: most people I know who program already know HTML and Javascript to some degree. From there, it's a very small leap to XUL and Javascript.
    The major disadvantage is that it will necessarily be a little slower than a custom coded native solution. But who cares for most apps? With recent Mozilla versions, it's more than fast enough. Anyway, my $0.02

    Patrick

    --
    "He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
  3. Don't overlook REALbasic by dpbsmith · · Score: 4, Interesting

    I'm not sure whether it is suitable, but It does give access to the full API via "declare" statements.

    Don't reject it out of hand just because it isn't a "macho" language.

    I don't say it's the right environment for you. I do say you're being foolish if you don't at least take a look at it.

    You can make a very good evaluation because REALsoftwarelets you download a version that is complete, and comes with full documentation (it produces time-crippled applications that only work for thirty days).

  4. QT can be the right solution by statusbar · · Score: 3, Interesting
    If the app GUI is fairly simple, do the back end in a c++ library, and do the front end in Cocoa.

    But if you have a complex GUI, do take a look at QT/Mac from trolltech. It isn't FREE but it is quite good and allows your program to be portable between Mac/Linux/Windows.

    --jeff++

    --
    ipv6 is my vpn
  5. Re:Nothing wrong with Objective C by Ageless · · Score: 3, Interesting

    Unless I am sorely mistaken, the kernel that runs OSX is not written in ObjC. While a OS is more than a kernel (as RMS will gladly point out) the bits that talk to the hardware are the important ones and they are not ObjC.

  6. what is wrong with objective-c? by the_2nd_coming · · Score: 3, Interesting

    you can still compile C code with an objective-c compiler, infact, Objective-C isw a true supper set of OO features appened to C, so would you then not be able to use Coaca with C code as long as you compile into an objective c binary?

    --



    I am the Alpha and the Omega-3
  7. Re:Java -- no question about it. by Twirlip+of+the+Mists · · Score: 3, Interesting

    Who's to say that you can't write good software in Java?

    Absolutely you can write good software in Java. I've seen it done, although I admit that I don't have the mad Java skillz to do it much myself.

    But you can't write good software with Swing. Swing may be a fine user interface toolkit on UNIX, where there are no superior alternatives, but on a Mac, a Swing application-- unless it's specifically tweaked to use the Aqua look and feel-- is kind of an embarrassment. Java Swing apps run on OS X just fine, but they're unpleasant to use.

    this post just makes me angry

    I'm sorry. You get angry at strange things. Must have missed my post in another discussion about how disappointed I am that Mozilla is irrelevant; that post made lots of people angry.

    --

    I write in my journal
  8. Re:my experience by bnenning · · Score: 3, Interesting
    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.


    That's a matter of opinion; I and many others would disagree.


    And resource management in Objective-C and Cocoa is a lot more work and a lot more error prone than in Java or C++.


    Not really. Objective C has no built in memory management (neither does C++), but it uses a reference counting system that works well enough that you rarely have to manually allocate or free memory.


    I don't see much of a future for Cocoa, at least in its current form.


    Apple does. Virtually all apps that come with Mac OS X are written in Cocoa and Objective C. iTunes and iMovie are Carbon, but that's only because they were designed to also run on OS 9.

    --
    How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.