何年も前に、Mac ソフトウェアを書きたいと思っていて、Java WebObjects の経験が豊富だったので、Java ブリッジを試してみましたが、弾丸を噛んで Objective-C を学ぶことにしました (幸いなことに、自分のソフトウェアがブリッジで非推奨になるのは嫌だったので)。その後、RubyCocoa をいじりました。私は Ruby を学びました (実に興味深いものでした) が、ブリッジが成熟したり安定したりとはかけ離れているという困難な方法を発見し、最終的にコードを Objective-C に移植することをやめました。
何年も経ちましたが、MacRuby に時間を投資する価値があるかどうか、あるいは PyObjC を使用するために Python を学習する価値があるかどうか疑問に思っています。私は Objective-C が好きですが、Ruby ブリッジがクラッシュしなかったときの方がはるかに生産的だったことを思い出します。クラッシュするソフトウェアを再び作成するために時間を費やすのは嫌いです。
ブリッジの 1 つを試してみたい場合は、MacRuby が最適です。これは、Ruby に取り組んでいる Apple のシニア ソフトウェア エンジニアである Laurent Sansonetti によって開発されています。
現在は非常に機能的で、ネイティブ フレームワークとうまく統合されています。特に Ruby の経験がある場合は、一見の価値があります。
Cocoa プログラミングを学びたい場合は、ブリッジを無視してください。それらは Cocoa アプリケーションの作成をより困難にするだけであり、速度を上げるために多くの時間を無駄にすることになります。
具体的には、Objective-C を学習して、システム フレームワークの API と設計パターンの両方を理解できるようにする必要があります。さらに、すべてのドキュメントとツールは、Objective-C をサポートするために特別に作成されています。
Cocoa プログラミングの学習に費やす時間の大部分は、前述の API と設計パターンに費やされます。比較すると、実際の言語部分は比較的小さいです。
また、ある言語から別の言語にまったく同じではない機能をマッピングしようとすると、ブリッジは必然的にインピーダンスの不一致を招くことにも注意してください。
率直に言って、Ruby を知っていれば、Objective-C は自明のことです。オブジェクト モデルは非常に似ています。
これが時間の無駄ではない理由です。場合によっては、Ruby と Python には、Objective-C では利用できず、利用できない可能性が高い、よく開発された優れたライブラリがあります。これは、最良の使用例の 1 つです。
例: Rails を Objective-C で再実装したくない (そうする人もいます) が、MacRuby で Cocoa アプリを強化するために、その一部を簡単に使用できます。
さて、MacRubyは死んでいます。商用の RubyMotion があります。
PyObjc、RubyCocoa、mruby はまだあります。
他の興味深い使用例の 1 つは、AppleScript や OSA のように悪臭を放たないスクリプト機能を提供することです。
正当な理由があります。
私の個人的な意見は、ObjC for Mac ネイティブ アプリを使用することです。
疑わしいサポートを伴う信頼性の低いインターフェイスがなくても、ネイティブで適切に機能するはずの Ruby/Python を使用します。