回答:
クロスプラットフォームキットに対する傾向があるようです。一度書いてどこでも実行したい人は、HTMLを使用する傾向があります-Webサイトを作成します。人々は、たとえばiPhone上でネイティブのルックアンドフィールが非常に要求される場合にのみ、プラットフォームツールキットを使用しています。したがって、Web以外のアプリで悩んでいるのが、ネイティブのルックアンドフィールを取得することである場合、クロスプラットフォームキットを使用するのはあまり意味がありません。
クロスプラットフォームのツールキットがこれほどうまく機能したことはありません。デスクトッププラットフォームはそれほど類似しておらず、それらを完全に抽象化することは困難です。電話やタブレットをミックスに追加すると、さらに難しくなります。最終的に非常に漏れやすい抽象化になります（http://www.joelonsoftware.com/articles/LeakyAbstractions.htmlを参照）。多くの場合、「エンジン」とUIをうまく分離し、プラットフォームごとにUIを個別に記述する方が簡単です。
Macの人気が高まる傾向は、クロスプラットフォームキットの人気を高めるのではなく、むしろ低くするかもしれません。多くの場合、人々はクロスプラットフォームキットを使用して、すべてのプラットフォームで真に良い結果を得るよりも、クロスプラットフォームのチェックボックスを理論的にチェックすることが多かったと思います。実際に複数のプラットフォームを気にしたら...クロスプラットフォームキットの欠点を確認し始めます。
これらの欠点に関するアレックスペインのブログ記事は次のとおりです。http：//al3x.net/2011/01/15/user-hostile-platforms.html
大規模で人気のあるクロスプラットフォームアプリの多くは、独自のクロスプラットフォームアプローチを発明していると思います（Firefox、Chrome、Eclipse、OpenOffice.orgは頭に浮かぶ例です）。フレームワークを所有することで、必要に応じて抽象化を打ち破ることができます。また、これらのアプリはすべて、すべてのプラットフォームで同じように見える傾向があります（特にネイティブではありません）。
これはすべて言った、私は実際の統計情報などを持っていません。しかし、私はGTK +で多くの作業を行い、Firefox、Chrome、Eclipseなどのコードベースにある程度精通しています。そこで、ここで技術的な課題を直接目にしました。
実際のところ、近年、クロスプラットフォームUIツールキットに向かう傾向があります。そのツールキットはHTML / CSS / JavaScriptです。
一度開発すればすっごく簡単になり、どこでもほぼ同じように実行されます。
そして、はい、開発はデスクトップからウェブに大規模に移行しています。あなたは自分でそれを見る。
クロスプラットフォームツールキットを使用する傾向があるのは、クロスプラットフォームにしようとしているからではなく、デザインが優れているからです。たとえば、Windowsプラットフォームのみを対象としたC ++で書かれたプロジェクトに取り組んでいます。win32またはMFCを使用しますか。ネイティブツールキットで使用できるオプションはほとんどありますか？
神聖なfsckいいえ！それらは、私が今まで見たスパゲッティのゴミのほとんど最悪の山です！イベントシステムを基盤となるOSの「メッセージ」システムに直接結合することは、信じられないほど直感的ではなく、UIプログラムを迅速に作成するために必要な表現力に欠けています。現在、クロスプラットフォームツールキットでのみ提供されている高レベルの抽象化は、タスクに不可欠です。
それもほんの一例です。クロスプラットフォームツールキットの方が優れていることのリストにどんどん足を踏み入れることができました。事実は、グラフィカルインターフェイスは別個のものではなく、互いに類似しているということです。たとえば、WindowsのウィンドウプログラムとLinuxのウィンドウプログラムの違いはほとんどありません。UIプログラムを作成する際に行う種類は、ターゲットOSに関係なくほとんど常に同じです。電話/パームとデスクトップなどのアーキテクチャ間のわずかな違いのみです。この分野は、a）多くの人にとって必要であり、b）それはすべて同じだからです。
クロスプラットフォームのフレームワークを作成することに対する1つの議論は、それが常に最小公分母を対象とするということです-フレームワークのクライアントはコードを一度だけ書きたいだけで、「どこでも」サポートされます。そのため、プラットフォーム固有の機能を活用できないため、1つの素晴らしいハードウェアプラットフォームは、そのフレームワークを実行する他のプラットフォームのように見えます。
時間が経つにつれて、残念ながら、最も人気のあるプラットフォームに傾倒し、他のプラットフォームのサポートをハッキングしたり、予算/人気がなくなったときにそれらを切り捨てたりするフレームワークになります。
プラットフォーム固有の機能を活用する1つの方法は、#if PLATFORM_FEATURE_Xすべての特定のコードを構成するようなもの、またはコードが膨張する同等のランタイムチェックを使用することです。同じプラットフォームのバリアントでは特定の処理が必要になるため、これは非常に短時間で退屈になります。たとえば、一部のXBox v1にはハードドライブがないため、クロスプラットフォームツールを使用するゲームでは、ハードドライブを保証できるPCバージョンと比較して、キャッシュに使用できません。
デスクトップ/生産性アプリケーションでは、プラットフォームのルックアンドフィールが重要と思われますが、多くのアプリケーションには独自のスタイルがあるため、AIRでビルドされたアプリなど、すべてのプラットフォームで同じように見えることは問題ありません。
Apple、Sony、Nintendo、Toshibaなどのハードウェアベンダーは、自社製品が競合製品と差別化するために、タッチ、加速度計/暗視野鏡、Blu-Ray、3Dディスプレイなどの機能を確実に実行したいと考えています。すべての競合他社のすべての機能が1つに統合されたプラットフォーム（コストと複雑さのため）が存在する可能性は低いため、1つが勝ちます。