Slashdot Mirror


Modern Mac Development?

CDarklock asks: "I'm getting seriously interested in setting a new Mac next to my Windows box (to replace the Mac SE, which should tell you about how long it's been). But on Linux and Windows, I'm accustomed to writing lots of custom apps in C++ to fill the gaps around the system, but I haven't written anything on a Mac for something like fifteen years. As a professional Windows developer, what sort of expense am I facing to outfit a new Mac with development tools comparable to Microsoft's Visual Studio .NET, and what sort of learning curve should I expect?"

66 of 210 comments (clear)

  1. Xcode by geoffspear · · Score: 4, Informative
    The development tools come with the OS for free.

    As for the learning curve, it may take some time to get used to things being done differently in OS X, but moving from C++ to Java isn't too difficult if you choose to use Java Cocoa.

    Objective C is generally a better bet for Cocoa development, but it will have a slightly steeper learning curve, since the syntax is significantly different.

    Other than the change of language, the Cocoa frameworks might take a while to learn, but the documentation is very good.

    --
    Don't blame me; I'm never given mod points.
    1. Re:Xcode by drc1 · · Score: 2, Interesting

      You can use Xcode to program in almost any language you choose Cocoa, C, Java, Ruby....

    2. Re:Xcode by geoffspear · · Score: 2, Informative
      True, but if you're looking for something comparable to .NET to develop Mac applications, you're probably going to want to use Cocoa or Carbon.

      You can develop Palm applications in Xcode, too, but I don't think that's what the OP is looking for...

      --
      Don't blame me; I'm never given mod points.
    3. Re:Xcode by Golias · · Score: 2, Informative

      It should me noted that the just-released OS X 10.4 ("Tiger") comes with Xcode 2.

      Among other things, it's capable of importing Code Warrior projects.

      --

      Information wants to be anthropomorphized.

    4. Re:Xcode by Bastian · · Score: 4, Informative

      If you're looking at writing native software, I would strongly recommend taking the long road and getting used to Objective-C, for a multitude of reasons.

      The vast majority of frameworks available for OS X are written in Objective-C, and aren't necessarily well-documented. Even though there is an Objective-C - Java bridge, you'll still have to learn ObjC to use these frameworks just to learn how they work.

      In my experience, ObjC apps run faster and consume less memory than Java Cocoa apps. I have also found that this tends to be a bigger issue in the Mac world than it is in the PC world, because Mac users tend to hold onto their computers for much longer. That, and the Java Runtime Environment for Macs doesn't seem to be nearly as well-optimized as the JRE for PCs. (well, Windows, at least.)

      Massive portions of the OS X APIs have not been ported to Cocoa yet. If you use ObjC Cocoa, a lot of the ObjC objects you use will be toll-free bridged with the equivalent data structures in the Carbon libraries. It should also be a lot easier to deal with the even older C libraries that haven't even been included in Carbon yet.

      But most of all, my impression is that if you're using the Cocoa libraries and the Java language, you have more or less given up all the benefits of the Java platform (such as the ability to write platform-independent apps), as well as the benefits of the Objective-C language (such as categories.) Unless you just really don't want to trade automatic garbage collection for reference counting or just really don't want to learn a new language, you're giving up a lot to gain a little by using Java for Cocoa development.

    5. Re:Xcode by swillden · · Score: 4, Interesting

      Objective C is generally a better bet for Cocoa development, but it will have a slightly steeper learning curve, since the syntax is significantly different.

      Different, yes, but also very simple, so don't overestimate the level of effort required, assuming you know C.

      Objective-C is an object-oriented extension to C, like C++, but it took a very different approach than C++. While C++ is large and complex, Objective-C is small and simple. The syntax is deliberately based on Smalltalk syntax, so if you know Smalltalk you'll have even less to learn. If you don't know Smalltalk, though, keep in mind that Smalltalk is a language whose syntax and rules you can literally master in an afternoon. Objective-C has added some new ideas, such as "categories" that Smalltalk didn't have, and there are some interactions between the Smalltalkish syntax and the underlying C syntax, so Objective-C takes a day for a C programmer to fully understand, rather than an afternoon (C++, of course, takes months).

      For C++ and Java programmers who've never seen Smalltalk or another completely dynamically-typed language, I caution you to go slowly at first and take some time to understand the Smalltalk/Objective-C idea of what an "object" is. Or a "class". It's tempting to just dive right into the syntax, figuring that you know the "OO stuff", but the OO stuff in question is just different enough that you'll tie yourself in knots if you don't take a few minutes to understand what the differences are.

      For experienced C++ programmers there's another interesting goody waiting... Objective-C++. The Objective-C and C++ extensions to C are orthogonal, so you can actually mix Objective-C and C++ code at will. Objective-C methods can take C++ objects as parameters and vice versa, and they can store pointers to each other.

      The result is a very powerful language that lets you choose between the flat-out on-the-metal efficiency of good C++ code and the extreme flexibility of late-bound Objective-C code. And with C++'s polymorphism and Objective-C's categories (which provide limited compile-time typechecking) you even have a couple of steps in between. Be very, very, careful though. It's easy to create an unmaintainable mess when you start mixing things.

      BTW, I should make a disclaimer here: I have looked at but never written code for Mac OS X. Everything I know about Objective-C comes from when I used to own a NeXT machine, so there may be a few differences. Based on the OS X code I've read, though, I don't think there are very many or that they're very large.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    6. Re:Xcode by cpct0 · · Score: 4, Informative

      Backgrounder on me: I'm currently writing things for Mac and PC, in 2003 and XCode, professionally.

      I have to add to your very nice and concise description:

      - Don't try to learn Objective-C by yourself, it's weird syntaxically and many many pitfalls can be avoided by carefully perusing and actually doing the examples for the first few chapters of Ora's Learning Cocoa with Objective-C (http://www.oreilly.com/catalog/learncocoa2/). It's that weird. But it's totally worth it.

      - XCode and VC both have the good things and bad things. I'd say that VC is slightly better because they got more years under the belt that XCode. They also got Visual Assist X, which is God-sent (http://www.wholetomato.com/). And only for the build styles, that are so well hidden in XCode, that ought to piss you off (on VC, you just select the configuration and here you go).

      - As usual, you will pester while doing the transition. It's normal. You are accustomed to something and that "something" is not what you will have, hence you won't have your favorite little shortcut, or your thing you always do, software will react oddly too. Again, not because it's much worst, it's simply different.

      All in all, it's a very interesting endeavor. Good luck!

      Mike

    7. Re:Xcode by alanQuatermain · · Score: 3, Informative
      Unless you just really don't want to trade automatic garbage collection for reference counting

      I can't find the external link to this now (it may only have been in the developer docs for the Tiger developer releases), but the Objective-C runtime in Tiger has garbage collection. And as of Panther (so, for just over a year now) there has been built in ObjC runtime support for thread synchronization in a similar manner to Java - via the @synchronized keyword - and runtime-supplied try/catch/finally (rather than the setjmp-based macros NS_DURING/NS_HANDLER/NS_ENDHANDLER previously supplied).

      Since these features require a specific release of the Objective-C runtime, however, they will only work on their respective system builds, and therefore need to be enabled within the compiler settings in Xcode. So, garbage collection requires at least 10.4, and runtime exceptions/synchronization require at least 10.3.

      -Q

      PS. Just found out where I saw the option: in the 'Code Generation' section of the build rules pane on an Xcode target. Can't find any reference to it on the Internet. Although probably a better Googler than I might be able to find something associated with the GCC folks - the best I can find can be turned up by Googling or 'objc-gc'.

    8. Re:Xcode by drc1 · · Score: 2, Informative

      Have a look at http://developer.apple.com/internet/scripting/phpa ppledevtools.html I suspect it is now possible to use Xcode for just about every language. I must admit I quite like having the same environment for all my projects from Applescript to ObjC

    9. Re:Xcode by putaro · · Score: 2, Interesting

      But most of all, my impression is that if you're using the Cocoa libraries and the Java language, you have more or less given up all the benefits of the Java platform (such as the ability to write platform-independent apps)

      Depends on how you code things. We have a fairly large app written in Cocoa/Java and if you work to abstract things out a bit you can cut the amount of OS X specific code down quite a bit. For example, we have a GUI that runs under Cocoa and Swing. By factoring the code properly (Model-View-Controller) the Cocoa specific part is about 10% of the GUI code.

      If you're not planning to run on anything other than OS X, though, I'd say that the pain of trying to use Java is about equal to the pain of using Objective-C.

  2. Difficulty with VS.NET by crmartin · · Score: 4, Funny

    Your problem is managing to impede the Mac sufficiently to make it no better than .NET.

    (Okay, so I am a recent convert.)

  3. X-Code by meatball_mulligan · · Score: 3, Interesting

    I don't know how well it measures up against Visual Studio, but I for one love X-Code. It's a nice IDE, useful but not over done. X-Code and a number of other development tools come with OS X (and are avaible at no charge from the Apple Developer Network website). X-Code uses gcc and gdb for compiling and debugging. You can use it to code C, C++, Objective C and others. As far as coding goes, it sounds like you'll really want to learn Cocoa. Cocoa is the core set of OS X frameworks (think MFC, only much, much better). There are Cocoa bindings Java and a few other langs, but ideally you'll want to use Objective C. Obj C is a great language, much easier to learn than C++, and in my opinion a joy to program. Good luck.

  4. python? by same_old_story · · Score: 2, Interesting

    has any one experience with python development in OSX? these features of xcode, like getting undo for free. are/will they be available for python coders? I dont do any c++ or objective c, so I would not know. I guess those things would requires wrapers for python to deal with them , right?

    1. Re:python? by Anonymous Coward · · Score: 2, Informative

      Python is very popular on Mac OS X. Of the scripting-style languages (Perl, Python, Ruby, etc.), it probably has the most thorough support for writing real applications.

      Things like PyObjC let you do everything that the native frameworks can in Python. (That is, you can write full Cocoa apps entirely in Python). Also, you can use Python in Obj-C code. I know for certain that people have written plugins for many apps seemlessly this way.

      I don't know what you mean by "getting undo for free" -- if you mean Core Data, in Tiger, then the answer is "maybe". I don't see why not with something like PyObjC, but it would probably involve some Obj-C coding.

  5. Apple Development by Laplace · · Score: 5, Informative

    Apple ships OS X with a developer tools CD. That's where you will want to start. It will give you most of your basic gnu development tools, along with Xcode (a decent IDE which is getting better with every revision) and some mac-specific profiling tools.

    The next step is to sign up for the Apple Developer Connection. It has many membership levels ranging from free (so you can download developer tool updates) to very expensive. Update your compiler and tools to the latest version using this service.

    If you like Java, downloading Eclipse might be a good way to go. I haven't used Eclipse much, but have enjoyed all of my experiences with it on OS X.

    You will also want to install either Darwin Ports or Fink. These are package management systems that are based on BSD Ports and apt (respectively). I'm partial to Darwin Ports, but both systems have their strengths and weaknesses.

    If you want dead-tree documentation, the two books to start off with are "Cocoa Programming for Mac OS X" by Aaron Hillegass and "Core Mac OS X and Unix Programming" by Mark Dalrymple and Aaron Hillegass. These guides are thorough, and the authors have been part of the Objective-C/Cocoa community since the Next days, and give good tutorials on what is the Mac philosophy of software development.

    Another option for an IDE, which has decent but dated interfaces to the OS X world is CodeWarrior. I know a bunch of developers who swear by the CodeWarrior development platform. I really couldn't get into it myself, but it seems to have a nice toolkit for cross-platform development.

    Have fun!

    --
    The middle mind speaks!
  6. XCode is free... by teridon · · Score: 2, Informative
    I have no clue whether XCode is "comparable" to MS VS .NET, but it, and the other Apple developer tools are free. It comes with any Mac, or you can download it for free (with a free ADC Student membership).

    If you have any costs (other than the hardware), they might be:

    ADC membership (student membership is free, non-student cost is significant)

    WWDC attendance

    Other apple developer training/seminars

    None of the above are required. ADC membership will get you access to pre-release hardware and software to test your apps; but you're not doing commercial work, right? Apple training and the WWDC gives you insight into the inner workings of the OS, but you can get much of this info on Apple's developer website

    --
    I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson
    1. Re:XCode is free... by BoomerSooner · · Score: 4, Informative

      ADC is free
      ADC 1 year subscription for Student is $99
      ADC 1 year subscription with 1 Hardware coupon is $500
      ADC 1 year subscription with 10 Hardware coupons is $3500

      The Hardware discount is significant if you're getting a high end mac. I suggest the $500 subscription and you'll save that on a high end powerbook or G5 powermac

      Click United States Then ADC Hardware Purchase Program.

      Big savings plus it's like subscribing to the MSDN you get cool shit all year.

    2. Re:XCode is free... by Senjutsu · · Score: 2, Informative

      The Hardware discount is significant if you're getting a high end mac. I suggest the $500 subscription and you'll save that on a high end powerbook or G5 powermac.

      Student ADC members get the same discounts as the $500 select members, so if he's a student he could get those same discounts with the $99 membership.

    3. Re:XCode is free... by Senjutsu · · Score: 2, Informative

      The discounts get larger as the hardware gets more expensive (for fairly obvious reasons). I'm going to assume you're a fellow canuck based on that email address, so if you browse the Candian ADC Select Store, you can compare them with the regular prices at the regular Canadian Apple store. Remember to factor in the $99US student membership fee on top of the prices there.

      From what I've seen, unless you're buying quite high end stuff, it's about as cheap to buy from the regular education store than from the ADC store once you factor that cost in.

  7. Defend your position!? by ciroknight · · Score: 3, Interesting

    Why is it too bulky? It offers automated CVS/SVN support, greatly helps organize files without needlessly creating a thousand folders to store your files in, builds everything as you ask it to, and offers instant support at your fingertips. XCode is awesome if you know how to use it correctly.

    But, if you are a C or Perl hacker who likes doing things from the command line, that's quite alright as well. If you're programming on the Mac, you're most likely making a GUI for something UNIXie already, so you're probably going to want to use XCode, if not for its instant support to Carbon documentation, than for source code highlighting and autocomplete (which isn't as good as Visual Studio's autocomplete, but it gets the job done).

    --
    "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
    1. Re:Defend your position!? by Paradise+Pete · · Score: 3, Interesting
      In my experience, XCode is incredibly slow for building a smaller ( 20 files) application.

      I have a small project I'm working on. It currently has 16 files. If I change a single file and click "build," its finished about as soon as I release the mouse button. If I "clean" first, which forces it to recompile everything, the build is finished in six seconds.

    2. Re:Defend your position!? by alanQuatermain · · Score: 5, Interesting

      I've been using Xcode for things for years now, and the only thing that takes any real time for me is the precompilation step.

      If you build a Cocoa/Carbon application with only a couple source files, it may take a while to build the whole thing, but that's more than likely just the precompilation step (which is likely precompiling a large percentage of the header files installed on your system, and only happens on first build or after a 'clean' or 'clean all').

      That said, I rarely have any problem with such applications. In fact, I quite often build one-source-file testing applications with Xcode just to try things out - for example, to see what error codes are returned by FSMountServerVolumeSync() under different situations (already mounted by same user, already mounted by other user, invalid volume, invalid server, invalid user/pass, etc.). I rarely have a problem with it.

      Perhaps the tradeoff between long precompilation time and size of other source code seems wrong to you - but in that case you can always turn it off in the target settings. Internally it just calls through to gcc, and there doesn't seem to be any significant overhead that I can see...

      -Q

  8. New feature in Tiger ;-) by zhiwenchong · · Score: 2, Interesting

    Remappable Modifier Keys

    Remap modifiers such as control and caps lock to be super elite.
    http://www.apple.com/macosx/newfeatures/newfeature s.html

  9. Tiger? by El · · Score: 2, Insightful

    On a related subject, if I wait until May to buy a Mac Mini, will it come with Tiger and X-code?

    --

    "Freedom means freedom for everybody" -- Dick Cheney

    1. Re:Tiger? by nickscalise · · Score: 3, Informative

      Probably, but if not you can get the Tiger DVD sent to you for $9.95.

      http://www.apple.com/macosx/uptodate/

    2. Re:Tiger? by amichalo · · Score: 2, Informative

      According to Apple, if you buy a system today, you will get Tiger.

      --
      I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
  10. Book by avjewe · · Score: 3, Informative

    Cocoa Programming for Mac OS X by Aaron Hillegass is an excellent place to start learning how to use all the cool Mac-specific stuff.

  11. Other than the obvious by amichalo · · Score: 5, Informative

    Everyone has (and will continue) to discuss Xcode.

    I can give some insight into the question of learning curve.

    I develop .NET web apps at work on XP but have a Mac at home. there are a good many differences:

    - The mac is like Linux. Get used to the Linux command line. If you don't know basic commands like LS instead of DIR then the curve will be steap. If you have used a *nix system or are a quick study, I would pickup an O'reilly book and get up to speed with things like user permissions (CHMOD) and GREP and the Pipe "|" for automation. Also know than things like Chron jobs replace Windows Scheduler. Get a book adn take the few hours to skim it. It will be a great reference if nothing else.

    - Perpare yourself for more text editor usage and less sophisticated Integrated Developer Environment (IDE). Okay, let the Apple Xcoders begin their flame. I really feel that MS got some things very very right with Visual Studio .Net and it is way different developing .Net apps with the IDE in Visual Studio. I have developed php apps on the Mac and used TextEdit and BBedit (a great OS X only editor). IMHO, seasoned coders who really know their stuff will do well transitioning from VS.net, beginers will have a few less crutches to use.

    - You're gonna need an office suite. MS Office.X is great, but for the money, I kinda like OO.o and use NeoOffice/J myself. A Mac alternative to Visio is OmniGraffle and is better IMHO.

    - Get used to few, but higher quality choices. Okay, this one is touchy too but there are few fewer choices for software and websites to Google for a problem but the ones you do find for whatever the task might be are of better quality I think. Apple does a great many things right the first time so even if an article is written for Jaguar, it may very well work under Tiger, etc. I have found this very frustrating as I try to install something under IIS 6 with a document written for IIS 5 for example.

    - Don't underestimate the hardware. Okay, your budget, your choice, but I would be more inclined to recommend to a serious developer buying a Power Mac (watch out, rumors of new updates in May so careful with the timing) over a Mac mini. The Mac mini is great for a home user wanting to check email, but if you are going to develop, compile, and potentially deploy Web Objects and such, don't underestimate the G5's supperiority to it's 32-bit father. At a minimum, follow all the recommendations and get 512mb ram (I have a Gig and use it).

    Lastly, "Welcome".

    --
    I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
  12. Re:is this.. by amichalo · · Score: 4, Insightful

    There is more to developing on a Mac than downloading Xcode.

    I think the thread is worth exploring. There is a learning curve to moving from Windows to OS X in general, and more to learn when switching as a developer. The move from Linux to OS X is far less of a curve, but still exists.

    Let's give the thread a chance!

    --
    I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
  13. Re:Apple owner and developer by mopslik · · Score: 2, Informative

    Java is fine and dandy, but anyone who's had lots of experience with C++ might feel a bit more at home using wxWidgets. I've done a bit of work using wxWidgets, and it's pretty spiffy.

    I will admit, however, that the majority of my stuff has been for Windows/Linux cross-compatibility, with little focus on Macs.

  14. Xcode + a good book or two by anactofgod · · Score: 5, Informative

    Is all you need to write the sort of apps that you were talking about.

    Xcode, as every other post has said, is free.

    Wrt books, I'd recommend "Cocoa Programming for Mac OS X, 2nd ed", by Aaron Hillegass. Aaron has a lot of experience teaching NextStep, WebObjects and OS X development, and his book reflect that experience. It is excellent - much better than the O'Reilly offerings I've seen. Big Nerd Ranch also has a book about programming the underpinnings of OS X called "Core Mac OS X and Unix Programming." Haven't seen this version book yet, but apparently it's the spiffed up, published version of BNR's student guide, so I'd bet it's pretty well done. You can get both together for $96.20 from Amazon.

    There are other good references, tutorials, as well, some free on-line, and some for purchase. Do some Googling and mining on Amazon or B&N to find one that suits your purposes.

    BTW, OS X has some very strong scripting capabilities built in that you might find useful for the kinds of apps you typically develop. And, as someone else noted, Ruby and other cool hacking languages come shipped with OS X and work well with XCode. Also, Eclipse, with all its goodness, runs nicely on OS X.

    Lastly, if you want to put the limitations of "modern" programming languages behind you and get back to the future of software development, OS X has some of the best OSS Lisp implementations. SBCL or OpenMCL (if you want to do Cocoa apps), plus SLIME and Emacs is all a real programmer needs, and it's all free. *grynn*

    --

    ---anactofgod---

    "Equal opportunity swindling - *that* is the true test of a sustainable democracy."
  15. Avail yourself of the online resources. by mellon · · Score: 4, Informative

    My three main bookmarks for Cocoa help right now are:

    http://rentzsch.com/
    http://www.idevapps.com/fo rum/
    http://www.zathras.de/angelweb/x2004-12-05b. htm

    The main challenges with Cocoa are learning how to navigate project builder so as to connect things up, and figuring out all the undocumented interdependencies between Cocoa objects.

    One of the things that really screwed me up for a long time was not realizing that the UI objects aren't re-entrant, so if you call a UI object from a thread other than the main thread, you're likely to get random crashes.

    The biggest thing for me though was figuring out project builder - figuring out how outlets and actions work. This is particularly a problem because there's no file you can edit to do outlets and connections - you have to do it with the GUI, and it's extremely counterintuitive. Once you figure it out it's easy, though. So it's good to just type your way through a couple of tutorials just to get the hang of it.

    If you want to look at some example source code, I have something up on sourceforge that's (a) not trivial, but (b) not heinously complex, so it might be worth looking at. http://www.sourceforge.net/projects/gofer

    1. Re:Avail yourself of the online resources. by cratermoon · · Score: 2, Informative

      Pretty good links. I found the tips and tricks on the CocoaDev Wiki invaluable in my work on the Objective-C port of FIT.

  16. You forgot the c in the link by acomj · · Score: 3, Informative
  17. Cocoa is the way to go by tim1724 · · Score: 4, Informative

    If you're serious about Mac OS X development and want to write applications which blend in well with the Mac environment (necessary if you expect Mac users to actually want to use your applications) then you must learn how Mac applications are supposed to look and behave and figure out how to apply the Human Interface Guidelines to your application. (Note that the HIG is not always 100% accurate .. there are places where you should deviate from it slightly in order to match what Apple's apps do.) This is important, as if you do anything unMaclike then your application will be bashed as a bad Windows port (even if you wrote it from scratch) and no Mac users will touch it.

    You have two ways to go in terms of APIs. Cocoa and Carbon. Cocoa is a refined version of NeXT's OpenStep. Carbon is a cleaned up version of the old Classic Mac OS API (but with a huge number of changes .. it is much improved.) Carbon is straight C code, and the concepts involved are more similar to Windows or X11 than Cocoa's design. But it's big and complicated, and would take a long time to learn. Also, there's a lot more stuff that you have to do in Carbon to make your application behave properly.

    Cocoa gives you most of the behavior for free. You'll write less code, and you'll probably end up with a more Mac-like application. (It's entirely possible to write a a well-behaved Carbon app, but you'll have a lot more to learn in order to do it right, as fewer things are done for you automatically.)

    With Cocoa you'll have to learn Objective C. This is not a big deal. If you know C, then you can learn the handful of additions which comprise Objective C in less than an hour. It's a very simple language.

    Theoretically you can program Cocoa apps in Java, but I do not suggest that you attempt this. Java does not really fit into the Cocoa model very well (it's not nearly dynamic enough) and was shoehorned in as a way to attract developers who refused to learn ObjC. This was a mistake on Apple's part, and they seem to have realized it ... they no longer promote the use of Java in Cocoa.

    I strongly recommend that you spend some time with Hillegass's book on Cocoa. Objective C an elegant language, and is certainly the fastest way to develop Mac applications.

    If you are a diehard C++ fan, then you may be better off with Carbon, but there will probably be a bigger learning curve as the Carbon libraries are more complex. (Carbon has a long complicated history, from its Pascal roots and old Classic Mac OS constructs (resource forks, FSspecs, Gworlds, etc.) and repeated changes in design (GetNextEvent() replaced by WaitNextEvent() and then Carbon Events, QuickDraw replaced by Color QuickDraw and now by Quartz 2D) so it takes quite a while to figure it all out.

    I'd give ObjC and Cocoa a chance first. You can always use Objective-C++ to combine an ObjC user interface with a C++ backend, if you need to port old code. Be sure to check out MacSTL as it provides some nifty stuff to treat some Core Foundation and Foundation objects in an STL manner.

    As for tools ... well, the Xcode IDE and all the GNU tools (gcc, gdb, etc.) come with Mac OS X, so you shouldn't need to buy anything.

    --
    -- Tim Buchheim
    1. Re:Cocoa is the way to go by commodoresloat · · Score: 2, Insightful
      (Note that the HIG is not always 100% accurate .. there are places where you should deviate from it slightly in order to match what Apple's apps do.)

      An important example of such deviation is Apple's use of tabbed browsing in Safari. And now I'd like to take this opportunity to remind slashdotters that tabbed browsing was something I predicted years ago, but was slapped down by others who said that tabs would never happen in Safari because they violated Apple's HIGs. I was modded down for my premonition, but I would like to point out that I was right all along! Now give me my mod points!!

      (Is there a +1, smug?)

  18. From a broader scope by nflu · · Score: 2, Informative

    If you're just looking to write little C++ apps to fill in the gaps (hey, that rhymed), then you should have no problem at all. gcc/++ runs from the terminal the same way it does in Linux. Everything is the same, libraries, commands, and all. I frequently work on C++ projects between a Fedora machine, FreeBSD machine, and OS X; and if you didn't tell me which platform I was on, I wouldn't be able to tell you. Xcode, on the other hand, is a whole other beast. I use it somewhat frequently, but if you're used to working with source files by hand and doing your own Makefiles, then don't even worry about Xcode.

  19. Not only GUI development on Mac OS X by treerex · · Score: 2, Insightful

    You are not limited to using XCode on Mac OS X. Once you have the developer tools installed you can use Make and Emacs (or VIM, or whatever) if you want. You could even install KDevelop and use that, if you wanted. You can develop with Qt and its tools as well, if you want to go that direction as well.

    You also don't need to develop in Cocoa, if you feel up to learning the lower-level Carbon APIs and do not want to write code in Objective C.

    I expect that someone has provided Cocoa bindings for Python, if you want to write "native" look apps with that. However, the existing Tk interfaces just work.

  20. OSX has many free, high quality development tools by babbage · · Score: 4, Informative
    As a professional Windows developer, what sort of expense am I facing to outfit a new Mac with development tools comparable to Microsoft's Visual Studio .NET, and what sort of learning curve should I expect

    Whether or not it's comparable is debatable, but every copy of OSX includes XCode, which is a full suite of graphical and command line development tools: programs, libraries, examples, and copious documentation. And it's free.

    So there's that.

    Additionally, if you get a copy of Tiger -- which a Mac bought now should either include or be eligible for an upgrade to -- then you get Dashboard, which will let you develop small desktop applications using, as I understand it, Javascript as the development language.

    So there's also that.

    Additionally, if you get a copy of Tiger, you will get Automator, which is a kind of graphical scripting application that can do all kinds of things. From what I can tell, it is going to be great in all the ways that the appropriately-acronymed AppleScript Studio wasn't.

    So there's that, too.

    Plus, every version of OSX has supported the full range of Unix shells and scripting languages, so you can write command-line, X11, and sometimes Aqua-based graphical applications using languages such as Perl, Python, Ruby, the Bourne shell, etc.

    So to top it all off, there's that.

    And to drive the point home, you get all of this for free with every Mac. I've heard nice things about Visual Studio, and maybe there's a lot it can do that the Mac side doesn't have, but I strongly suspect that the full range of programming, scripting, and automation tools available on the Mac will run rings around it without costing you a dime more than the cost of the computer [and OS, if you're upgrading, which you won't be in this case].

  21. Re:If you love .net by babbage · · Score: 2, Insightful

    I don't think that's the reasoning at work here.

    On Windows, the platform is mature and widely adopted, with a rich variety of software from independent vendors. Microsoft feels they can charge for the development tools, and does so.

    On OSX, the platform -- not counting the Unix foundation -- is young, with a comparitively miniscule pool of software vendors. Apple needs to grow the pool of available software for the platform, so giving their development suite away is a way to encourage more software to be available for the platform in the long run, and so to make the platform more viable in the long run. It's a short term expense, but a long term investment.

    The motivations on the two sides are different, so of course the approaches are as well.

  22. You're kidding, right? by JonTurner · · Score: 4, Funny

    >>XCode is far too bulky

    As compared to Visual Studio?!? Woah.

  23. After you install Xcode... by Chief+Typist · · Score: 3, Informative

    Visit these sites:

    CocoaBuilder for the Mac OS X and Cocoa developer list archives.

    CocoaDev is a Cocoa developer Wiki.

    I find that 99% of the questions I have can be answered by these two resources (especially newbie type questions -- which you're bound to have in a new development environment.)

    -ch

  24. Re:Amateur Here by TheRaven64 · · Score: 2, Informative

    If you are interested in cross platform development, take a look at GNUstep. GNUstep currently implements most of AppKit and Foundation from Cocoa as well as some extra frameworks (e.g. Address Book). The one down side is that they do not yet support OS X .nib files, so you will generally need to re-create these in GORM (the GNUstep equivalent of Interface Builder). If you develop on GNUstep, then it is usually trivial to port to OS X. If you develop on OS X, it is sometimes a little bit harder. If you find a bug in GNUstep while trying, then please file a bug report - it won't improve if the developers don't notice it needs to.

    --
    I am TheRaven on Soylent News
  25. Re:what you should expect by bar-agent · · Score: 2, Informative

    Unless you want conditional breakpoints

    You have conditional breakpoints. There just isn't a UI for 'em. Unless they added one in XCode 2.

    See http://developer.apple.com/technotes/tn/tn2032.htm l#conditionalbreakpoints.

    --
    i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
  26. Re:TrollTech's Qt by TheRaven64 · · Score: 2, Insightful
    If you create an app using Qt, then do not expect Mac users to use it. Qt deviates horribly from the OS X HIGs in some areas (e.g. the text area control behaves completely differently from the standard OS X one), giving a really jarring feeling when using Qt apps on a Mac.

    There is no such thing as a good cross platform GUI. Either your GUI fits with the native platform's HIGs, or it is cross platform[1]. You can not have both. Fortunately, good code abstracts the application logic from the UI, so it is not a great deal of effort to port.

    [1] Some UN*X desktop environments attempt to clone Windows, and so it is possible to run applications which have Windows-like UIs on these without it feeling too wrong.

    --
    I am TheRaven on Soylent News
  27. Re:As a Windows programmer.. by Paradox · · Score: 4, Insightful
    Look, it's one thing to say "I had a bad experience with XCode." It's another to say, "XCode is the worst thing ever." I can't even find words to describe how juvenille calling an IDE "stupid" is in this context.
    When you just want to build a damn executable it has you messing with build targets and all sorts of garbage that I will never care about.
    Umm, it starts out working with sane defaults. In practice, I almost never need to mess with those settings until the very last steps of my application. Not the beginning. The only thing you might mess with in there is what libraries you link, but that's the wrong place to add them.
    Sorry, but I liked my old way of working - you know, where I was productive and didn't have to learn the quirks of your stupid IDE.
    You're advocating Eclipse and claim you don't have time to learn the quirks of a "stupid IDE"? Gee, that's the pot calling the kettle black, don't you think? Eclipse is one of the single most... erhem... "feature rich" products I've ever seen. Learning it is more of a chore than learning emacs, and that's saying something.
    If I was ONLY developing for the Mac I might take the time to learn it.. but I'm not, so I will never waste my time on it.
    XCode is-say it with me now-a OS X Application Development Environment. If you're expecting it to be something else, prepare to have those expectations failed. It can do a lot, and it's a complete, lightweight IDE with a very natural way of organizing OS X projects and integrating with IB.
    ... AND I still get command-line compilation if I don't feel like using an IDE that day.
    You never lose it using XCode. xcodemake has always been there.

    It sounds like you had unreasonable expectations for XCode, and they weren't met. And now you think it's the tool's fault for being nothing more than what it is.

    --
    Slashdot. It's Not For Common Sense
  28. Re:As a Windows programmer.. by vocaro · · Score: 2, Interesting

    I don't know if I would call it awful, but it's definitely not all it's cracked up to be. Everyone here seems to be chanting, "Xcode, Xcode..." but I wonder how many of them have actually used Xcode on a project or if they are just echoing the conventional wisdom. ("It's free! And it's from Apple!")

    Now, I haven't tried Xcode 2.0 in Tiger, but I have certainly made some sincere efforts to use Xcode 1.5 for my C++ and Java projects, and each time I've given up and gone back to a plain old programmer's editor and the command line. Although I loved the debugger, trying to set Xcode's compiler options and other parameters is a nightmare. Everything seems buried in different places for no apparent reason, special buttons have to be clicked in order to switch to a certain mode that will uncover hidden settings, etc. It's just not very easy to use, and it takes quite a bit of getting used to. It's definitely not a shining example of usability, especially given Apple's reputation.

  29. Porting from Win32 to Mac OS X Doc by toph42 · · Score: 2, Informative
    Porting to Mac OS X from Windows Win32 API

    This doc is invaluable for Win32 programmers moving to Mac OS X.

  30. Don't forget GCC by not-enough-info · · Score: 2, Informative

    Mac OS X has X11 if you choose to install it with the BSD subsystem. Terminal, yep. If you want to go IDE-less you can use GCC on the command line. Fink! Download Fink Commander for hundreds of 1-click compile and install OSS. BBEdit is a nice editor.

    Personally I like XCode. I do most of my coding in it. I don't really like the SCM support, but svn on the command line works fine. C++ development is fine; you can use the Carbon API.

    For my school Java projects I work in Eclipse. Which, incidentally, works just fine also.

    --
    ---k--
    </stupid>
  31. Re:If you love .net by davidbro · · Score: 4, Informative

    >On OSX, the platform -- not counting the Unix foundation -- is young

    Are you kidding? Cocoa is based on NeXTStep, which has been actively refined since the late 80's. Win32 dates from the early 90's, and .NET is even younger still.

    Interface Builder, the primary Cocoa/NeXTStep GUI tool, was the first of it's kind. I saw it for the first time in 1989.

    The class library that makes up Cocoa is one of the most mature frameworks out there.

  32. Good Intro to Objective-C by EccentricAnomaly · · Score: 5, Informative

    Apple has a free mini-book that intros Objective-C and gives a good feel for its capabilities:

    ObjC.pdf

    I highly recommend it to anyone coming from a C++ or Java background who is wondering what the big deal about Cocoa is.

    And if this little PDF catches your Fancy, Aaron Hillegass has an excellant book: "Cocoa Programming for Mac OS X". Another good book is "Building Cocoa Applications" by Garfinkel and Mahoney.

    --
    There are 10 types of people in this world, those who can count in binary and those who can't.
  33. Re:Correction by Bastian · · Score: 2, Informative

    To the third point - ObjC objects aren't toll-free bridged to the Carbon libraries, they are toll-free bridged to Core Foundation, a procedural C set of libraries that is secretly most of what Cocoa is. But the end result is still that, if you need to, you can treat your Objective-C objects as C structs with no extra work.

    (Stupid me. I tend to (wrongly) think "C == Carbon" when I think about the OS X libraries.)

  34. Re:developer.apple.com by Moofie · · Score: 2, Funny

    I'm a DEVELOPER! I don't have time to READ your stupid DOCUMENTATION! If the computer can't read my mind, it's STUPID and BROKEN.

    Where's my Xanax?

    --
    Why yes, I AM a rocket scientist!
  35. Learn the OS first by shatfield · · Score: 2, Interesting

    I was you 2 years ago.... so listen up!

    Coming from Windows, you will immediately be immersed in a new environment that is sometimes very different from what you are used to. Coding on Windows (as I do, I'm a C# developer at my day job) is a whole lot different than coding for the Mac.

    I whole heartedly suggest that you buy a new Mac and dive right in -- but first you must learn how it works. The first thing you'll say to yourself is "everything is on the wrong side!". The icons are on the right, the window buttons on the left. If you think the differences end there, are you in for a surprise!

    So first, use the Mac, become very familiar with it, and know it. Read books, visit forums, learn how it works "underneath".

    And then start trying to find something to create.

    So here are the steps:
    1) Learn it
    2) Know it
    3) Code it

    Good luck!
    -Steven

    --
    "To make a mistake is only human; to persist in a mistake is idiotic." Cicero
  36. Top Ten Reasons to Become a Mac Programmer... by Space+Coyote · · Score: 4, Funny

    Just wrote these today, coincidentally... 10. All the blue-coloured widgets and background images are good for the soul. 9. You can keep a Terminal.app window open and pretend to be a Unix hacker. 8. Crappy enterprise data access support means no horrible database programming. 7. People will think you're some kind of artist or writer or something else less socially leper-ous than being a programmer. 6. Interface Builder's NeXTStep heritage will force you into a Model-View-Controller architecture so strongly that even design-as-you-go nitwits like me will be saved from their own poor planning. 5. No matter what you do, Wired will eventually write a feature story about you. 4. All the built-in eye candy and automatic alignment guides will make you look like you know something about UI design. 3. The development tools don't cost more than what your stupid shareware program will probably earn you. 2. The Indian programmer who stole your Windows coding job can't afford to buy a Mac. 1. Chicks dig iBooks.

    --
    ___
    Cogito cogito, ergo cogito sum.
  37. Like everything else... by menace3society · · Score: 4, Informative
    Switching to Mac development is like switching to the Mac in all other respects. If you're hoping for something that looks and behaves exactly like Windows, but has all the chick appeal of a Mac, you're not going to be happy. Apple does things very differently than Microsoft, and that is true of handling files, users, system programs, and so forth, and also of application development. Conventions are different for users, and they are different for developers as well. Apple gives *very* sage advice wrt interfaces; they've been at it, and been doing it better most of the time, than anyone else in the business.

    If you want help programming, plenty of people have given links. If you want help with the interface end of things, try using some of the best Apple applications and see how things "work"--iTunes, The Omni Group, Bare Bones Software, Lemkesoft's Graphic Converter, Rancho's NetNewsWire. There are many others, but trying these on should give you a feel for what makes a great Mac App. Also, it is a commonly-perceived problem that there is no great mac Word-processing software. There are acceptable entries, including MS Office, and several others, but this is one area where OS X is gravely deficient (if you want to write the best Mac WP ever, feel free! I'd even buy a copy).

    Lots of people (i.e., Windows & Linux Fanpersons) will deride many interface trends as "fluff"; do not make this mistake. Apple is pretty careful about what stuff they include, and while there might be a few things in there for no real reason (animated screensavers as you desktop background?), most of the "fluff" has a damn good reason to be there.

  38. NeXT retrospective (was Re:If you love .net) by WillAdams · · Score: 2, Interesting

    People who loved/used NeXTstep

    - John Carmack
    - Tim Berners-Lee
    - Andrew Stone

    Companies successful w/ NeXTstep (other than the afore-mentioned Omni):

    - Lighthouse Design (bought out by Sun to do Java development)
    - Stone Corp.
    - the company MCI hired to create the database which made ``Friends and Family'' work --- they liked it so much, they bought the company

    Programs w/ a heavy NeXT heritage:

    - Doom
    - WorldWideWeb.app
    - TeXshop (Alan Hoenig's book, _TeX Unbound_ is basically a paean to to glories of Display PostScript w/ TeX)
    - FreeHand (FreeHand 4 ~= Altsys Virtuoso 2 - bugs and w/o Services, DPS, &c.)
    - Softmagic's Project M (their sole competitor gave up on trying to code an equivalent in Windows and licensed their product instead)

    Oh yeah, and there's this little project called GNUstep....

    William

    --
    Sphinx of black quartz, judge my vow.
  39. Re: Obj-C learning curve by YOU+LIKEWISE+FAIL+IT · · Score: 4, Funny
    [object methodcall:parameter] isn't that much harder than object.methodcall(parameter)

    Further, if memory serves, it's actually syntactic sugar for objc_msgSend( object, "methodcall:", parameter );

    Of course, if you actually use it that way outside the debugger, I hear Steve Jobs personally flies to your house and takes your Mac away from you.

    YLFI
    --
    One god, one market, one truth, one consumer.
  40. Qt by Brandybuck · · Score: 2, Interesting

    Since there's a free native Qt for Mac, you should consider that as one of your options. A lot of Mac purists will discredit this option out of hand, simply because it's not a Mac-first framework. Don't listen to them, and make up your own mind. One of the chief objections is that it doesn't force you into Apple's interface guidelines. But at the same time, there's nothing stopping you from voluntarily following them, so I don't consider this a valid objection.

    If you're writing a bunch of small custom apps, and they don't need to be proprietary closed source, then Qt is free. Otherwise you do have to pay (gasp) for Qt. It's hard to tell from your description what you need, but I'm guessing you can get away with the free GPL version.

    I haven't played with the Apple frameworks, but compared to Microsoft's that you're used to, Qt will be a breath of fresh air!

    --
    Don't blame me, I didn't vote for either of them!
  41. Re:Parent is Troll? by amichalo · · Score: 2, Interesting

    The reason I think the parent is a web coder is because he mentions TexTEdit and BBedit for coding.

    Wow, you're a real detective!

    [from the parent "troll" I authored] I develop .NET web apps at work on XP but have a Mac at home. [/]

    Comparing a php app written in BBedit and an asp+ app written in VS.Net is less than fair and pure trollbait, since I cam write a php app in notepad on Windows as well, but I would need to be seriously dumb to do that wouldn't I?

    This comment is completely inaccurate. First of all, to write ASP or ASPX pages, one does not need VS.net, all they need is a text editor (one could even use "copy con foo.asp" from the command line if they wish!) The same holds for php, HTML, css, perl, etc on all platforms, Mac or Windows.

    What using an editor like BBEdit gets you is a customized environment to provide contextual command support for the language of choice (php, asp, perl, coldfusion, etc). What Integrated Development Environments (IDEs) like VS.net and XCode get you (besides a compiler) is the ability to harness the power of object oriented coding right in the editor so you get the power of an editor + compiler + object access right in the code.

    BTW, your Caps Lock key is sticking.

    --
    I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
  42. $1295 by YouHaveSnail · · Score: 3, Informative

    As so many others have pointed out, Xcode won't cost you a cent beyond whatever you decide to spend on a Mac (which could be anywhere from $500 to $3000, depending on you). And there are lots of free resources for learning about Mac programming, and lots of books.

    If you want to get a taste of the cutting edge of Mac development, however, go to developer.apple.com and buy yourself a ticket to Apple's Worldwide Developer Conference, a.k.a. WWDC. Depending on where you live, you may also need a plane ticket and a plane ticket and a hotel room or a pal in San Francisco that you can crash with. Anyway, at WWDC you'll meet a few thousand Mac developers and attend sessions given mostly by Apple engineers on .

    Attending WWDC is definitely not something you _need_ to do, particularly if you're just starting out. But it's a lot of fun, and you might just see stuff there that will make you decide to sell your PC.

    If you decide to do it, do it soon. You can get a WWDC ticket now for $1295, but prices go up to $1595 on April 22.

  43. Re:relative age (was Re:If you love .net) by WillAdams · · Score: 2, Insightful

    Cocoa, nee Rhapsody, nee Yellow Box, nee OPENSTEP is _not_ part of the ``Unix foundation'' of Mac OS X --- one can see what OS X's Unix has matured to in Darwin, and Cocoa ain't there (which brings up an interesting question of how nice an environment would Darwin and GNUstep be).

    NeXT used to charge a _lot_ more for their Dev tools for a while (they started out as free, then were an optional install, then were ~$4,995 and now are free again). The price change tracks pretty closely whether or no the company expects to make money on hardware --- since it's not feasible for Microsoft to bundle Visual Studio w/ an IntelliExplorer mouse and expect it to be used, they don't.

    William

    --
    Sphinx of black quartz, judge my vow.
  44. My experiences moving from win32 to cocoa. by l4m3z0r · · Score: 3, Interesting
    During my senior year of college I decided I wanted exposure to OSX development so I got myself a mac, installed the dev tools and went to town with the same assignments I had for my MFC/C++ programming class. Turns out what took me a semester to do in MFC/C++ took about 3 weeks using Cocoa/Objective-C. I then decided to port a semester long project from win32 MFC/C++ code from visual studio to OSX and hell that took about 2 weeks. Apple has what they like to call Objective-C++(which allows you to mix, objective-c, pure c, and c++ code in the same project) and I just plopped about 85% of my code into the project and bam it worked WITHOUT EDITING, it took me roughly two weeks to build it a new interface and link up all the actions properly.

    All I have to say is that Apple documentation is very bad and mostly unhelpful. Learning Cocoa/Objective-C from oreilly is near useless. In fact I did 2 examples from it following its directions and havent used it since. Learning Objective-c and Cocoa to the point where an advanced reference is what you need is borderline trivial. I suggest not bothering with introductory texts and simply grab some examples work through them, muck around with adding a few controls to them and you will be all set.

    Really, if you know C you will have no problem moving to Objective-C, and Cocoa is in my opinion very very intuitive making MFC look like a bastard child.

  45. Re:Parent is Troll? by cosmo7 · · Score: 2, Funny

    Comparing a php app written in BBedit and an asp+ app written in VS.Net is less than fair and pure trollbait, since I cam write a php app in notepad on Windows as well, but I would need to be seriously dumb to do that wouldn't I?

    Yeah, as dumb as <SPAN></SPAN><SPAN></SPAN><SPAN></SPAN><SPAN></SPA N><SPAN></SPAN><SPAN></SPAN><DIV> </DIV><SPAN></SPAN><SPAN></SPAN><SPAN></SPAN>

  46. Here's my offering... by GrahamCox · · Score: 3, Informative

    OK, I'm late to this thread, and no doubt you have a clear picture already. But I'm a long-standing Mac developer steeped in C++ who also recently bit the bullet and changed the way I program on the Mac (from Carbon/C++ to Cocoa/Objective-C). OK you may say, but that's not as big a leap as Windows to Mac... well, I think it is. There are very few overlapping APIs, unless you want to use Carbon within Cocoa, which so far I have found very little need for except a bit of bridging to QuickTime.

    So: 1. XCode comes with the OS. It comprehensive, it's good. I'm still learning it, but the basics are easy to grasp and you can fill in the finer detail as you go along.
    2. Objective-C is a VERY SMALL addition to C. You can learn it in half an hour especially if you know C++. The syntax might look odd at first glance but it works, it's consistent, and it's only syntax!

    3. The framework (Cocoa) is huge, and takes longer to learn. However, again you can get going very quickly because XCode will build a fully functioning app for you with no coding at all, then you can use that as a base on which to experiment. Personally I'd suggest you do spend a bit of time experimenting without trying to build a huge new app first go, because there are different ways of doing things, some not as good as others. But gradually the picture becomes clear.

    4. Get a book. I recommend Aaron Hillegass's tome - well written, easy to understand, the examples work, and it touches on a lot of useful areas of the framework though in some cases could do with a bit more depth. The O'Reilly book is not as good in my opinion, I found it only started to make good sense after I'd read Hillegass and actually tried out some coding.

    5. Be prepared to be amazed at what Cocoa can do and how it works. After years of C++ grinding, Cocoa is a breath of fresh air to me. Objective C is so much to the point, but avoids all that syntactical cruft that C++ has. It makes me realise that half the code I've ever written was there just to keep the language happy, rather than contributing to my actual productivity. Objective C's method lookup is incredibly flexible and makes things possible that you wouldn't even think of in C++. In that respect a C++ background can be a liability - many things turn out to be much simpler to do te Objective-C way than what you might think of at first. For me this was one of the steepest aspects to the learning curve, but also one of the biggest revelations. For example, look at how Undo is handled - it's gobsmackingly easy. After a while you'll start to wonder why other platforms don't have anything like this. Cocoa is what Java could and should have been.

    6. Enjoy yourself - it's fun to program in Cocoa. Once you get on top of it you may find, as I have, that your programming ambition suddenly increases enormously. With Cocoa I feel I COULD write a Photoshop killer, if I wanted to....

  47. Re:*Modern* Mac development? by ArmpitMan · · Score: 3, Interesting
    I don't know much about Java Beans, but the documentation that Sun is giving me about them doesn't give me much reason to connect the two. In fact, it sort of looks like Java Beans are Sun's version of NeXT's Interface Builder. Which is, as I said, nice.

    You know Model-View-Controller? Interface Builder is a tool to build the view, and tie it to the classes of your application. Before Cocoa Bindings and Core Data, you would create a custom controller class or two, and connect them up. This button fires this action, which calls this method of MyAppController. MyAppController updates the model, then does some updates to the view. Grueling, thankless glue code.

    Cocoa Bindings are a set of generic controllers, coupled with some tools in the IDE, that let you bind the view to the model in various complex ways while writing no boilerplate glue code. Say you have an array of objects in your data model. Cocoa Bindings lets you use an NSArrayController and a couple of straightforward bindings to say, "Fill this combobox with the 'name' field of each object in this array, and when a selection is made, populate these other fields with their other properties."

    Core Data, though you didn't ask, is a set of generic tools that take care of the model, and gives you things like data persistence, undo, etc. for free. With Core Data and Cocoa Bindings together, you can go so far as to build UI scaffolding -- you literally drag one of the entities from your data model into a blank window in interface builder, and it builds a prototype interface for you. Not one you'd want to actually use, of course, but it gets you going and makes for a nice demo (see: Ruby on Rails hoopla).

    As you might imagine, these tools take care of a lot of the grunt work of building graphical applications.