Should I Learn MACruby or Rubycocoa

PyObjc vs RubyCocoa for Mac development: Which is more mature?

I would echo Chris' assesment and will expand a bit on why you should learn Objective-C to learn Cocoa. As Chris says, Objective-C is the foundation and native language of Cocoa and many of its paradigms are inextricably linked with that lineage. In particular, selectors and dynamic message resolution and ability to modify classes at run time are required to implement Cocoa technologies such as Distributed Objects and bindings. Although these features are available in other dynamic languages such as Ruby and Python, there is enough of a mismatch in the language models that you will have to at least understand Objective-C to understand Cocoa. I suggest you take a look at this previous question for further discussion: Do I have to learn Objective-C for professional Mac Development?

Fortunately, Objective-C is very easy to learn. I often tell people it will take them a day to learn Objective-C coming from C/C++/Java or LISP, Scheme, or any of the 'newer' dynamic languages such as Ruby and Python. In addition to expanding your mind a bit, you'll learn to at least read the code that is used in virtually all of the Cocoa documentation and examples.

As for Ruby vs. Python, the bridge capabilities are very similar. In fact, they both use Apple's BridgeSupport (shipped with Leopard) to provide the bridge description. Both are supported by Apple and ship with Leopard. It's a matter of personal taste which language you prefer. If you choose Ruby, I suggest you give MacRuby a look. It's definitely the future of Ruby on OS X, as it reimplements the Ruby runtime on top of the Objective-C run time. This provides some nice performance and conceptual advantages (including integration with the Objective-C garbage collection system, a feature currently lacking in PyObjC which uses the native python gc). MacRuby also includes a custom parser that makes the syntax of bridged objective-c methods a little nicer. The downside of MacRuby is that it's not quite ready for production-level use at the time of this writing (June 2009). Since it sounds like this is a learning project for you, that's probably not an issue.

Mac development - Start with MacRuby or Objective-C?

Learn Objective-C first. I was in your position and I tried to do MacRuby and didn't get much of anywhere. Now that I've done some Objective-C development, MacRuby is easy, and it's a nice relief to get back to ruby syntax.

Good resources to learn MacRuby

I found MacRuby: The Definitive Guide, by Matt Aimonetti
very helpful for getting started with MacRuby.

For what programs are Objective C and Ruby ideal on the Mac?

If I were to write a big application, I would stick to Objective-C only. It’s not hard, it’s the most supported option and for the foreseeable it will stay that way. As for Ruby, there used to be Java support in Cocoa that does not exist anymore. I’d hate to have a large legacy application written in mixture of Java and Objective-C and having the prospect of rewriting the Java parts or sticking with older OS.

(The previous paragraph applies to writing pure desktop applications. If you wanted and could write a part of the application say as a local webservice it would be quite different, as the Ruby support there would be much more dependable. Depends on your people, experience, goals and other variables.)

Dependency Injection and DDD are both abstract ideas, so yes, you can certainly do that in Cocoa. I have no idea about how many Mac devs do it. As for DI, there is strong support for loose coupling in Cocoa and the whole technology stack (see Interface Builder, KVO/KVC or bindings).

Hope that helps.

Cocoa/MacRuby: How to write a toolbar which accepts custom items?

There is an excellent tutorial here: http://www.mere-mortal-software.com/blog/details.php?d=2007-03-14

It is targeted at preferences windows, but of course you could use the window class anywhere.

I have not bothered to port the window superclass to Macruby, I just use it as is. Then I use macruby to write the subclass, for example:

class MopenPrefsWindowController < DBPrefsWindowController
  attr_accessor :generalPrefsView
  attr_accessor :openingPrefsView
  attr_accessor :advancedPrefsView
  attr_accessor :appearancePrefsView  

  def setupToolbar
    self.addView(generalPrefsView, label:"General", image:NSImage.imageNamed(NSImageNamePreferencesGeneral))
    self.addView(openingPrefsView, label:"Opening")
    self.addView(advancedPrefsView, label:"Advanced", image:NSImage.imageNamed(NSImageNameAdvanced))
    self.addView(appearancePrefsView, label:"Appearance")
  end
end

The one thing that might cause me to some day port the window class to macruby is to give it the ability to have a bottom section that appears on all panes.

Can you develop native iPhone apps in Ruby?

No, you are correct. Currently, and most likely for the foreseeable future, Ruby will not be an option, at least for AppStore applications. There's no reason you couldn't do this on a Jailbroken phone, but Apple is pretty wed to Objective C for official development.

MacRuby Pointer to typedef struct

If you were writing C you would have written

SecKeychainRef keyChainRef;
SecKeychainOpen("/path/to/...", &keychainRef);
SecKeychainLock(keyChainRef);

i.e. while SecKeychainOpen requires a pointer to a SecKeychainRef (so that the output parameter can be filled in), other apis just require a SecKeychainRef, so you need to dereference the pointer:

framework 'Security'
keychainObject = Pointer.new_with_type('^{OpaqueSecKeychainRef}')
SecKeychainOpen("/Users/charbon/Library/Keychains/Josja.keychain",keychainObject)
SecKeychainLock(keychainObject.value)

MacRuby vs MacPorts

I agree with Douglas F Shearer suggestion of RVM. I use it daily on OSX I recommend it very highly.

https://rvm.io

Importantly, it will also allow you to install different flavors of 1.9 in parallel. So you can ave the MRI implementation and the jruby implementation, and switch between them if you so desire.

Unrelated: check out homebrew for OSX. Link I like it alot better than MacPorts.