How long does it take to learn how to program for Mac OS X?

July 26, 2007 12:44 AM

How long does it take to learn how to program for Mac OS X?

I frequently have ideas for applications that I wish existed, and am trying to figure out whether it's worth learning how to make them myself (as a hobby -- I have no professional programming aspirations).

Based on the answers to a previous AskMeFi question, it seems like the best approach is to start with Kochan's Programming in Objective C and then move to Hillegass's Cocoa Programming for Mac OS X.

I don't have any experience with serious programming languages, but over ten years ago was pretty adept with BASIC. I'm a pretty quick study in general, though.

Realistically, around how many hours would it take to gain enough proficiency to make useful applications?

posted by Ø to computers & internet (14 comments total)

Depends who the applications are going to be useful for.

If you were adept with BASIC ten years ago, you should get to Hello World in a completely new platform within hours to tens of hours, and you will probably be able to produce useful little bits and pieces to scratch your own itches in a few hundred hours.

It will take you tens of thousands of hours to get proficient enough to knock out commercial-grade apps. But then, it takes tens of thousands of hours to write commercial-grade apps. So the best thing to do is just get started on the drive toward your first one, but plan to throw it away. Then start your second one, and make that the first thing you release. By then, you'll have enough knowledge and experience to do a competent rewrite of the first one.

Bear in mind at all times that good code is what remains after you've deleted nine tenths of what you've written, and you won't go too far wrong.

The very first thing you should do is install a good source-code revision control system (like subversion) and work out how to drive that.

Once you have enough experience with your chosen implementation platform to feel comfortable with it, get into the habit of writing unit tests for all the code you create. Not only will this force you to consider exactly what it is that you really want each unit to do, it will force you to think through the edge cases - and this process often leads to insights that can make you decide to approach coding from a slightly different direction, or break it into modules in a slightly different way that will work better for you. The question you should always be asking when you've written a chunk of code is "how can I be sure this code does what I think it does?" And this is true in any language and/or framework.

Go for it! Enjoy!
posted by flabdablet at 1:06 AM on July 26, 2007 [1 favorite]

If you're thinking in terms of hours, not weeks or months, you've got the wrong hobby.

Seriously, though, this is not really an answerable question. It depends entirely on what you want to accomplish, and what you consider a "useful" application to be. You could probably figure out how slap a UI on top of some existing code in a few days to a week, starting from scratch. If you want to write a web browser or database, it'll be more like years.

It's like asking "How long does it take to learn to write?" -- it depends entirely on what your goal really is. Learning to write your name: a few months (starting from nothing). A term paper? Longer. A great novel? Much longer, if you've even got it in you.

(And the variation is enormous: some people could never write that novel if their lives depended on it, and some managed it before they hit 30. Talent and circumstances matter a great deal.)
posted by xil at 1:13 AM on July 26, 2007

"If you're thinking in terms of hours, not weeks or months, you've got the wrong hobby."

I realize that it's a longer-term project, but specified hours because different people devote different amounts of time each day.

One person might spend only an hour every week; another might become a "programming monk" and devote every waking hour for a summer. Actual work-hours are a more objective measure.
posted by Ø at 1:20 AM on July 26, 2007

Objective-C is a very thin layer on top of C. To understand ObjC, a basic understanding of C is important. Objective-C programs, however, are very different than C programs in that they are structured around objects, not procedures. An understanding of object-oriented design is thus also critical.

From here, you must learn about the Cocoa frameworks, which are in two parts. Foundation includes important classes like NSString, NSDictionary, and NSArray, which you will use constantly. AppKit revolves around the event loop, windows, views/controls, and the responder chain. Learn about each of these topics and you should be well on your way to being a Cocoa guru.

Then there's Interface Builder. What you see in Interface Builder are simply Objective-C objects. Every kind of object you can make in IB has a way to save and restore its state into a "NIB" file. As well as the objects themselves, the NIB stores connections between objects — outlets and actions. Outlets are instance variables that can be automatically set when the NIB is loaded, and actions are functions that a control will call when it is activated. It's a much better way of building user interfaces than anything else I've seen (with the possible exception of Self's Morphic ;). This is the fun and easy part of OS X development.

So that's an overview of the language, libraries, and tools you'd be learning about. You can probably figure out write a Cocoa application without mastering every level, but it helps to understand what's really going on. I don't know how long all this would take to learn, but IMO it's worth it. Cocoa really is the cutting edge of application development (even though it hasn't really changed much since it was part of NeXTSTEP in the 80's).
posted by panic at 2:23 AM on July 26, 2007

Everyone seems to be jumping on Cocoa and Obj-C. That's not the only way to create programs for OS X - depending on the complexity of your project, you could start with AppleScript, or Python/Ruby might even be more appropriate. A couple years back, you might even have been able to play with Java, but Apple have now deprecated the Cocoa/Java bridge.

I'd advise taking a look at http://developer.apple.com/ - there are some nice Cocoa tutorials there, and you'll be able to quickly see how long it takes to knock together a simple temperature/exchange rate converter application using the full suite of XCode/InterfaceBuilder tools. You may well find that that's something you're happy with with your project, or that you might want to explore a Python/Ruby approach with Cocoa bindings.
posted by danhon at 6:32 AM on July 26, 2007

The advice here is good if you want to become a super proficient programmer. I'm not sure learning SVN and writing Unit Tests and what not is the best way to go if you just want to bang out some simple applications. I'm pretty sure you'll get sick of programming before you get proficient at it if you follow that route.

For starters, Cocoa and Objective-C aren't the only way to write applications for MacOS X.

Real Basic is a sort of cross platform visual basic, and you can write all sorts of simple applications with it.

I'm pretty sure you can use Interface Builder and Applescript together as well.

Also keep in mind that Mac OS X is based of Unix, so if the sorts of applications you are writing don't need a GUI, you can program them in any old programming language, like Ruby, Python, Perl, etc, etc, etc.
posted by chunking express at 6:42 AM on July 26, 2007

Let me toss in another vote for Real Basic. I'm not a professional programmer at all - I'm a woodblock printmaker - but it took me around two months of casual evening time from start to finish, to create a comprehensive billing/inventory/bookkeeping system for my business using it. And it's not expensive at all ...
posted by woodblock100 at 6:52 AM on July 26, 2007

if the sorts of applications you are writing don't need a GUI, you can program them in any old programming language, like Ruby, Python...

Or if they do need a GUI, you can still use Ruby and Python, of course.
posted by signal at 7:08 AM on July 26, 2007

Re: Ruby, as far as I know, Leopard will have built in support for the Objective C bridge to Ruby. Learning Ruby will be easier on your head than learning C, while still having all the native gui components afforded to you by Cocoa.
posted by cschneid at 7:10 AM on July 26, 2007

Thanks for all of your great comments so far!

To respond to a few themes that have popped up:

1. Real Basic is attractive from the perspective of instant-gratification, but my [uninformed] assumption is that serious programmers don't use it for a reason. As long as I'm investing the time to learn a language, I'd like it to be one that won't prove limiting in the future (if things go well).

2. I'd like to be able to produce a normal Mac GUI at some point.

3. Several people have mentioned that Ruby is easier... what's the downside (compared to Objective C)? What about Perl?
posted by Ø at 9:09 AM on July 26, 2007

With respect to point one, learning Real Basic really isn't a hindrance. I learned to program in Pascal. I haven't written a line of Pascal since high school, but what I learned from using Pascal I carried forward to the next language I learned. Jumping right into Objective-C may be daunting. The syntax is obtuse to say the least.
posted by chunking express at 10:01 AM on July 26, 2007

As long as I'm investing the time to learn a language, I'd like it to be one that won't prove limiting in the future (if things go well).

Learning only one language will prove limiting in the future.

That which you learn from RealBasic, or any of the other suggestions here, is very much applicable to any other language you learn. The important thing is to look at a couple of examples of simple applications and go with whatever makes the most sense to you.

Instant gratification does have some value when it comes to starting a new hobby.
posted by cCranium at 10:13 AM on July 26, 2007

(everything panic said and...)

I've been playing around with Objective-C on and off for two plus years and I think I understand it well enough but I don't have that great of a grasp of it. I had been using AppleScript to automate a lot of complex tasks in print production for about a decade so that helped me approach it but in the two years of learning Cocoa, I've taken seasons off and I haven't taken it too seriously so my results aren't really indicative of what time you might actually need.

On a superficial level Objective-C can be easy to pick up though a little tedious to code. You can almost get away with not knowing any C beforehand, but only almost. It's pretty easy to put together simple applications, so much so that you can create a text editor or a web browser with little to no code. One of my first apps I built parsed XML documents and presented the tags, tag attributes and tag contents in an outline view. And it didn't take long. As soon as you try to get really serious and explore beyond the basic set of tools, things can get really hairy, even with a good grasp of how Objective-C works. And it only gets worse when you try to create custom UI controls. Even something that might seem simple, like displaying an icon in the same table field as the icon label, can be a difficult puzzle without any experience in UI customization or example code.

Apple has also been adding more abstract controllers that can significantly reduce the amount of code you have to write but I've found them rather confusing. It seems they would be better suited to very experienced programmers who already have a comprehensive understanding of Objective-C, which emphasizes panic's point that it helps to understand what's really going on.

After diving in at the beginning, I always ended up hitting a wall with no readily-available help online, so I decided to take a more patient approach and first focus on the basics of Foundation, strings, dictionaries, and arrays. This has been extremely productive and has resulted in a library of underlying model and control objects that are thoroughly tested and ready to be linked to the UI. I've since been focused on the next level, UI customization, but with the promise of a somewhat different approach in Leopard and with a new version of Interface Builder (finally), I've been in wait mode (and a bit of impatient mode since it was delayed until October).

I started off with a bunch of online tutorials and a few books, Cocoa Recipes for Mac OS X by Bill Cheeseman, Cocoa Programming for Mac OS X by Aaron Hillegass (which you mention), and Advanced Mac OS X Programming by Mark Dalrymple and Aaron Hillegas. Most of the online stuff came from CocoaDev, Cocoa Dev Central, O'Reilly MacDevCenter, and CocoaBuilder, which is a online archive of the Apple cocoa-dev mailing list. I got some example code from Matt Gemmell, Ken Ferry, Chad Weider , Dave Batton, Rainer Brockerhoff, and others. Apple also has a bunch of example code that can be found in searches of the developer documentation in Xcode.

Obviously, a serious commitment to learning Cocoa will get you much better results than my two years on and off to become adequate but severely lacking, but I still imagine that you'd need at least a year to become proficient enough to approach most programming challenges with some semblance of confidence. Your question doesn't really imply that's what you're after, though. To learn how to make a useful but basic app could be only a few weeks depending on what you think is useful and basic. It would have to be pretty basic. The XML app I described above took me about two months of learning and about three weeks of programming, testing, and refining. And it wasn't very useful. I can't really break that down in to a number of hours but I know when I get on programming binges, I can put in about 20 hours a week.

If you want to make an app that will be released to the public, I'd advise a lot more time.
posted by effwerd at 11:14 AM on July 26, 2007 [1 favorite]

Just a note if you're keeping an eye on this thread - if you've gone the Ruby route, you could start doing basic GUI stuff with Shoes by why the lucky stiff.
posted by djgh at 7:05 PM on September 10, 2007