Zen and the Art of Programming » Cocoa and Objective-C

Programming in Objective-C, 3rd Edition is out

Antonio Cangiano — Thu, 23 Jun 2011 19:50:09 +0000

Addison-Wesley quietly released the third edition of their Programming in Objective-C book (USA | UK | Canada). I own the first edition of the book and it’s stellar, so I’m really looking forward to reading this upgraded version which includes the latest changes to the language, the main IDE (XCode), and the Foundation framework for developing Mac, iPad, and iPhone applications.

No related posts.

Would you use a Mac mini as your development machine?

Antonio Cangiano — Thu, 17 Jun 2010 11:23:53 +0000

Apple just released a brand new, gorgeous looking Mac mini. This major upgrade brings us two different models: a desktop one and a server version (priced at $699 and $999, respectively).

Equipped with a HDMI port, the desktop edition of the Mac mini makes for a perfect Home Theater PC. It’s small and stylish, and as such is a great fit in your living room. Most of the reviews I’ve read focus on its use as a highly capable HTPC (despite its lack of a Blu-Ray drive).

However, I see the new Mac Mini in a different light. At $700 it is far too expensive for a HTPC, yet it’s ideal as an entry-level machine for web, Mac, and iOS development (it’s almost as cheap as a Hackintosh, minus the headache).

Mac Minis will do the job and be more than capable thanks to their adequate, albeit not spectacular, hardware specs. If my MacBook Pro were to die today, I would definitely consider purchasing one for development purposes. Would you?

No related posts.

Why MacRuby Matters (Present & Future)

Antonio Cangiano — Sun, 29 Mar 2009 05:33:09 +0000

Over the years the inadequacy of Ruby’s main implementation has led to the creation of several alternatives. The greatest common divisor between these is an attempt to improve the performance of Ruby, both in terms of time and space. But every Ruby implementation has another, deeper reason for being. For example, Ruby 1.9.1 is a refactoring of the language that provides the chance to incorporate several much needed features into a relatively fast virtual machine, whereas JRuby’s truest value lies in its ability to interact with the Java ecosystem. Likewise IronRuby (which is admittedly at an earlier stage in its development) is attempting to plug a dynamic language like Ruby into the .NET world (as per its predecessor IronPython).

While MacRuby is a younger, lesser known implementation, it has the potential to become a game changer – at least for Mac developers. Based on Ruby 1.9, MacRuby’s main aim is to provide programmers with the ability to write Mac OS X applications in Ruby, making Ruby a first class Cocoa programming language. In what may sound like an utopistic effort, MacRuby strives to provide the high level abstractions, power and syntax sugar of Ruby, without the characteristic performance hit of its main implementation.

Rather than relying on a mix of Objective-C and Ruby (through a bridge like RubyCocoa), developers can use MacRuby which integrates with Mac OS X core technologies and acts as an alternative language to Objective-C. To be exact, Objective-C’s runtime and generational garbage collector are at the heart of MacRuby, but from an API standpoint, programmers can write code in Ruby, instead of in the more verbose and low level Objective-C. MacRuby maintains the ability to integrate with Objective-C code, but doing so is often unnecessary thanks to a framework known as HotCocoa, which is a Ruby wrapper around the Cocoa API.

MacRuby applications end up being succinct, easy to write and straightforward to maintain. Their look and feel is exactly the same as those of applications written in Objective-C, because they are actually native Cocoa applications. In fact, MacRuby objects are Objective-C objects which use Core Foundation data types and services. The current version, MacRuby 0.4, even allows you to package applications as self-contained .app, without having to redistribute MacRuby itself.

Sponsored and developed by Apple, MacRuby 0.4 is a stable release that can be – and already is – used to write desktop applications. But MacRuby’s real promise lies in its experimental branch. This rewrite will become MacRuby 0.5, as announced by the MacRuby team earlier today (along with a new, nice looking site). This future version of MacRuby is freakishly fast and uses the LLVM to generate code for the Objective-C runtime. The layer composed of LLVM, ObjC Runtime, Generational Garbage Collector and Core Foundation make this specific Mac OS X release possible. To this layer, add in Ruby 1.9′s AST parser and Standard Library, and you get MacRuby 0.5 as it stands today. In the future it’s likely that applications built with MacRuby will be compiled into binary code, like Objective-C ones, thus removing the issue of protecting one’s source code in commercial applications.

To really understand the value of MacRuby, consider the following Hello World program that uses RubyCocoa:

require 'osx/cocoa'; include OSX

app = NSApplication.sharedApplication

win = NSWindow.alloc.initWithContentRect_styleMask_backing_defer(
    [0, 0, 200, 60],
    NSTitledWindowMask|NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask,
    NSBackingStoreBuffered, false)
win.title = 'Hello World'

button = NSButton.alloc.initWithFrame(NSZeroRect)
win.contentView.addSubview(button)
button.bezelStyle = NSRoundedBezelStyle
button.title = 'Hello!'
button.sizeToFit
button.frameOrigin = NSMakePoint((win.contentView.frameSize.width / 2.0) - (button.frameSize.width / 2.0),
                                 (win.contentView.frameSize.height / 2.0) - (button.frameSize.height / 2.0))

button_controller = Object.new

def button_controller.sayHello(sender)
 puts "Hello World!"
end

button.target = button_controller
button.action = 'sayHello:'

win.display
win.orderFrontRegardless

app.run

And compared to the equivalent MacRuby and HotCocoa program:

require 'hotcocoa'
include HotCocoa

application do |app|
 win = window :size => [100,50]
 b = button :title => 'Hello'
 b.on_action { puts 'World!' }
 win << b
end

The first approach reminds me of Objective-C, the second is a pure Ruby DSL.

Benchmarking the experimental branch

The question on many readers minds is probably, how fast is it? To begin with, the start-up time is negligible which is a good quality for desktop applications to have. Using the YARV tests that ship with the experimental branch, let me show you the numbers I obtained on a Mac Pro with two Quad-core Intel Xeon 2.8 GhZ and 18 GB of RAM. The tests were also run on much less “beefier” hardware with analogous results.

All the usual disclaimers apply here. These are just a few very basic micro-benchmarks that should give you a “feel” for how two VMs stack up against each other; but don’t read too much into this and don’t expect it to be a scientific report on the performance of the implementations that were tested. Also keep in mind that MacRuby 0.5 is currently an experimental release, and while it’s able to pass RubySpec’s language specifications, it is not a complete implementation so far. The team is taking incompatibility issues seriously though and will make sure MacRuby will be able to run any Ruby code.

The following table summarizes the results of these benchmarks for Ruby 1.8.6, Ruby 1.9.1 and MacRuby 0.5:

This table shows the ratios between Ruby 1.9.1 and MacRuby 0.5, respectively, against the Ruby 1.8.6 baseline. When you see a number 4, for example, that means that the given implementation was four times faster than Ruby 1.8.6.

And here is a direct comparison between Ruby 1.9.1 and MacRuby 0.5. In this case, a number 4 (for example) would mean that MacRuby was four times faster than Ruby 1.9.1 for the given test:

The following chart should help you better visualize the results shown in the first table (click on it to enlarge the picture):

Even when you consider the disclaimer above and the trivial nature of the benchmarks themselves, it’s clear that at this stage of the game, MacRuby 0.5 is built for speed. ~~the fastest Ruby implementation around~~. MacRuby literally dominates Ruby 1.9.1. On “average”, according to these limited tests the experimental branch of MacRuby appears to be roughly 3 times faster than Ruby 1.9.1 (YARV), and in some cases even faster than that. You should definitely find this impressive.

For full disclosure, I’d like to explain the most likely reasons behind the four tests in which MacRuby is slower than Ruby 1.9.1:

bm_app_raise: MacRuby opts for cost free IA64 exceptions. What this means is that begin/rescue clauses don’t require a setjmp() like YARV does, but in case of exceptions at runtime, raising an error is more expensive. Of course, exceptions are… well, exceptional, so this has a trivial impact on real world programs.
bm_app_mergesort: Array operations are currently suboptimal. Slight improvements are expected.
bm_so_object: MacRuby’s object allocation tends to be relatively expensive. If you are allocating a zillion objects in a test, MacRuby will pay a hefty price for it.
bm_so_random: The performance of Fixnum has been optimized in this early release, but both Bignum and floating point operations are still suboptimal. Work is in progress and major improvements are expected to occur in future versions. In the case of Bignum, vectorization will do the trick.

The take home lesson

MacRuby is a serious project that fits in, and serves the flourishing market of Cocoa applications well. Its experimental branch is a major rewrite that, ~~grants this implementation the title of fastest Ruby in the West~~ that, much like Unladen Swallow for CPython, could become a very fast alternative to Ruby 1.9.x and JRuby. It’s mainly aimed at the desktop world, and as such the question of when it will work with Rails, is less pressing than it was in other early Ruby implementations. What’s certain is that Ruby is going to become a first class “scripting” language and a common choice for desktop applications on Mac. And should the difference in performance still remain in future, stable versions, it’s not hard to imagine that Apple’s server segment could also benefit from this, when Rails support becomes available.

Update (2009-04-04): I’ve modified a controversial statement since, technically speaking, while it is true that a very fast, incomplete implementation is promising and worth getting excited about, it cannot be considered the fastest Ruby implementation until a great degree of compatibility has been reached. This doesn’t diminish the value of MacRuby in any way, but rather draws a more accurate conclusion about the data that’s available today. It’s also worth noting that the few benchmarks that have been mentioned here are only part of the story. Speed aside, MacRuby’s aim and potential for Mac development still stand.

The image at the top of the post was generated by James Reynolds with HotCocoa::Graphics, a Processing-like library that uses Mac OS X’s graphics capabilities and makes them available to MacRuby.

No related posts.

Don’t alienate developers

Antonio Cangiano — Thu, 25 Sep 2008 21:49:14 +0000

Remember Ballmer shouting ad nauseam “Developers, developers, developers”? I’m sure you’ve seen the original video and even a few techno remixes. Whether he truly meant it or not, his message was correct: it’s all about developers. Any platform that doesn’t attract developers is bound to fail.

Microsoft is trying to make an effort to please developers by shifting to a more open attitude towards the development community. Their record is far from pristine, but at least they are making a concrete attempt not to piss off programmers who chose to develop for any of their platforms – efforts which are rarely acknowledged.

Apple, a company that is generally considered far from “sinister” or “evil”, on the other hand, is trying their best to alienate developers. This is a crucial and costly mistake, even if they are a hardware company whose interest is mostly centered around their phones at this stage.

Their first idiotic move was to place an NDA on a finished product like the iPhone SDK (including the final version). For the ecosystem surrounding a platform to flourish, it’s fundamental that developers are able to freely share their knowledge. This move has many repercussions including the inability to publish books on the subject, something that is clearly a stepping-stone when it comes to being able to reach a broad audience of programmers.

Apple then decided that it was a good idea to charge people for the privilege to develop for the iPhone: $99 (that’s a hundred bucks, we are not idiots and this is not a grocery store). Thousands of other developers would have likely given it a shot and tried to tap into this new platform (and market opportunity), or simply experimented with it to satisfy their intellectual curiosity. But putting a $99 price tag on the Standard Program will push away the silent majority of potential developers and surely most freeware authors. Why would Apple do this? For a few extra bucks? That is nothing short of nearsighted thinking which only benefits a company in the short term and does serious harm in the long run.

These were two blatant mistakes, but, if you can believe it, Apple managed to alienate developers further still. A few thousand people put up with the NDA on the SDK, with the cost of the Standard Program, and with the lengthy and bureaucratic process it takes to access the only viable distribution channel, the iPhone App Store. Some of them spent months trying to create excellent, innovative applications for the iPhone, only to see their work rejected for no good reason other than that it competed with Apple’s own products (e.g. Podcaster) or was inconvenient for their business partner AT&T (e.g. NetShare). How shortsighted is that? It’s almost as stupid as the RIAA, which has a habit of suing its own customers.

Following the uproar of complaints about this, Apple decided that the best way to deal with developers’ malcontent was to legally bind them to shut up. So now the rejection letters many developers are receiving are covered by an NDA as well.

How low will Apple go? I understand that a few developers are making a good deal of money from some popular applications, and that the iPhone is a hot product which may change the mobile world. I can even grasp that programming in Objective-C is fun. But how many developers is Apple alienating, how many great applications will never be written because programmers object in principle to developing for Apple’s platform?

I fail to see Apple’s usual business insight and only see blind greed, the kind that acts as a highly effective cautionary tale against developing for Apple’s platforms. This all comes at a time when Google is promoting a truly open platform, Android, which poses a few challenges due to the heterogeneous nature of the devices it will be deployed on, but is equally interesting from a technical standpoint. Google even went so far as to award ten million dollars in prize money through a contest that they held, to attract new developers and applications. Android is definitely welcoming new developers and it’s doing so free from glaring restrictions and limitations.

I suspect that many will put up with Java, to get a cup of freedom.

No related posts.

Ruby, Python, Haskell and Objective-C Feed Survey

Antonio Cangiano — Tue, 27 Nov 2007 10:30:33 +0000

Having little time to follow the blogosphere and its crazy rhythms of publication is not a good enough excuse for not being up to date. This rings particularly true for me as a technical evangelist at IBM, and as someone who is deeply passionate about the development and the information technology world. The biggest challenge is to quickly and efficiently divide the wheat from the chaff or, in other words, filter out the noise from the overload of signals put out there. For me, feed readers are life savers, I couldn’t cope without them.

I recently adopted a setup that seems to be working particularly well. I purchased NetNewsWire for my Mac and FeedDemon for Windows, and automatically got a one-year subscription to the online premium service from the fine folks at newsgator. The two programs are a joy to use, especially for handling very large group of feeds in a short amount of time, as I often need to do. Each program automatically synchronizes with the newsgator service, therefore no matter which computer I’m using, I’m always dealing with the same folders, subscripted feeds and saved clipping. Sure, there are free services out there like Google Reader or Bloglines, but to me there is no comparison between the experience that I have when using a sluggish web interface and a rock solid, well designed desktop application. If I have the option, I’ll always choose the latter, especially since newsgator allows me to take advantage of a centralized repository of feeds from my desktop programs, just like as if I were using their online service through Firefox. For a few dollars, I got a setup that is working awesomely well for me and it’s saving me huge amounts of time. It also helped me to identify non-updated blogs, and those that I was no longer paying attention to, therein allowing me to reduce my over-all amount of feeds (granted with a conscious effort on my part) to a more manageable total of 160.

As mentioned above, my subscribed feeds are important to me, with a list that changes dynamically over time, as I add and remove entries. That said, I was looking at my Ruby and Rails folder when I decided to share my feeds with you. The list is understandably incomplete (after all, there are thousands of Ruby related blogs) and the presence of planets, aggregators and tags in bookmark services like del.icio.us, generate a few unavoidable duplicates. These are the Ruby/Rails blogs and sites that I currently subscribe to:

You can download the file Ruby-Rails.opml to easily import all of the above feeds into your own reader.

Since I’m sure there are plenty of other “must have” Ruby feeds and blogs that are not currently on my radar (no word of a lie, I’ve already added more since I put the list together), I openly invite you to write a small entry in your blog as well, and show us what feeds you subscribe to. Please link back to this original post, or I won’t be able to easily find your answer. Consider it a sort of Ruby and Rails feed survey.

And since we’re on the topic, and the amount of feeds that I follow is dramatically reduced now, I’d like to extend an invite for you to do the same thing with Python/Django, Haskell, and Objective-C, assuming you are into any of these communities respectively. Those are the languages that interest me the most and I’d like to start following a good selection of feeds on these topics. If you don’t wish to blog about it, or use the comment section below, you can always write me privately at acangianoATgmail.com, specifying if you are okay with me crediting your list to you. I’d like to collect and organize the most interesting ones in a “results” type of post.

I thank you in advance, as I think it’s an interesting “experiment” that can be quite useful, especially for those who are just starting to learn any of the languages above.

No related posts.

DB2 on Mac

Antonio Cangiano — Wed, 19 Sep 2007 20:00:25 +0000

Python and DB2

We now have a working Python driver for DB2 which is currently undergoing internal testing. The driver is similar to the Ruby and PHP ones, which means that you get an advanced and very easy to use API. It also means that if you are confident with the Ruby driver, you will be able to use the Python one in no time.

Ruby:


require 'ibm_db'

conn = IBM_DB::connect(database, user, password)

if conn
  puts "Connection succeded."
  IBM_DB::close(conn)
else
  puts "Connection failed."
  puts IBM_DB::conn_errormsg
end

Python:


import ibm_db

conn = ibm_db.connect(database, user, password)

if conn:
    print "Connection succeeded."
    ibm_db.close(conn)
else:
    print "Connection failed."
    print ibm_db.conn_errormsg

We made it so that if you know one, you already know the other. These drivers are CLI wrappers that provide you with performance and stability. Also they don’t limit you to user data and are able to retrieve a good deal of metadata about your database. We’ll also provide a thin wrapper for those of you who intend to use a PEP 249 API. The next step, working on SQLAlchemy, has already started.

DB2 on Mac (no, really!)

When I first posted about our interest in Python/Django and DB2, the comment thread got hijacked by many people who asked for a Mac client in order to develop on Mac and deploy on Linux. Ask and you shall receive. I’ve promoted the idea of Django/SQLAlchemy/Python in IBM for a while now, and we are finally close to delivering the driver (with the adapter progressing at the same time too). Well, don’t take this as an official announcement, but Python wasn’t the only thing that I’ve been promoting for months within IBM. With the ever growing community of Ruby/Python hackers adopting Mac as their development platform of choice, I strongly believe that an investment in porting the great free version of DB2 to Mac is a very valid one.

I couldn’t talk about this for weeks, and it must be viewed as a rumor until IBM makes an official announcement, but we have been working on porting DB2 to Intel Mac. Not just the client, the whole package. This makes me a happy panda, no longer will a virtual machine be required to develop with DB2 on Rails on my Mac Book Pro. It’s a joy to see DB2 Express-C run on a Mac Pro (shown in picture) next to the other black boxes in the lab. Work is still in progress, but we should have a beta out there relatively soon (before winter kicks in). DB2 Express-C on Mac is intended for development purposes rather than production, this means that we expect you to develop on your shiny Mac but deploy on Linux or Windows. DB2 on Mac will be a beta product, but again it won’t just be a client runtime, it will be the full product and there is no reason why it shouldn’t be just as stable and efficient as the Linux and Windows versions.

Time to employee some of the newly acquired Cocoa-fu. I’m starting to feel that I could even learn Wasabi and IBM would still be able to let me use that skill in my day job. Awesome.

No related posts.

A preliminary review of three Cocoa and Objective-C related books

Antonio Cangiano — Wed, 22 Aug 2007 01:03:58 +0000

As announced before, I got interested in Mac development, bought a bunch of books and spent a few nights reading and coding. Here are my first impressions on those books which thus far I’ve picked up.

I only had time to read 3 chapters from Stephen Kochan’s book and I must say that I’m not impressed! The pace is extremely slow and experienced programmers who read it will be bored to tears. An example of this, is the fact that he spends 15 pages on teaching how to use if/else statements. I’m afraid it’s not working for me; by nature it’s far too basic, and slow paced books are irritating. I don’t blame the author, I’m just not the right target for such a book – and I find the title to be inappropriate, or rather, inaccurate. It should be renamed ‘Learn to Program with Objective-C’ or ‘Introduction to Objective-C’ not ‘Programming in Objective-C’. Readers who don’t know how to program in C or any other programming language, will find this book to be a very good explanation and thorough introduction to programming though. The book “Learn Objective-C on the Macintosh” is basic too, but it’s often recommended as an alternative to Kochan’s book. According to what I’ve seen from the sample chapter, this is still a very gentle introduction to the language, but it carries more insight and it’s not a boring read. Plus one of the authors is Mark Dalrymple who is very active in the online community as well.

Hillegass’ book is a whole different story. He is clearly a great teacher and, while I’ve read only half of this book so far, I can already conclude that this book rocks. Most of what I’m learning is coming straight from this book. Cocoa is not that easy but I feel that this tutorial sufficiently covers the subject matter at hand in-depth and gives a good deal of clarity to the fundamental concepts of this topic. I won’t be an expert by the time I’ve finished this book, no (this is never the case with any one book), though I will have a far better grasp of Cocoa. I’d say that at this time, it’s most likely the best book I could be reading on the subject. I highly recommend it to those of you out there who’d like to follow similar steps (if you buy only one book to get started with Cocoa, this is definitely the one I’d go for).

I read three chapters from Advanced Mac OS X Programmingso far, and I’m really glad I bought this book. If Cocoa Programming for Mac OS X (2nd Edition) is the the best tutorial to learn the basics and get started with, this advanced book appears to be what I’m really aiming for eventually and there is no doubt in my mind that it’s going to become my reference of choice along with the official Apple documentation. It covers difficult topics in detail and gives you insights that I’ve not found elsewhere on the Web. If I’m aiming to get serious about Mac development, I have to study this tome as best I can. I’m holding off on reading it for the moment, as I believe this book is the perfect continuation of the one I’m currently reading. From the chapters that I’ve read up until now, I’m wowed by this book. Mac OS X is a Unix OS, and this book covers that aspect by not leaving many details out. So far it looks like the perfect match up between theory (you will get a lot of college flashbacks when they talk about multi-threading and networking) and practice (the chapters on Memory management and Subversion are worth the price alone). Mark Dalrymple and Aaron Hillegass nail it again with a must-have book for serious developers.

Not bad, I bought three books and it turns out that two of them are great. I’m tempted to return the Objective-C one, but ultimately I don’t think that I’ll end up doing so.

I’ll suggest a fourth book, in case you are approaching Objective-C without any knowledge of C (but with at least some knowledge of other programming languages). I’m using it myself to brush up my C skills, which are certainly there, but in need of a quick refresher course.

Objective-C (aka ObjC) is a superset of ANSI C in fact. As such, any C program is also a valid Objective-C program. It provides you with a relatively easy and straightforward way of doing Object Oriented programming, while simplifying memory management. From what I’ve seen though, unless you are willing to become well versed in C, you won’t become an overly advanced Objective-C developer. Knowing C already (albeit I’m not a Guru), I must say that Objective-C is very easy and can be picked up in a matter of days. The real power and learning curve comes from the Cocoa framework itself, and that’s where I’m going to focus my efforts.

No related posts.

Cocoa is my Cup of Tea

Antonio Cangiano — Fri, 10 Aug 2007 22:10:29 +0000

Writing the article “Desktop Applications are not dead!” was an interesting experience that led to vivid discussions about the business of software for desktop applications, including the current limits and options available in this field. In the last comment by Eugueny Kontsevoy (the person I was responding to with my article in the first place), he expressed once again his frustration regarding Windows development:

“Seriously: I am an engineer for the sake of it: I love what I do and spending 20% of my time planning the deployment and dealing with failing Microsoft OS components is NOT something I want to do anymore. Period.” — Eugueny Kontsevoy

Before you dismiss his comment as an over exaggeration or peg him as having too picky an attitude, I would suggest thinking twice. The guy has a point, and if you’ve done Windows desktop application development before, you know this is often the case. My article proposed possible (partial) solutions for making Windows a more enjoyable and viable deployment platform for software startups. Of course, the easy way out is to leave the desktop market and move exclusively to the Web application arena. Hey, that’s what everyone else is doing, that’s the future, it’s buzz compliant, etc… But I want to take my own advice, and put my money where my mouth is.

Taking the red pill

I felt more at ease with my Mac after 5 weeks of using it, than I had with Windows after a dozen years. We feel like old friends, like Hemingway’s old man and the sea. I absolutely love Mac. I love its culture, the quest and appreciation for beauty. Quality over quantity, simplicity over complexity, beautiful design over crowded ugly interfaces. Mac is productive; Mac is zen-like, inspiring, and enlightening. Mac makes me happy to be a computer geek, and in my mind, Mac OS X is simply the best operating system available today.

I’m taking the red pill: I’ve decided to get serious about developing applications for Mac OS X. I can’t refrain from programming with this beauty.

Oh boy, where do I start?

I’m writing this as a quick guide for whoever decides to follow a similar path as mine. Consider that I’m just starting out, so I don’t know anything beyond what I’ve researched from reading other peoples’ opinions. I think it’s a sensible plan though. There is a wealth of good information on Apple’s site and many guides all over the web. Here is a list of resources that I am using or which I plan to use. They refer to Objective-C and Cocoa, which are respectively the favored language and framework for developing Mac applications.

First Step: Let’s get excited

Let’s get motivated with these slides from one of the most successful Mac developers out there and his associated podcast (whose genre is ‘religious’, according to iTunes, hahaha);
Beginning Mac Development: A good guide on how to get started by MacZealots.com;
Subscribe to CocoaRadio, an awesome podcast including interviews with the most popular and successful Mac developers around.

Second Step: Let’s read some documents

Get a quick, very basic intro to the C language. C is a subset of Objective-C, so it will make things easier if you already know the language or if you can at least understand the basics. This C Language Tutorial for Cocoa should get you started. (I’ll be skipping this step, and you can safely do so also if you know C, too).
The Objective-C Programming Language by Apple;
Cocoa Fundamentals Guide by Apple.

Third Step: Let’s get serious, with some books

I actually ordered the three books below yesterday night. The second one is already here, while the other two should arrive soon enough. All three of them have stellar reviews.

This should teach the language in depth and serve as a decent reference to have on hand.
This is, I believe, *the* crucial book. I plan to read this cover to cover and work through it.
This book should provide some advanced techniques.

Fourth Step: Join the discussion

Join the irc.freenode.net channels #macdev and #macsb, respectively about Mac development and the business side of Mac programming;
Subscribe to the Cocoa-Dev and the MacSB mailing lists.

Fifth Step: Keep Reading

Apple Developer Connection (ADC) has a huge amount of information about developing applications and guidelines for delivering high quality products. Bookmark http://developer.apple.com/ and come back to it often. I know I will.

What about Ruby and Python?

RubyCocoa is a nice bridge that allows you to develop in Ruby and Cocoa. Yes, I’m super interested in this project, but I want to learn first the traditional way of using Objective-C and only then consider when and if Ruby and Python can be beneficial for my Mac development needs.

And what about DB2?

Do I miss DB2 when I am on my Mac? Hell yes. DB2 Express-C is just plain awesome and it’s the only software that I really miss on my Mac. It runs fine in a virtual machine, but wouldn’t it be great to see it run natively in Mac OS X? Well, this won’t happen tomorrow, but I’ll tell you something… sooner or later, we’ll get there!

I already know that the biggest challenge is going to be finding the time to study all this stuff, and above all, finding time to code (the only way to really learn). But it’s going to be awesome. What are your thoughts about this strategy for learning Mac development? I especially welcome comments from experienced Mac developers and people who, like me, have decided to give Cocoa a serious go.

No related posts.