一度書けばどこにでも展開：いつネイティブに移行するか？

Write Once、Deploy Everywhere（WODE）は、過去10年間、多くの開発フレームワークの約束であり、その目標は、複数のネイティブアプリケーションを作成する手間を軽減することです。 どのパスを取るかを決定することは、プロジェクトマネージャーが立ち上げコストが高く、開発チームに影響を与え、元に戻すことができない可能性があるため、プロジェクトマネージャーが下さなければならない最も重要な決定の1つです。

Ionicなどのハイブリッドソリューションは、Webテクノロジーを活用してプラットフォーム間でアプリケーションをレンダリングしますが、多くの場合、最終製品は、ネイティブのルックアンドフィールに対するユーザーの期待を下回ります。

ただし、最近、「ネイティブ」という用語でさえ、ネイティブコードにコンパイルされるフレームワーク（React Native、Xamarinなど）によって混乱しています。

この記事では、さまざまなモバイル開発パスの長所と短所を分析し、製品マネージャーがより多くの情報に基づいて決定できるようにするために、チームの構成、コスト、およびユーザーエクスペリエンスと比較検討します。

一度書けばどこにでも展開

Write Once、Deploy Everywhereの概念は、アプリケーションがデプロイされるプラットフォームの抽象である単一の開発スタックを使用して、アプリケーションを1回だけ作成し、それでもデプロイする機能を維持する開発チームの能力を指します。 Android、iOS、Windowsなど、必要なすべてのプラットフォームへのアプリケーション。理想的には、これは、保守性、パフォーマンス、またはユーザーエクスペリエンス（UX）を犠牲にすることなく実現されます。

モバイルアプリケーション開発の代替の（そして歴史的な）方法は、プラットフォームごとに個別のアプリケーションを作成するという単純なプロセスを含みます。もちろん、それはそれ自体の潜在的な高い時間とリソースのコストを伴います。

一般に、開発パスを選択する際に考慮すべき要素は次のとおりです。

• プロジェクトの年齢
• 開発チームの構成と規模
• 配布に必要なプラットフォーム
• 市場投入に必要なタイムライン
• 必要に応じて別のパスに変更するために使用可能な帯域幅

残念ながら、これらの要素のそれぞれを利用可能なパスのそれぞれに適用すること、および主題に関する無数の利用可能な意見をくぐり抜けることは、非常に困難な場合があります。 さらに、このプロセスでは、多くの場合、アプリケーションの要件を満たすためにどのパスが最適であるかについて、プロジェクトマネージャーに不確実性を感じさせます。

大まかに言えば、さまざまなモバイル開発パスは、ネイティブまたはWODE、つまりネイティブまたはその他すべての2つのカテゴリに分類できます。 簡単に言えば、ネイティブアプリケーションを作成するか、作成しないかのどちらかです。 WODEカテゴリは、さらに2つのグループに分類されます。

• ハイブリッドフレームワーク-Webテクノロジーを活用して複数のプラットフォーム間でアプリケーションをレンダリングするフレームワーク。
• 非ハイブリッドフレームワーク-ハイブリッドフレームワークのようにアプリケーション内でWebビューをレンダリングする代わりに、ネイティブUIコンポーネント（ボタン、テキストフィールド、さらにはレイアウトマネージャーなど）を使用するフレームワーク。

WODEフレームワークの大部分はハイブリッドです; ただし、WODEフレームワークの利点を提供しながら、ハイブリッドフレームワークのパフォーマンスとUXの両方の制限を改善するために、現在の傾向は非ハイブリッドに向かっています。 この傾向により、React Native、Xamarin、Appceleratorなどのフレームワークが人気を集めています。

これらのパス（ネイティブ、ハイブリッド、および非ハイブリッド）にはそれぞれ長所と短所があり、その結果、それぞれに最適なユースケースが異なります。 この記事の残りの部分では、チーム構成、プロジェクトコスト、UXなどの競合する優先順位を検討する際に、各モバイル開発パスの長所と短所を説明します。 いくつかの特殊なユースケースを除いて、ネイティブアプリケーションを作成すると、わずかに高いコストでユーザーエクスペリエンスが最大化されます。

一般的に、「あなたはあなたが支払うものを手に入れる」という格言が適用されるので、コストが顧客の経験よりも重要である場合、ネイティブは正しい選択ではないかもしれません。 ただし、UXが不可欠になると、ネイティブアプリケーションが明確な選択になります。これは、UXを改善するために、WODEベースのアプリケーションが時間またはネイティブの専門知識の形でかなりのコストを負担し、非ネイティブを選択する目的を無効にするためです。そもそも開発パス。

さらに、そのコストが支払われたとしても、WODEベースの最終製品は、ネイティブの製品と比較した場合、常に劣ったUXを提供します。 その結果、ほとんどの場合、ネイティブはほとんどの開発チームおよびほとんどのプロジェクトにとって正しい選択です。

ネイティブアプリケーション

ネイティブアプリケーションは、特定のプラットフォームのコア言語で記述されています。 たとえば、AndroidアプリケーションはJavaで記述されていますが、iOSアプリケーションはObj-CまたはSwiftで記述されています。 開発エンジニアは、言語と、サードパーティのパッケージ統合、レイアウト管理、オペレーティングシステム（OS）の相互作用など、プラットフォーム固有のニュアンスを理解する必要があります。

長所

高度にカスタマイズ可能。 各アプリケーションはネイティブコンポーネントを使用して作成されているため、カスタマイズの唯一の制限は、基盤となるフレームワークへのインターフェイスであり、その場合もありません。 ほとんどのネイティブ開発エンジニアが証明するように、インターフェイスが制限されているにもかかわらず、特定のタスクを実行する方法がよくあります。

このアイデアの簡単な証拠は、特定のプラットフォームのサポートコミュニティを閲覧することで見つけることができます。 基盤となるフレームワークの制限にもかかわらず、「予約から外れている」可能性のあるタスクを実行する方法の例が多数見つかります。

このような一見単​​純なタスクの具体的なiOSの例は、タブバーやナビゲーションバーなどのすべての外部UI要素の上にフルスクリーンオーバーレイを表示することです。図1に示すように、これは通常、現在表示されている通常のUIレイヤー。 そのため、フルスクリーンオーバーレイを作成するには、ビュースタックのタブバーの上にある非表示のレイヤーに追加する必要があります。 この種のカスタマイズは通常、ネイティブアプリケーションでのみ可能です。

最高のパフォーマンス。 予想どおり、ネイティブアプリケーションはパフォーマンスのベンチマークを設定します。 他のほとんどのフレームワークタイプは1つ以上の中間層を追加するため、ネイティブアプリケーションよりも本質的に実行速度が遅くなります。

最もメンテナンスしやすい。 オペレーティングシステムは絶えず変化します。 限目。 その場合、重大な変更が行われたかどうかに応じて、新しいOSにアップグレードするユーザーベースの一部を失わないように、アプリケーションをタイムリーに更新する必要があります。 明らかに、ユーザーが変更を利用できるようになってからアプリケーションが更新されるまでにかかる時間は短いほどよいでしょう。 この新しいOSをサポートするために更新する必要のある依存関係がない場合、この時間は最小限に抑えられます。これは、ネイティブアプリケーションで作業する場合に当てはまります。

短所

追加のリソース。 複数のプラットフォーム用のアプリケーションを作成する場合、開発チームは通常、サポートされているプラ​​ットフォームごとに1人以上のモバイルソフトウェアエンジニアで構成されます。 もちろん、これは本質的に開発チームの規模とコストを増加させます。 また、同種のスキルベースではなく、エンジニアのチームがさまざまなスキルを持っている必要があります。 これは、サポートとコラボレーションに関してチームを断片化する可能性があります。

開発サイクルが遅い。 ネイティブアプリは、必要なプラットフォームごとに個別のアプリケーションを作成する必要があるため、開発サイクルが遅くなる可能性があります。 極端なケースは、各アプリケーションが基本的に直列に記述されているため、チームに1人のモバイル開発エンジニアがいる場合です。

パフォーマンスが低い。 賛否両論としてのパフォーマンスを持つのは奇妙に思えるかもしれません。 一方では、ネイティブアプリケーションは、開発者に、きめ細かく調整された高性能アプリケーションを作成するための十分な余地を与えます。 しかし一方で、それらは開発者に自分自身を吊るすのに十分なロープを与えます。 彼らが何をしているのかわからない場合、結局、彼らはせいぜい標準以下のアプリケーションになってしまうでしょう。

注：一般に、これはすべてのフレームワークパス（ネイティブ、ハイブリッド、および非ハイブリッド）に適用されます。 アプリケーションを開発するエンジニアが自分たちが試みていることに対して不十分なスキルを持っている場合、結果として得られるアプリケーションは、設計要件を満たしていないか、ユーザーに十分に受け入れられていない可能性があります。

ハイブリッドアプリケーション

ハイブリッドアプリケーションは通常、HTML / CSS / LESSを使用して作成され、ユーザーインターフェイス（MVCデザインパターンの「V」）を設計します。 「C」またはコントローラーは、通常、JavaScriptで記述されます。理想的には、AngularJSなどのJavaScriptMVCフレームワークを使用します。 AngularJSのようなフレームワークを使用すると、jQueryのみを使用して通常可能であるよりも、クラスと責任をより適切に分離できます。

このタイプのハイブリッドフレームワークスタックの例は、AngularJSに裏打ちされたIonicビューレイヤーであり、これは最終的に、PhoneGapとCordovaを使用して目的のプラットフォーム上のWebビューに変換およびレンダリングされます。 明らかに、このタイプのWODEフレームワークには、複雑さが増すという犠牲が伴います。

さらに、JavaScriptを使用すると、独自の設計ベースの制限と言語ベースの問題が発生します。 この記事の目的は、1つの言語の長所や短所について議論することではありません。 ただし、プロジェクトマネージャーとして、モバイルテクニカルスタックでJavaScriptを使用するという選択は軽視すべきではありません。 以下は、JavaScriptを可能な限り避けるべき理由に関するよく書かれた記事のほんの一例です。

• JavaScriptの問題
  
• 私がReactNative開発者ではない理由

長所

最小限の開発チーム。 ハイブリッドフレームワークを使用すると、小規模な開発チーム、特にWeb開発を主な知識ベースとするチームが、複数のプラットフォームにまたがる単純なアプリケーションを迅速に作成できます。 これにより、プロジェクトマネージャーはチームを小さく保つことができ、チームが複数のプラットフォームのネイティブ言語とフレームワークを学習する必要がなくなります。

より速い開発サイクル。 小規模なチームに加えて、ハイブリッドフレームワークは、Webテクノロジを使用して単一のビューレイヤーを設計するだけでよいため、複数のプラットフォームに展開する場合の開発サイクルを短縮できます。

短所

潜在的に貧弱なUX 。 単一のビューレイヤーを作成するだけでよいという欠点は、単一のビューレイヤーが残ることです。 UIデザインへの万能のアプローチでは、すべてのプラットフォームのユーザーにとって快適で親しみやすいルックアンドフィールをアプリケーションに提供できないため、これによりUXが低下する可能性があります。 さらに、ハイブリッドアプリケーションは基本的にUIに埋め込まれたWebビューであるため、ネイティブアプリケーションを操作するのではなく、実際にWebページを表示しているような印象をユーザーに与えることができます。 このエクスペリエンスは、ほとんどの場合、ユーザーの満足度、そして最終的には定着率に悪影響を及ぼします。

カスタマイズするにはコストがかかります。 プラットフォームごとにカスタマイズされたUIを設計することでUXを改善すると、複雑でユニークなUIフレームワークが作成され、作成にコストがかかり、長期にわたって維持するのが困難になる可能性があります。 さらに、アプリケーションを目立たせるのに役立つUI要素（アニメーション、カスタムビューなど）を作成するには、カスタマイズされたブリッジコンポーネントを作成して、高レベルのUIデザインを低レベルのフレームワークに変換する必要があります。 、Cordovaなどが理解します。 一般に、ハイブリッドアプリケーションのUXをカスタマイズして改善すればするほど、高速で安価な設計サイクルのメリットが減少します。

パフォーマンスが低下します。 ハイブリッドアプリケーションはWebビュー内でアプリケーションのビューをレンダリングするため、OSフレームワーク（ネットワーク、Bluetooth、デバイス上の連絡先など）を処理するときに実装ミスを犯す可能性が高く、パフォーマンスが大幅に低下します。 また、すべてがWebビューを介して表示されるため、パフォーマンスに細心の注意を払っても、ハイブリッドアプリケーションの最大パフォーマンスは常にネイティブアプリケーションよりもわずかに低くなることにも注意してください。

重要なプラグイン管理。 設計チームが数週間かけて磨きをかけたカスタム機能を覚えていますか？その後、開発チームが必要なブリッジコンポーネントを作成して、Cordovaがそれらを操作できるようにしました。 チームが達成しようとしていることをサポートするCordovaプラグインがない限り、それらは機能しません。 これは、2つのことのいずれかを意味します。チームがそれを自分で作成するか、その仕事を行う適切なサードパーティのプラグインを見つける必要があります。 残念ながら、多くの場合、オプション2は存在しません。 その結果、カスタムプラグインを作成するために追加の開発時間が必要になり、その後、アプリケーションに必要なCordovaプラグインの増大するライブラリを管理するためのビルドサポート作業が（時間の経過とともに）必要になります。 もちろん、Cordovaの更新が発生した場合、これらのプラグインも更新する必要がある可能性が高くなります。

OSサポートラグ。 前述のカスケードブリッジコンポーネント/Cordovaプラグインの問題は、OSがコア機能を変更するとさらに悪化します。 変更をサポートするためにCordova、PhoneGap、およびIonicが更新されたら、カスタムプラグインとブリッジコンポーネントも更新する必要がある可能性があります。 この作業に必要な規模に関係なく、新しいOSに更新したエンドユーザーをアプリケーションがサポートしない時間が長くなります。 もちろん、これは最悪のシナリオであり、下位互換性のない重大な変更がAppleまたはGoogleによって行われていますが、これは決して起こりません…そうですか？ 一般に、開発者の制御が及ばず、最初に更新する必要がある中間フレームワークは、プロセスを遅らせるだけです。 最後に、中間フレームワークに依存することは、これらのフレームワークのタイミングが非常に不明であるため、プロジェクトマネージャーが計画を立てるのに頭痛の種になる可能性があります。

非ハイブリッドアプリケーション

非ハイブリッドアプリケーションは、ハイブリッドアプリケーションと同じように始まります-非ネイティブプラットフォーム言語で設計されたUIレイヤー：React Nativeは、JavaScriptまたはXamarinに基づくHTML / CSSを使用します。これは、.NETルートのためにC＃に基づいています。

ただし、ここで類似性が終了します。 非ハイブリッドアプリケーションは、ネイティブコードにコンパイルされ、Webビューを介してレンダリングする代わりに、プラットフォームネイティブコンポーネントを使用してアプリケーションをレンダリングします。 これにより、少なくとも表面的には、両方の長所を備えたWODEフレームワークが実現します。

前に説明したように、JavaScriptを使用することを選択することは、軽率な決定ではありません。JavaScriptの使用について学びたくない、または関心がない開発チームにとっては、これは大きな問題になる可能性があります。

長所

ハイブリッドよりも高いパフォーマンス。 ご想像のとおり、非ハイブリッドは、埋め込みWebビューに依存する代わりに、ネイティブUIコンポーネント（ボタン、ビュー、レイアウトマネージャーなど）を使用してアプリケーションをレンダリングできるため、本質的にハイブリッドアプリケーションよりも高いパフォーマンスを発揮します。 もちろん、開発者は、驚くほどまたはひどく実行するアプリケーションを自由に作成できます。 非ハイブリッドアプリケーションの利点は、同様のハイブリッドアプリケーションと比較した場合にパフォーマンスベースラインが高くなることです。

最小限の開発チーム。 ハイブリッドフレームワークと同様に、非ハイブリッドを使用すると、小規模な開発チーム、特にWeb開発を主な知識ベースとするチームが複数のプラットフォームにまたがる単純なアプリケーションを迅速に作成できます。 これにより、プロジェクトマネージャーはチームを小さく保ち、チームが複数のプラットフォームのネイティブ言語とフレームワークを学習するのを防ぐことができます。

より速い開発サイクル。 小規模なチームに加えて、非ハイブリッドフレームワークは、単一のビューレイヤーのみを設計する必要があるため、複数のプラットフォームに展開する場合の開発サイクルを短縮します。

より高速な反復（React） 。 Reactフレームワークは、アプリケーションへの変更をリアルタイムでレンダリングできる強力な機能を提供します。再コンパイルや再構築などの必要はありません。その結果、Reactエミュレーターは、各実装の期間を劇的に短縮する非常に強力な開発ツールです。サイクル。

短所

カスタマイズするにはコストがかかります。 ハイブリッドアプリケーションと同様に、非ハイブリッドアプリケーションでプラットフォームごとにカスタマイズされたUIを設計してUXを改善する必要がある場合、複雑でユニークなUIコンポーネントが作成され、作成にコストがかかり、長期にわたって維持することが困難になります。 これは、フレームワークのネイティブ要素サポートのギャップを補うためにカスタマイズされたブリッジコンポーネントを作成することも意味します。 ハイブリッドと同様に、このコストは高速で安価な設計サイクルのメリットを減らしますが、ハイブリッドアプリケーションとは異なり、ブリッジコンポーネントは、必要なプラットフォームごとに母国語で記述されます。 つまり、非ハイブリッドアプリケーションが、主にWeb開発者で構成されるチームの柔軟な代替手段である代わりに、非ハイブリッドパスを選択するチームは、フレームワークの特定の言語（JSXやC＃など）だけでなく、学習する必要があります。また、各プラットフォーム（Java、Obj-C、またはSwift）のネイティブ言語。

サードパーティの依存関係。 この制限には2つの異なる形式があります。 React Nativeの場合、それは多数の依存関係、つまりおよそ650の形をとります。その結果、これらの依存関係の1つ以上が古くなっている可能性が非常に高くなります。 また、OSレベルが大幅に変更された場合、これらの依存関係のほとんどまたはすべてを更新する必要がある可能性が高いことも意味します。 潜在的な節約の恩恵は、FacebookがReactを使用していることです。そのため、300ポンドのゴリラが隅にあります。

Xamarinの場合、サードパーティの依存関係の問題は、そもそもそれらを統合することが非常に難しいということです。 Xamarinはこの問題を認識しており、Sharpieと呼ばれるユーティリティツールを提供しています。 このツールの目的は統合の一部を支援することですが、残念ながら、Sharpieは誤ったリソースをコンパイルしてリンクしようとすることが多く、開発者は低レベルのコンパイルパラメーターを手動で変更して正常に完了するという骨の折れる時間のかかるタスクを実行する必要があります。統合。

OSサポートラグ。 非ハイブリッドアプリケーションは、ハイブリッドアプリケーションと同じ問題に悩まされています。 開発者の制御が及ばず、最初に更新する必要がある中間フレームワークは、最先端のユーザーをサポートするためにアプリケーションを更新するプロセスを遅らせるだけです。 さらに、前述のように、中間フレームワークに依存することは、これらのフレームワークのタイミングが非常に不明であるため、プロジェクトマネージャーが計画を立てる際の頭痛の種になる可能性があります。

長期サポート（React Native） 。 この問題はReactNativeに固有のものであり、これまでFacebookがそのフレームワークの長期サポートプランを確約していないという奇妙な事実に関係しています。 同社はモバイルアプリに独自のフレームワークを利用しているため、これはリスクが低いと言えますが、Facebookがこの件についてコメントを拒否した理由をプロジェクトマネージャーが検討する価値はあります。

適切なアプローチの選択

コストが主な考慮事項ではない場合、図2は、アプリケーションの要件に対して開発チームの構成を活用する場合、ほとんどの場合、ネイティブアプリケーションを作成することが最良の選択であることを示しています。 必要なプラットフォームの数よりも開発エンジニアが少ない場合は、もう少し興味深いものになります。 その場合、チームのリリーススケジュールが非常に厳しい場合は、Reactを使用するのが正しい選択です。 それ以外の場合は、ネイティブにすることが依然として最良のオプションです。

チームが主にWeb開発チームであり、カスタマイズされたUXが必要な場合は、アプリケーションをネイティブにするために、一部のチームメンバーに帽子を変更するか、一部のチームメンバーを追加することをお勧めします。 多くのアプリケーションが行うカスタム要素がアプリケーションに必要な場合、実行可能で保守可能なフレームワークオプションは実際にはありません。

ただし、カスタムUXが必要ない場合は、リリーススケジュールによっては、IonicまたはReactを使用する方がよい場合があります。 チームがJSXを学ぶ時間がない場合は、Ionicが正しい選択です。 それ以外の場合は、Reactを選択することをお勧めします。これは、すでに多くのサードパーティの依存関係が必要であり、さらに追加しても開発サイクルに影響を与えないためです。

プロジェクトのコストが主な関心事になると、通常、既存のチーム構成の優先順位は低くなります。これは、最初のステップは、予測されるコストのプロジェクト計画を実行するための適切なチームを配置することであるためです。 図3に示すように、ネイティブアプリケーションは、対応するWODEアプリケーションよりも開始コストが高くなりますが、潜在的なUXも高くなります。 さらに、WODEアプリケーションは、プロジェクトに適用される資金とリソースの量に関係なく、常にUXで制限されます。

この記事が、さまざまなモバイル開発パスの長所と短所を明らかにし、アプリケーション要件とプロジェクトのコストの両方に対してチームの構成を比較検討するのに役立つことを願っています。 そのメッセージは、WODEフレームワークが劣っていて、決して探すべきではないということではなく、ネイティブにならないための有効なユースケースがあるとしても、そうすることの影響を完全に理解する必要があるということでした。