Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Which Coding Framework for Mac OS X ?

Cliff posted about 12 years ago | from the choosing-your-poison dept.

Apple 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.

Sorry! There are no comments related to the filter you selected.

You also have Carbon (5, Informative)

akac (571059) | about 12 years ago | (#4441282)

Carbon is a good API to begin with. You can use C++ or C and access all the nice GUI of OS X.

Cocoa just makes things a lot easier.

I like to think of it this way (though technically its wrong, its a nice way to think of it): Win32 == Carbon; .NET == Cocoa

Re:You also have Carbon (1, Informative)

Anonymous Coward | about 12 years ago | (#4441449)

One thing to consider with Carbon is that keyboard navigation in open/save dialogs is broken (right now). However it works fine in Cocoa. Your users may prefer a Cocoa app for that reason....

Re:You also have Carbon (0)

Goalie_Ca (584234) | about 12 years ago | (#4441524)

Really!? That's odd!

FP FP FP (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4441284)

First post biatch

Native, native, native (2, Informative)

Clock Nova (549733) | about 12 years ago | (#4441286)

I'd go with Cocoa. The more native, the better.

Re:Native, native, native (3, Insightful)

akac (571059) | about 12 years ago | (#4441349)

Though I prefer Cocoa, Carbon is just as native as Cocoa is.

native != better (0)

Anonymous Coward | about 12 years ago | (#4441393)

Ouch! One big problem with "going native"
is that you tie your design and implementation
to the vendor's world view du jour. Don't
fall for this. Keep portability in mind;
you may have to implement it "native" to
actually get in running and take advantage
of some features. Keep it so that you can
port it any environment or support other components.

Re:native != better (5, Insightful)

Twirlip of the Mists (615030) | about 12 years ago | (#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.

First Post? (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4441287)

BFD right....
guess we'll see....

i suggest (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4441292)

switching to a real Os liek GNU/Linux

Don't use Cocoa (0, Informative)

jpmorgan (517966) | about 12 years ago | (#4441295)

While Apple wants you to use Cocoa, they're provided a more typical C/C++ API called Carbon. I suggest you use that- everybody else does. :)

Re:Don't use Cocoa (4, Informative)

WoofLu (459652) | about 12 years ago | (#4441310)

While it is true that the Carbon framework exists, it doesn't give you access to the full capabilities of Quartz/Aqua ..
Carbon was designed to ease the porting of old OS9 apps to OSX, and AFAIK is meant to vanish.

You'd better use Cocoa and learn ObjC .. If you have basic C skills, you should be able to learn it quickly.

My two cents.

Re:Don't use Cocoa (0)

Fuzzle (590327) | about 12 years ago | (#4441378)

Yeah, it supposed to vanish. And it appears that with every update, some Carbon apps just break or start acting odd. I would recommend going completely native with Cocoa. It seems to create much better apps, and takes advantage of all of the extremely cool things that aqua has to offer. Not that Carbon is a complete dud, but Cocoa is the more technologically advanced piece.

Re:Don't use Cocoa (1)

zephc (225327) | about 12 years ago | (#4441394)

FWIW, the ObjC app framework was rewritten basically as a Carbon wrapper, unlike the older NeXT versions. So basically all the AppKit objects/methods are callling Carbon.

Re:Don't use Cocoa (3, Informative)

Twirlip of the Mists (615030) | about 12 years ago | (#4441389)

Um... no, "everybody else" doesn't use Carbon. The Carbon and Cocoa APIs are both used pretty widely. Older applications that were written for the pre-OS X Mac OS Toolbox are usually ported to straight Carbon, because it's easy on the developers. But new applications often use a combination of Carbon and Cocoa to implement different OS features.

There was a session on this at this spring's developer conference. Even applications like TextEdit, which you'd assume would be pure Cocoa, considering the source, use a combination of Cocoa and Carbon code in them.

Your generalization is wrong, sorry.

learning objective c (5, Informative)

Dougal (1492) | about 12 years ago | (#4441298)

To be honest, I'd say get over it and learn Objective C. For an experienced programmer it won't take you long to get to grasps with the basics of Objective C, and Cocoa is really easy to work with. Who knows, you might even grow to like it :) At first I thought Objective C was weird, but now I really like it.

Get a beginners book and work your way through it. I recommend Cocoa Programming for Mac OS X by Aaron Hillegass, published by Addison Wesley, ISBN 0201726831. This seems to be what most people learn from.

Re:learning objective c (1)

davesag (140186) | about 12 years ago | (#4441340)

i am a long time java developer who has never done any c is his life. i went from 68k assember to java via ada, 4d and stuff like lingo and javascript. what books would you recommend for java programmers wanting to learn Objective C and Cocoa? how easy is it to connect front end cocoa stuff like drawers, services access, etc to java backend services. can rendesvous and jini map together? can one write an osx preference pane using java?

Re:learning objective c (3, Informative)

Twirlip of the Mists (615030) | about 12 years ago | (#4441420)

To learn Objective C, start by learning C. Objective C is just a superset of C; most of what you'll be writing will be pure C code.

Once you've mastered C-- which takes about two days, using nothing more complex than a copy of The C Programming Language by Kernighan and Ritchie-- you can learn Objective C using Apple's language reference, which is available for free on the web at this link [] . (Warning: 1.7 MB PDF) Apple also has a number of tutorials on Cocoa programming available on [] that make for a nice, gentle introduction. You'll know Currency Converter inside and out in a matter of hours.

how easy is it to connect front end cocoa stuff like drawers, services access, etc to java backend services

Trivial. There's a full Java language binding for the Cocoa API. You can, in fact, write an entire graphical application in Java with the Cocoa API (using Interface Builder for the GUI, naturally).

As for your other questions, I'll defer to people with more experience than I have.

The Master Of C (0)

Anonymous Coward | about 12 years ago | (#4441479)

Once you've mastered C-- which takes about two days

Oh yeah it's a piece of cake. What a lamer !
Just another one of those fresh new wannabe programmers. If you think you can master C in a couple of days, you probably didn't understand much about computer science to start with.

Re:The Master Of C (4, Funny)

oh2 (520684) | about 12 years ago | (#4441496)

I agree. Mastering C takes at least three days, four if you need to go to the bathroom.

Re:The Master Of C (0)

Anonymous Coward | about 12 years ago | (#4441516)

If you are such a master of C, how come you can't program worth shit ?
Back your boldness with software.

Re:The Master Of C (2)

Twirlip of the Mists (615030) | about 12 years ago | (#4441528)

Uhhh... dude, are we talking about the same thing? The C programming language is incredibly simple. Hell, it only has 32 reserved words! (Plus or minus a few depending on your compiler of choice.) Any reasonably intelligent person who already understands programming concepts like functions and variables should be able to learn the entire C language in a day, maybe two.

Now, if you're talking about the C standard library, or the various POSIX APIs, that's a different story. The various standard C APIs are numerous and bewildering. But the same can be said of any language/API combination.

Re:The Master Of C (0)

Anonymous Coward | about 12 years ago | (#4441550)

Uh, dude, learning the syntax and basic semantics of C in a couple of days? Fine.

Mastering C? That's a whole different story...

Re:The Master Of C (5, Informative)

Jorrit (19549) | about 12 years ago | (#4441561)

The difficulty of learning a language has little to do with the number of keywords it has. It is more a matter of how those keywords (and operators) are used together to enable programmers to do things. C is not that hard but in some cases it can get complex compared to other languages (even if those other languages have more keywords). Pointer arithmetic is one area in which many people struggle. Especially if you come from a programming language (like Java, ...) which doesn't have that.

C++ adds a number of keywords to the C language but not that much. Even so it is a highly complex language with lots of special constructs and exceptions.


Re:learning objective c (3, Informative)

T-Kir (597145) | about 12 years ago | (#4441346)

I agree, I used to program on the NeXTStep platform (my placement/internship company were typesetters, the native PostScript came in handy) and it is virtually (I may be completely wrong here, I havent touched OS X, let alone Macs ;) ) the same thing, just a tad older

With our NeXT systems, you could program in Objective C (being the staple diet), but you could also use C/C++ code as well if you wanted. It won't take to long to get used to (I've heard some peeps say that Objective C is more of a proper OO than C++, but I'm not taking any sides here!)... plus as a programmer, once you know the basics it is just a case of getting used to the semantics, syntax style and quirks of the different language you're learning. Good Luck!

anal cox (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4441302)

are there seriously people outside that use MAC ? i mean comeon. 95% of the marketshare belongs to microsoft and if you want to get work done use windows and not macos.

Erase him (1)

Clock Nova (549733) | about 12 years ago | (#4441342)

I wish I hadn't posted to this topic so I could use my remaining mod points to mod this down. Could someone do it for me, please?

Seems like you answered the question yourself. (5, Interesting)

tqbf (59350) | about 12 years ago | (#4441306)

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.

Re:Seems like you answered the question yourself. (0)

Anonymous Coward | about 12 years ago | (#4441327)

GCC includes an objective-c front end, and GNUSTep aims, as I undertand it, provides the request libraries for the GUI. If you write in Cocca, then it should be a fairly straight port to UNIX using GNUStep. At least in theory (practice is another manner).

WRONG - Carbon provides this too! (1)

linefeed0 (550967) | about 12 years ago | (#4441465)

If you use Project Builder to build Mach-O Carbon apps (rather than CodeWarrior and CFM), you can use all the C-based Unix API's. This myth that only Cocoa's api's work on top of the BSD layer is so incredibly false.

Also, remember that CoreFoundation gives you some of Cocoa's advantages (reference counted data structures, for example) in Carbon. Not knocking Cocoa, but having Carbon as well gives you a lot of choices.

Cocoa all the way (5, Informative)

petrilli (568256) | about 12 years ago | (#4441308)

As someone who grew up around Macs, and then moved to NeXT, I'd have to say that if you know C, and understand OO principles (prefferably in the Smalltalk model, not C++), then you can pick up Objective-C in an afternoon. It's really just some extensions to C. Carbon is a great set of APIs if you've got 10 years of Toolbox experience on the Mac, but otherwise, it's much harder to learn the ins and outs.

Cocoa, because of it's past with NeXTstep, has a lot of emphasis on rapid-prototyping and dynamicism. Lots of delegation, lots of easy stuff to do to get an effective solution. As for Java, I'd have to follow Aaron Hilldegrass' advice... don't. Not on the Mac, not unless your goal is cross-platform. If you're writing for the Mac, write in Objective-C, C++, or even REALbasic, but not Java. There's simply no good reason.

Having written nearly identical programs many years ago for Mac, PC and NeXTstep, I'd say this. Mac and PC (Mac = traditional Toolbox on OS7.x) and Win32 are roughly equivelent to get the work done. Different, but one isn't necessarily easier. The NeXTstep app was implemented in 1/3 of the time, and that included me learning NeXTstep.

Re:Cocoa all the way (1)

petrilli (568256) | about 12 years ago | (#4441319)

Oh yeah, I forgot. Notifications, and Distributed Objects are trivial in Objective-C. They rule, they rock, they're fast to build IPC with. They have different goals, but they are very quick for specific targets, read about them, worship them, they are what Aqua uses all over hte place.

Re:Cocoa all the way - Mod Parent Up (5, Informative)

Anonymous Coward | about 12 years ago | (#4441376)

The above poster hit the nail on the head.

Now, for my own two cents regarding Java+Cocoa: Don't do it. Some friends and I programmed a Jabber-based instant messenger in Java and Cocoa before OSX was officially released. Working with the beta frameworks was a nightmare, for one simple reason: Nobody else was doing anything with Java and Cocoa. To my knowledge, there are only a handful that work with it now.

Like other posters have said, if you're just starting out on a platform, get over your fear of learning a new language. Objective C + Cocoa on OSX and C# + Windows Forms on WXP are the way to go. Also, Carbon, like MFC on Windows, is only really useful if you've got a lot of experience with the older Mac operating systems. There's a lot of cruft in there that's not really necessary and can be a pain to learn. You should find yourself developing a lot cleaner code a lot faster if you take the time to learn the newer tools available.

Have fun. =)

Obligatory resume (on topic because it lists the project!... riiight):

Best Framework for Mac OS X (0, Troll)

Anonymous Coward | about 12 years ago | (#4441309)

Do not use Carbon. The Carbon API has to go through a compatability layer, so any program written in Carbon will always be slower and less capable than its Cocoa version. Also, the Cocoa API is actually very easy to use once you learn the very simple connect protocols. Go to and goto the cocoa column for some great examples.

Re:Best Framework for Mac OS X (2, Interesting)

akac (571059) | about 12 years ago | (#4441335)

Wrong. CLASSIC goes through a compat layer which is probably what you mean. Carbon and Cocoa are FULLY native on OS X. In fact, some Cocoa calls actually call Carbon API funcs. Even Apple developers use Carbon (iTunes) and mix Carbon and Cocoa in the same app.

Re:Best Framework for Mac OS X (4, Informative)

malice (82026) | about 12 years ago | (#4441442)

You clearly have no clue what you're talking about. Many parts of Cocoa are built on top of Carbon -- there is no "emulation layer" for Carbon calls, nor are carbon applications inherently slower than Cocoa applications.

Carbon and Cocoa are merely two APIs that allow you to do the same thing. Carbon is procedural, Cocoa is object oriented.

Many things are easier to prototype and get your initial code up and running in Cocoa, but like an OO framework, you must design your object hierarchy well ahead of time.

There is also a rather serious learning curve for Cocoa, and if you decide to go with Cocoa over Carbon, you've essentially written off any xplat possibilities.

Most of the major applications for Mac OS X are written in Carbon, and will continue to be. Cocoa is a very cool OO framework, but it isn't right for every project, and the misinformation you're spreading is doing no one any good.

Re:Best Framework for Mac OS X (2)

Twirlip of the Mists (615030) | about 12 years ago | (#4441542)

Many things are easier to prototype and get your initial code up and running in Cocoa, but like an OO framework, you must design your object hierarchy well ahead of time.

Of course you're right-- who would know better, right?-- but you'd be surprised how many nontrivial Cocoa programs out there have only one class: Controller. They're basically straight procedural C programs with the Controller class in place of the main() function.

I recommend . . . (-1, Flamebait)

Anonymous Coward | about 12 years ago | (#4441311)

. . . writing code for which there is an audience, i.e. Intel PC's running Windows. Unless you're trying for a niche market where the users are so thankful for anything that they'll buy a substandard app, like the Mac.


Re:I recommend . . . (-1, Troll)

Anonymous Coward | about 12 years ago | (#4441343)

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.


Re:I recommend . . . (5, Insightful)

lemkebeth (568887) | about 12 years ago | (#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).

Fink? (2, Informative)

yerricde (125198) | about 12 years ago | (#4441529)

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

Which utilities that don't already have equivalents in Fink [] (i.e. d*b**n gnu/mac os x) are you talking about?

Re:Fink? (1)

Anonymous Coward | about 12 years ago | (#4441539)

Stuff that requires running an X server doesn't count :).


Let the application dictate the language (5, Insightful)

ageitgey (216346) | about 12 years ago | (#4441320)

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.

Java -- no question about it. (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4441322)

Use Java with swing.

after all, portability should be everyones top priority!

Re:Java -- no question about it. (2)

Twirlip of the Mists (615030) | about 12 years ago | (#4441441)

Yeah, after all, there's no reason to write good software when you can just write portable software.

Least-common-denominator approaches are good for nothing-- except grade-school arithmetic exercises.

Re:Java -- no question about it. (0)

Anonymous Coward | about 12 years ago | (#4441564)

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

Good software design is NOT about the language you use, its about how you use it. (something I'm sure you've heard before)

Saying that all Java code is poor is like saying that all books written in russian are poor.

this post just makes me angry

Let your fingers do the walking (-1)

Anonymous Coward | about 12 years ago | (#4441325)

Google []

Nothing wrong with Objective C (5, Informative)

zulux (112259) | about 12 years ago | (#4441328)

I love C++, templates, and think nothing of derfrrencing a pointer to a vector of objects that are stored in a crazy containter that I cobbeled together last night while high on cough syrup and mountain dew:

However -

Objective C kicks ass for GUI apps. It's easy to learn, and hides some of c's rough edges, and it's fast to compile. Make no mistake - nobody's going to code the next operatig system in it - but for GUI apps, take this good tool and run with it.

Re:Nothing wrong with Objective C (3, Insightful)

Sahib! (11033) | about 12 years ago | (#4441422)

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

Funny, that's just what Apple did.

Re:Nothing wrong with Objective C (2)

zulux (112259) | about 12 years ago | (#4441493)

Funny, that's just what Apple did.

Are you seriously claiming that the kernel of the OS is written in Objective C?

If it is, please tell me, as I'd be quite impressed.

AFAIK - the Kernel and Darwin are C, but hey, I'd like to know if otherwise.

Re:Nothing wrong with Objective C (3, Interesting)

Ageless (10680) | about 12 years ago | (#4441512)

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.

Re:Nothing wrong with Objective C (-1, Troll)

Anonymous Coward | about 12 years ago | (#4441502)

C++ sucks, so do people that "Love it", or in general people that "love" things.
C++ fag !

Why not Java / Swing? (1, Informative)

hoegg (132716) | about 12 years ago | (#4441334)

Forgive my inexperience with OSX programming, but some of the features you seem to be interested in are not OSX specific.

Easy IPC can be accomplished numerous ways using vanilla Java (RMI, conventional Thread communication), and you can go with CORBA for language-neutral IPC. And I think Java Threads are as good or better than BSD processes.

The UI decision is less important than the underlying program architecture and language/framework choice. Swing is the most obvious choice, but there are others [] .

Depends where you start (0)

Anonymous Coward | about 12 years ago | (#4441347)

The answer to this is going to be different if you're (a) writing something from scratch or (b) porting a mass of existing codes.
Let me put my own spin on this question for the /. experts to answer. If you have a 200K-line C++ Windows app to port, would you
  1. Carbonize it?
  2. Leave it alone and add a Cocoa interface layer?
  3. Rewrite the whole bloody lot in ObjectiveC?

Re:Depends where you start (0)

Anonymous Coward | about 12 years ago | (#4441425)

I'd pick...

3.) Rewrite the whole bloody lot in ... Java ....

Now I never have to port my application again. []

Mozilla (5, Interesting)

Fished (574624) | about 12 years ago | (#4441355)

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


Re:Mozilla (5, Insightful)

Lao-Tzu (12740) | about 12 years ago | (#4441410)

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.

Re:Mozilla (1)

Pahroza (24427) | about 12 years ago | (#4441416)

And when you put together that page that works only in mozilla and mozilla releases a patch that fixes some bugs and introduces others, are you going to tell your customers that they can't upgrade their browser because your application no longer works with it ?

Re:Mozilla (2)

Jorrit (19549) | about 12 years ago | (#4441537)

He is not talking about Mozilla The Browser. He is talking about Mozilla the Application Framework. Mozilla is more than just a browser. It is an entire application framework in which you can make applications that do NOT require or run in a browser.


Re:Mozilla (1)

Twirlip of the Mists (615030) | about 12 years ago | (#4441452)

Dude, you have got to be kidding, right?

Re:Mozilla (5, Informative)

Fished (574624) | about 12 years ago | (#4441497)

People responding seem to be missing a crucial point: I am not talking about a web application here. I am talking about using the mozilla framework to develop a local application. This is actually how Mozilla, including Mail, Messenger and Composer, is developed.

If you haven't looked at it closely, don't knock it. Take a look at Creating Applications with Mozilla [] , from O'Reilly (of course.)

Speaking from experience... (0, Informative)

Anonymous Coward | about 12 years ago | (#4441368)

I have been programming for Macs for the past 7 years..

First of all, Java. Java unfortunately is still too slow in its execution time. Yes there have been improvements, but they're not up to par yet.

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.

Which leaves Carbon. Nice, clean C++. Speedy execution too. Go for Carbon.

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

Re:Speaking from experience... (2)

lemkebeth (568887) | about 12 years ago | (#4441447)

You wrote:

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.

Objective-C is an extensions to C (like C++) but, for the extensions draws on Smalltalk for inspiration.

In addition you wrote:

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

Cocoa is an updated NeXT API.

Re:Speaking from experience... (1)

LeninZhiv (464864) | about 12 years ago | (#4441500)

I believe the OP must've meant to say

I have been programming my 7-year-old Mac for years

rather than

I have been programming for Macs for the past 7 years.

Re:Speaking from experience... (4, Insightful)

Twirlip of the Mists (615030) | about 12 years ago | (#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.

Don't overlook REALbasic (4, Interesting)

dpbsmith (263124) | about 12 years ago | (#4441369)

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).

Re:Don't overlook REALbasic (0)

Anonymous Coward | about 12 years ago | (#4441391)

I agree, REALbasic is Not In Any Way the mac equivilant of VB.

(Sure its expensive, and dies for no reason sometimes, but so does windows, and you don't hear your boss complaining...)

Seriously though, REALbasic just might be the way for you to go. Give it a try, and if you like it, you should buy it. []

Re:Don't overlook REALbasic (4, Funny)

Pahroza (24427) | about 12 years ago | (#4441428)

How could someone possibly overlook RB? Have you seen the footprint of RB apps ? Blech. Cocoa is the way to go.

Re:Don't overlook REALbasic (1)

fdiv_bug (611080) | about 12 years ago | (#4441467)

I used REALbasic for a short time in Mac OS 9, and I found it to be a fantastic solution for application design. The language is simple and very easy to learn and the UI design tools work very well. It also lets you build apps for Mac OS 9, Mac OS X, and Windows all from one project; while I never tried this myself, I've never heard any complaints about it. REALsoftware also has a bunch of moderate- to high-traffic mailing lists for discussion of various aspects of REALbasic coding, and they're frequented very often by REALsoftware people, including the CEO Geoff Pearlman. You couldn't ask for better support for your money from them.

The only major drawback is that it costs money, but you can grab the demo and start toying with it to see how well it works. To echo the other posters, it's not for low-level or realtime performance.

Again, I agree with both posters here: You may be missing out on the right solution if you overlook it.

What about QT? (0, Troll)

wray (59341) | about 12 years ago | (#4441386)

I am not sure of your position, (because the developer license costs money for Mac OSX) but QT [] has the advantage of porting to about every platform there is.

Re:What about QT? (2)

JohnG (93975) | about 12 years ago | (#4441404)

Where in the blue hell did you hear that the developer license for Mac OS X costs money. The OS ships with developer tools.

Re:What about QT? (1)

gnuadam (612852) | about 12 years ago | (#4441501)

Not 100% sure (because I'm too lazy to look at the trolltech website) but I think he was refering to the fact that getting the QT developer licence is not free for mac os x, unlike in linux, where they give free license. This has nothing to do with the too often uninstalled extra CD apple ships with their operating system.

Re:What about QT? (2)

JohnG (93975) | about 12 years ago | (#4441534)

Oh, OK, I'm an idiot! Apologies to the original poster! :)

Re:What about QT? (1)

Josh (2625) | about 12 years ago | (#4441407)

On the topic of QT, I'd like to pose the question, for those, who know, of what underlying API QT uses for the OS X specific part of the toolkit. Is it Carbon?

Re:What about QT? (2)

statusbar (314703) | about 12 years ago | (#4441427)



Re:What about QT? (2, Informative)

SilverSun (114725) | about 12 years ago | (#4441438)

quoting trolltech:

Qt/Mac runs on Mac OS X. It uses the native Carbon API and does not require any special libraries.

Qt/Mac can be used with Apple's Project Builder and the gcc compiler that is shipped with Mac OS X.

It runns just fine. porting from Linux to Mac? No, just recompile.

QT can be the right solution (3, Interesting)

statusbar (314703) | about 12 years ago | (#4441398)

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.


Cocoa / Obj-C (5, Informative)

Sahib! (11033) | about 12 years ago | (#4441400)

Definitely, learn [] Cocoa and Objective C if you can, just for the experience of realizing how much better it is that most of your other choices. With InterfaceBuilder [] , you can completely abstract your UI [] from the core of your code.

Since you say you want to use the BSD layer, I suggest making a command-line [] version of this core code first (you can do this in C or C++), since this will be immediately more portable to other Unices. Once that is done, tying that code in with the UI you build in InterfaceBuilder is simple.

Also, there are some pretty interesting [] native IPC libraries [] in Mach. If you don't mind your code [] being tied to Mach, you should check that out as well.

Oh, did I mention that Apple's developer tools and documentation are free for download [] ?

Re:Cocoa / Obj-C (2, Informative)

Sahib! (11033) | about 12 years ago | (#4441457)

Also, O'Reilly's Building Cocoa Applications [] is excellent for the beginner, although I wish they would publish AppKit & Foundation in a Nutshell for a good off-line reference.

Some other good references:

use Cocoa (5, Insightful)

d3xt3r (527989) | about 12 years ago | (#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.

How about Qt/Mac (3, Informative)

SilverSun (114725) | about 12 years ago | (#4441414)

Qt/Mac [] from trolltech:

Qt/Mac runs on Mac OS X. It uses the native Carbon API and does not require any special libraries.

Qt/Mac can be used with Apple's Project Builder and the gcc compiler that is shipped with Mac OS X.

I used gtk for a while and now switched to Qt. It is just wonderful. I can just recommend it to anyone who is willing to use C++/perl/pyth/ruby or so. It is pretty solid, and (wit exeption of the moc-precesser) very beautyfully designed. It is portable and available on Win/Unix/Linux/MacX.

I ported some of our apps to Qt/Mac. Well, I recompiled the Qt stuff and the porting was related to other parts.

Even though many people don't seem to realize, it Qt is fully GPL. The plain, good ol GPL. So if you project is GPL it is a very good choice. If not, you probably have the money to pay and it is still a good choice.

Cheers, Peter

Only on X11 (2, Informative)

yerricde (125198) | about 12 years ago | (#4441505)

Qt is fully GPL.

Only when compiling for the X11 target, which requires Mac users to install XDarwin and Windows users to install Cygwin and XFree86.

Re:How about Qt/Mac (1)

SilverSun (114725) | about 12 years ago | (#4441509)

To be precise Qt/X11 is GPL. There is a Qt/Win non-commercial version, but I guess you have to pay for Qt/Mac.

Java Cocoa (5, Informative)

BlueGecko (109058) | about 12 years ago | (#4441418)

the Cocoa Java API [gets compiled to PPC binaries, lots of APIs available [think Google], but absolutely no decent documentation to be found]
First, Java Cocoa is not native. Your application will still run on the Java VM. In my mind, it fills a very narrow purpose: it allows you to quickly turn a 100% Java application into an application that behaves exactly like a truly native OS X application and which can take advantage of the niceties that provides (for example, Services support, Sheets, Quartz, etc.). Secondly, I hear the complaint about the lack of Java API documentation all of the time, and I honestly don't understand it. Admitting that I've been working in NEXTSTEP and later OpenStep and then Cocoa for a very long time, Apple provides a detailed Java API reference that has class-for-class and method-for-method documentation exactly on par with the ObjC documentation and also provides a tutorial for Java developers that literally produces exactly the same application as the ObjC Cocoa tutorial. You need merely do both tutorials to see how exactly the two APIs line up. The only somewhat legitimate complaint is that Apple examples typically come as ObjC, but how hard is it, honestly, to figure out that [aSpellingChecker ignoreWord: @"bodacious" inSpellDocumentWithTag: myTag] becomes aSpellingChecker.ignoreWord("bodacious", myTag)? The rules for ObjC-to-Java conversion of APIs and code are very straight-forward:
  1. Any code relating to autorelease pools may be deleted and ignored (at least in basic code; by the time you need to make use of manual garbage collection in Java Cocoa (multithreaded code in the GUI being a big one), bluntly, you'll already know enough that it won't bother you)
  2. Java class names remain identical to their ObjC counterparts, and are in either if they are part of the ObjC FoundationKit and part of if they are part of the ObjC AppKit. (QuickTime is in its own API and really is a separate discussion, since "QuickTime for Java" has existed for several years now and is more a part of Carbon than Cocoa.)
  3. Method names for Java always consist of the first part of the ObjC identifier and always take the same parameters (except that NSStrings become java.lang.String). For example, (void)NSSpellChecker>>ignoreWord:(NSString *)inSpellDocumentWithTag:(int) becomes void NSSpellChecker.ignoreWord(String, int).

All that said, I would strongly recommend you take the time to learn ObjC Cocoa. I use Java Cocoa when I am grafting a Cocoa UI onto Java code, but ObjC is still faster (though the gap is narrowing) and I still honestly believe the language is still a bit more productive due to things such as Categories, Smalltalk-style method names, and other things. If you know C and Java and are familiar with the concepts of reference-counted garbage collection, learning ObjC will take you the better part of a morning.

Depends on the needs [/METOO] (3, Insightful)

Have Blue (616) | about 12 years ago | (#4441426)

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).

Don't discount Cocoa! (5, Insightful)

critic666 (317551) | about 12 years ago | (#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 :)


Sockets and Java (1, Flamebait)

Tim Ward (514198) | about 12 years ago | (#4441445)

If you want to make non-trivial use of sockets then there are plenty of things you can't do in Java anyway. Even if you find that Java can do what you want to with sockets you may find that it's not portable (particularly if you are combining sockets and threads).

Documentation (1)

matsukio (27212) | about 12 years ago | (#4441448)

I agree with most of those who have said that Objective C is easy enough to pick up in an afternoon. And in my experience, Objective C is preferable to Java for Cocoa development. And in my experence Cocoa is preferable to Carbon, not only because the Carbon featureset is a subset of the Cocoa featureset, not only because Cocoa is the native framework for OS X, but also because you can leverage the excellent development tools provided by Apple (especially Project Builder and Interface Builder). A dedicated programmer can learn how to use PB and IB and Objective C in a day or two, and proficiency in those tools will speed up your actual coding work more than enough to merit the time spent learning them.

Documentation for the development environment, as well as Carbon and Cocoa API tutorials and reference, can be found on Apple's Developer [] site.

apparEntly (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4441458)

Learn English first !

Use Cocoa (3, Insightful)

Anonymous Coward | about 12 years ago | (#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.

Use Objective C + OmniNetworking (5, Informative)

jarrettwold2002 (601633) | about 12 years ago | (#4441489)

I myself just got into OS X development. I found that the doucmentation for ObjC is huge, almost all examples I find are in ObjC. Also there is a nice BSD sockets wrapper from OmniGroup calld OmniNetworking. SX /Frameworks/

In addition there is a mailing list that's amazing and answers a ton of questions that link is:

Finally as intimidating as ObjC looks, it's quite easy to pick up after you get the basics down. I would highly recommend Aaron Hillegass's Cocoa Programming for Mac OS X.

Finally last reason. It's something to add to your resume. I like programming because of the cool new stuff. It's like a geek Christmas every day. As such why not try the new toys and learn from it. Since ObjC has been in GCC for a while, you can use it elsewhere ;)

APPARANTLY (-1, Offtopic)

Anonymous Coward | about 12 years ago | (#4441491)

APPARENTLY you don't know your own language.

Why not wxWindows? (3, Insightful)

kollivier (449524) | about 12 years ago | (#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. =)

Carbon vs Cocoa (-1, Redundant)

Anonymous Coward | about 12 years ago | (#4441515)

Carbon is faster than Cocoa, but Cocoa is easier than Carbon. You should read this tiny article [] .

Use Jython or JRuby with SWT (1)

fxj (267709) | about 12 years ago | (#4441544)

write your basic classes in java and
use jython to set up the application.

Have you had a look at SWT ? Eclipse is written in it and it is really fast !

AppleScript? (1)

CowboyNick (612553) | about 12 years ago | (#4441546)

Why not just use AppleScript? :)

Here's how I see it (5, Insightful)

Dr. Awktagon (233360) | about 12 years ago | (#4441551)

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 default, I recommend Cocoa / Objective-C (2, Interesting)

Anonymous Coward | about 12 years ago | (#4441555)

Mac users care a great deal about nativity and the app behaving like a good Mac OS X app. (Otherwise we could be using something cheaper and less elegant, right?) Cocoa is the most native thing on OS X. If you use Cocoa, you have an immediate advantage over competitors who use Swing or Carbon.

With Carbon you have to implement a lot of stuff Cocoa gives you for free. I still haven't seen a non-sample-code Carbon app with proper Unicode support. Then there are things that Swing apps just can't do. (And don't believe Sun's pluggable talk. You can't just plug in Aquaness without designing for Aqua.)

The Cocoa Java API feels like an Objective-C API anyway, so you might just as well learn Objective-C unless you already have Java back end code.

Objective-C is way cooler than C++.

what is wrong with objective-c? (3, Interesting)

the_2nd_coming (444906) | about 12 years ago | (#4441562)

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?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?