モバイル開発-ネイティブVSクロスプラットフォームVSJavaScript
最高品質/費用効果の高いソリューションを実現するために利用可能なさまざまなツールの長所と短所を調査するようCTOに依頼されたため、当社はまもなくモバイルプラットフォーム向けの製品の開発を開始します。
主にiOSとAndroid、Windows-MobileとBlackBerryのセカンダリ）を目指します。
候補者：
いくつかの背景調査を行った後、私は次の候補を見つけました。
ネイティブ-ネイティブのツールと言語を使用して、プラットフォームごとに単純ですが手間をかけて開発します。
HTML5、CSS、JavaScript-デバイスのブラウザ（Webサイト）で実行されているWebサービス、またはWebKitの周りにそのようなコードをカプセル化するアプリである可能性があります。
Rho mobile-グーグル製なので良いはずです-それでもRuby（私たちは慣れていません）に基づいており、複雑でかなり薄っぺらな開発者がいます環境。
PhoneGap-簡単に見え、ほとんどがJavascriptに基づいています-オープンソースですが、最近Adobeに買収されました良い兆候ではありません）
---（Appcelerator-JavascriptからPHPそしてpythonまで、さまざまなAPIアクセスがありますが、（Appleによる）拒否の話や、使用時の非互換性について多くの話を聞きました。異なるプラットフォーム間での複雑なコード。
そして、MoSync、Sencha、Appmobi、Coronaのように（直接テストしていません）。
いくつかの参照点：
私たちはゲームの開発を計画していません。私たちが開発を計画しているアプリケーションは、ビジネスアプリケーションと情報ツールの領域にあります。
アプリケーションは、デバイスAPIの過度の使用に依存していません（ただし、いくつかのマイナーな基本アクセスが必要です）
同社はすでにiOS向けに開発しており、ネイティブiOS開発者の小さなチーム（Objective-Cオタク）がいます
新しいOSやAPIによってアプリケーションが壊れることなく、この機能でアプリケーションの開発を継続できるようにしたいと考えています。
クロスプラットフォームコード（主にAppStore）が原因でアプリケーションが拒否されないように事前に確認しておくと便利です。
他の企業と同様に、できる限り費用対効果を高めたいと考えています。一方、高品質の製品と最高のユーザーエクスペリエンスを求めています。
StackOverflowよりもこの質問をするのに最適な場所はありません。このトピックに関する経験を持つ開発者からのコメントをいただければ幸いです。
アプリ市場には50万以上のアプリがあり、競争は熾烈です。優れたUXとグラフィックスを持つことが最も重要です。
クロスプラットフォームツールは、ネイティブ開発と同等ではありません。もしそうなら、私たちは皆それらを使用しているでしょう。しかし、そうではありません。理由があります-あなたは完全なコントロールを持っていません。また、見栄えの良いアプリを作成するには、フルコントロールが必要です。
アプリがコンシューマーアプリではなく、内部部門によって使用が指示されているエンタープライズアプリの場合、そのようなアプリの価値はそこにあるため、可能性がありますまあまあの設計でうまくいきます機能。
しかし、モバイルアプリ市場に真剣に取り組んでいる場合、唯一の方法はネイティブになることです。そして、チームにはUXの人とデザイナー（モバイル開発を知っている）がフルタイムで必要です。時間の50％以上をルックスに費やします。私が現在参加しているプロジェクトは、80％以上の時間をルック（グラフィック、アニメーション、UX、ユーザビリティテスト）に費やしています。
提案：競合他社のアプリを使用して、妥当な時間（=日）を費やしてください。また、各市場の上位50のアプリで時間を過ごします。バーの高さを実感できます。次に、クロスプラットフォームツールで作成されたアプリを確認し（サイトにリンクがあります）、比較します。
@Peter Knegoと完全に合意していますが、いくつかのプラットフォームをサポートしようとしているチームのために、いくつかのマイナーなポイントを追加します。
Peterが指摘するように、UXは巨大であり、クロスプラットフォームUXは最小公分母のUXです。後ろで手を縛らずに、このようなものを必要なものすべてにするのは十分に難しいことです。本当に素晴らしいWebアプリは、ネイティブエクスペリエンスに近づく能力で判断されますが、その逆ではありません。
製品にはUXではない部分がたくさんあります。そこに到達できる再利用の種類を慎重に検討する価値があります。たとえば、SQLデータベースをすでに使用しているチームにAndroid iPhoneでCoreDataを使用しないようにアドバイスすることがよくあります。オブジェクトとデータモデルを再発明する理由はありません。
これは、コアをC++で作成するという包括的な提案ではありません。あなたが大規模な既存のC++コアを持っているなら、私はそれを再利用する方法について 以前に提案をしました しました。しかし、私は一般的に新しいコードにはお勧めしません。ほとんどの場合、プラットフォームの最高のOSレベルの機能を使用することをお勧めします。
すべてのプラットフォームで適切に機能するネットワークプロトコルの設計は非常に簡単であり、追求する必要があります。ここでの最善の策は、ほとんどすべての場合RESTとJSONです。特に、SOAPと複雑なXMLの解析を嫌うiPhoneの場合は、シンプルにしてください。
いくつかの複雑なレイアウトの問題は、ネイティブコントロールよりもHTML + CSSの方が簡単です。これは、複雑な複数列のテーブルがある場合に特に当てはまります（特に、
colspanとrowspanが必要なもの）。移植性がまったく考慮されていない場合でも、他のネイティブアプリに個々のUIWebView個を埋め込むことはかなり幸運でした。ここで再利用する価値のあるものがいくつかあります。 HTMLブラウザをニュートラルにするために多くの労力とパフォーマンスを無駄にしたくないことを覚えておいてください。 iPhoneでは、WebKit拡張機能を使用して、アプリをユーザーにとってより良いものにします。
ただし、これで最も重要な教訓の1つは、すべてのプラットフォームに適したアプリを作成するための単一の「正しい」方法がないということです。 iPhoneアプリはiPhoneアプリのように動作する必要があります。 AndroidアプリはAndroidアプリのように動作する必要があります。
高度にクロスプラットフォームのアプローチは、「何か」が何であるかを本当に気にしない場合に「何か」を取得するための安価な方法です。それらは何か素晴らしいものを手に入れるための非常に高価な方法です。
私はAppMobiで働いており、いくつかコメントします。
あなたのアプリは、ネイティブWebビューを使用したクロスプラットフォームであるとして拒否されるべきではありません。 Apple AppMobiが提出したアプリでそれを使用したことはありません。
Rhombileは「Madebygoogle」ではありません。実際、グーグルが購入したのはモトローラの一部ではなく、彼らの事業部門です。彼らはHTML5/Javascriptに向かって進んでいますが、現在はRubyです。
Appceleratorは、Webビューのサポートを開始し、その後バックトラックしました。彼らはウェブビューのサポートに戻るためにたくさんのお金を集めました。
クロスプラットフォームアプリに「いいえ」と言う人について。 Facebookやその他の大手企業は、モバイル向けのHTML5ベースのアプリに移行しています。