私は、将来のmISV用のソフトウェアを作成する初期段階にあります。このプログラムはデスクトップアプリケーションであり、長期的にはWindowsとOS Xの両方のネイティブバージョンが必要です（さまざまなクロスプラットフォームAPIを調べましたが、どれも私のニーズを満たしていません）。ただし、最初は、2つのプラットフォーム用に同時に開発することは意味がないと思います。そのことを念頭に置いて、私はWindows用のWPFとOS X用のCocoaを見てきましたが、それらは似ているようです。
誰かが一方を他方に移植した経験がありますか？移植を容易にするために従うべき特定の技術/パラダイムはありますか？ビジネス上の考慮事項を無視して、最初にそれらの1つで開発することをお勧めしますか？
上手。Cocoa用のアプリを作成したら、それをWindowsに移植することができます。これは、gnustepまたはCocotronを使用して実行できます。
逆の場合、WINEは移植を容易にすることを目的としています。
私はむしろOSXバージョンを最初に書きたいです。これは、Windowsユーザーがアプリケーションの外観を明確に把握していないためです。私の経験では、彼らはあらゆる種類のユーザーインターフェイスを介してかなり苦しむことができます。一貫性は彼らにとってほとんど価値がありません。Windowsアプリがどのように見えるべきかという共通の合意がないため、Windowsユーザーが実際にOSXデザインを好むことを妨げるものはなく、頻繁にそうすることさえあります。iTunes for Windowsは非常に典型的なOSXアプリのように見え、Windowsっぽいものでは不十分だという苦情はほとんどありません。
反対の方向に進むと、これは真実ではありません。OSXユーザーは、Cocoaアプリを明確に好み、たとえば、GIMPやInkscapeのように、OSXでも他の場所でも機能しますが、OSXの訓練を受けた目には明らかに醜いものにほとんど寛容ではありません。
各プラットフォームに固有のウィンドウ環境を選択することで、正しい道を進んでいると思います。このアプローチにより、クロスプラットフォーム ウィンドウ ツールキットに固有の妥協によって制限されない、各プラットフォームでのユーザー エクスペリエンスを作成できます。
適切な最初のステップは、設計を 2 つの部分 (プラットフォーム固有の要素とプラットフォームに依存しない要素) に分割することです。既に任意の UI コードをプラットフォーム固有の列に入れることができますが、プラットフォームに依存しない C++ で記述できるデータの永続性がアプリに必要になる場合があります。このアプローチでわかることは、UI とグルー コードだけをプラットフォーム固有のままにして、プラットフォームに中立な方法で記述できるかなりの数のロジックとインフラストラクチャがあることです。
最近、 Late Night CocoaのエピソードとしてPorting Large Applications to the Mac platformというタイトルがありました。あなたのアプリは「大規模」とは言えないかもしれませんが、このポッドキャストは、移植を数回行ったことのある人から、かなりの優れた移植知識を提供します。
まあ、簡単な道はありません。最良の方法は、Model-View-Controllerパターンやその他のアーキテクチャを使用して、ビジネスロジックなどをプレゼンテーションから分離することです。ただし、Monoを使用していない限り、共有できるコードはほとんどないと思います。WPFを開発している場合は、必ず.NETを実行し、Monoを除いて、Objective-CはMacOSの標準プログラミングツールです。バツ。
優れた設計を維持すれば、移行パスを見つけようとするのではなく、ほとんどのコードを.NETコードのObjective-Cバージョンにすることができます。その逆も可能です。