いいえ、プロパティをサポートする計画があるかどうかはわかりませんが、GNUstep が実行可能であり続けることを計画している場合 (たとえ現在の限られた程度であっても)、これを優先する必要があります。GNUstep が Objective-C 2.0 の機能を採用することを決定しない限り、それと Apple の実装との間のギャップにより、適切なクロスプラットフォーム コードを書くことがますます難しくなります。(ほとんどの開発者にとって、それはすでに無意味な境界線です。)
私は通常、本質的に「それをしないでください、それは悪い考えです」という答えは嫌いですが、特に実用性の観点から、これについて@Jonathanに同意する必要があります. コードはクロスプラットフォームでコンパイルできますが、ユーザーがアプリを使用するためだけにランタイムをインストールする必要がある場合、誰かがアプリを使用する可能性は大幅に低下します。
This SO answerはそれをうまくまとめています。それを読んで、あなた自身の結論を引き出すことをお勧めします。
また、「objective-c」タグには 3280 を超える質問があり、「gnustep」タグには 9 があることも考慮する価値があります。質問の量が品質の指標であると言っているわけではありませんが、活動や関心と平行しており、非常に重要です。おそらく、このサイトには GNUstep の専門知識を持つ少数の人々がいます。したがって、検討している道を進むことを選択した場合、良い助けが得られる可能性は低くなります。
ところで、互換性という名目で新機能を避けるという考え方は、「最小公分母」の振る舞いであり、長い目で見れば、コードの洗練度や「機能性」を低下させます。これは、10.2 または 10.3 で利用可能な API のみを使用してコーディングするのと似ています。最近の OS X または iPhone の開発者は、過去の制限に妨げられずに、クールな新機能を利用したいと言うでしょう。最近では、ほとんどの場合、新しいアプリには 10.5 が必要です。古いバージョンのサポートは、下位互換性がある確立されたソフトウェアの特徴であり、多くのアプリは時間の経過とともに古い OS を削除することさえあります。
アプリケーションの販売を検討している場合、GNUstep 互換の API のみを使用すると、市場が大幅に制限され、実現できる洗練度や機能のレベルなど、基本的な方法でアプリが制限されることさえあります。アプリが商用化されない場合でも、一般的に、特定のプラットフォームに最適な言語とフレームワークを使用するメリットがあります。クロスプラットフォームのサポートを本当に探しているなら、Java の方が胸焼けが少なくてすむでしょう。(Java は間違いなく私のお気に入りの言語ではなく、Cocoa ではありませんが、多くのことをうまく実行します。) クライアントとプラットフォーム間で言語バージョンの問題は依然として同じですが、少なくともクロスプラットフォームであり、すべてのコンシューマー向けに設計されています。プラットフォームには、しっかりした Java サポートがあります。