I think the article vastly overstates its case. Nobody disputes that it's possible to have more-or-less working memory management in ref-counted Objective-C. But it's clearly harder than in a GC language, else it wouldn't need seven pages worth of "simple rules" to explain.

Moreover, the author glosses over many of subtleties of reference-counting. For example, accessors in Java are dead-simple, practically boilerplate. But in Cocoa, what looks like a perfectly reasonable implementation to a newcomer is in fact buggy:

  - setFoo: (id)aFoo {
    [foo release];
    foo = [aFoo retain];
  }

Look closely, and you'll realize that if foo and aFoo are in fact the same object, it will be freed, and foo will have an invalid pointer assigned to it. Pretty much every Cocoa programmer knows about this, but we shouldn't ahve to.

One of the better Cocoa blogs is written by Mike Ash, and he has quite a few posts that illustrate some of these issues. For example, the first half of http://www.mikeash.com/pyblog/friday-qa-2010-12-03-accessors... talks about whether or not accessors should autorelease their return values, with pros and cons for each option. Later on, the money quote: "If you're using garbage collection, this whole question becomes vastly simpler."

Our author here says that "Cyclic object graphs in Objective-C are not a problem. At all." But another post by Mike Ash illustrates that it can be harder to deal with: http://www.mikeash.com/pyblog/friday-qa-2010-04-30-dealing-w... . A great example:

  _myInstanceVar = [[SomeClass alloc] initWithBlock: ^{
    [self doSomething];
  }];

Using 'self' within the block captures it in the closure as a reference, and then the closure itself is referred to by the instance variable of 'self'. This cycle is hard for the coder to notice, and will leak.