クロスプラットフォームモバイル

多くのモバイルプラットフォームが登場し、それぞれ異なるUIを持つ中、多くの人がクロスプラットフォームツールキットに注目しています。これにより、モバイルアプリを一度作成して、様々なモバイルデバイスに展開できます。これらのツールキットは使用する価値があるのでしょうか？

クロスプラットフォームツールキットは魅力的です。多くのモバイルデバイスが存在し、それぞれのためにアプリケーションを作成するのは大変な作業です。一度記述してどこでも実行できれば、はるかに容易になります。

もちろん、デスクトップアプリケーションでも同様の状況がありました。長年にわたり、デスクトップ向けのクロスプラットフォーム環境を作成しようとする多くの試みがありました。Javaは恐らく最もよく知られていますが、最善でもなければ最初のものでもありませんでした（SmalltalkユーザーにVisualWorksについて尋ねてみてください）。しかし、クロスプラットフォームアプリは全体として成功していないことに気付くかもしれません。[1][2]

最初の問題は、異なるプラットフォーム間でのUIコントロールのバリエーションを処理することです。大きく分けて2つの戦略があります。各プラットフォームでネイティブコンポーネントを使用するか、よりプリミティブなグラフィックスを使用してコンポーネントをエミュレートするか（つまり、独自のUIシステムを作成する）です。Javaの世界では、これはSwing（エミュレーション）とSWT（ネイティブコントロール）の違いでした。

どちらのアプローチにも問題があります。ネイティブコントロールを使用する場合、異なるプラットフォーム上の類似したコントロールが動作にわずかな違いがあるという事実に対処する必要があります。これは、適切な抽象化を考案することを困難にします。さらに、一部のプラットフォームでのみ利用可能な機能についてどうするかを決定する必要があります。プラットフォームの最低共通分母で終わってしまうのでしょうか？

そのため、全体的なアプローチとして、または一部のプラットフォームで入手できないコントロールを補うために、エミュレーションが魅力的になります。エミュレーションにはいくつかの困難があります。第一に、エミュレートされたUIを十分に高速に動作させるのは困難です（UIコントロールにとって非常に重要です）。第二に、ネイティブコントロールとまったく同じように動作させるのは非常に困難です。ほとんどネイティブコントロールのように動作しますが、ユーザーを混乱させるのに十分な小さな違いがある「不気味の谷」に陥りやすいです。UIコントロールでは、動作を「完璧に」するには非常に細心の注意を払う必要があります。

優れたUIコントロールを得るのはほぼ不可能ですが、それは最大の課題ではありません。最大の課題は、全体的なユーザーエクスペリエンスに関することです。異なるプラットフォームでは、全体的なエクスペリエンスデザインを変える方法が異なります。Unixベースのシステムを使用する場合、優れたエクスペリエンスデザインでは、ミドルマウスボタンを多用することになります。これはUnix UIの方法だからです。しかし、Macでそれを行うと苦労します。Macは、2つのボタンですら多すぎると考えているからです。

モバイルデバイスは、全体的なユーザーインタラクションのアプローチにさらに大きな違いがあるため、さらに大きな負担を負っています。最近、クライアントから、開発したiPhoneアプリをAndroid版にするように依頼されました。初期の実験から、まともなAndroidアプリを得るには、エクスペリエンスデザインを根本から考え直す必要があることがわかりました。iPhoneアプリのテストケースは、Androidアプリの機能にとって非常に貴重なチェックリストになりましたが、アプリ全体の雰囲気は異にする必要がありました。

そのため、これらの理由から、クロスプラットフォームモバイルツールキットは行き詰まりであると考えています。ネイティブエクスペリエンスを本当に模倣するには、あまりにも困難です。ネイティブアプリを作成する価値がある場合は、そのプラットフォーム固有のエクスペリエンスデザインを含め、適切に作成する価値があります。[3]

では、多くのモバイルプラットフォームをサポートしたいが、各プラットフォームのネイティブアプリのコストを負担する準備ができていない人はどうすればよいでしょうか？幸いなことに、価値のあるモバイルデバイスであればどれでも動作する単一のプラットフォームがあります。それはWebです。Webアプリは、熟練した開発者によって作成された場合、現在では非常に機能的で高度なことができます。ここで最大の課題はオフライン使用です。常にオンラインで問題ない場合は問題ありませんが、オフラインが必要な場合は、様々なローカルストレージオプションを検討する必要があります。

Webアプリを作成する際は、ネイティブアプリのように見せるのではなく、モバイルWebアプリのように見せるようにしてください。それでもエミュレートされたアプリと同じくらい使いやすくなりますが、ユーザーを不気味の谷に陥れることを避けることができます。これはデスクトップで起こったことと似ており、複数のデスクトッププラットフォームをサポートしたいと考えている人々は、Webを効果的な展開プラットフォームとして見つけています。ここで成功の鍵は、人々がWebアプリをWebアプリのように動作することを期待しているため、ネイティブアプリのようにすることを期待していないことです。これにより、異なるプラットフォームでの異なるユーザーの期待の問題を回避できます。

要約すると

• クロスプラットフォームツールキットを使用しないでください
• 最大限のリーチを実現するには：Webアプリのように見えるWebアプリを作成してください
• 特定のプラットフォームに訴求するには：そのプラットフォームのインタラクションスタイルに基づいて、そのプラットフォーム用のネイティブアプリを作成してください

フォローアップ

メールやその他のコメントからのいくつかの考えと反応

ある通信員は、彼の会社がWebアプリを薄くラップしたネイティブアプリを作成する方法について話しました。これにより、起動と共通リンクへのアクセスが容易になり、動作の大部分はクロスプラットフォームのWeb内で維持されます。

ガンナー・ピーターソンは、セキュリティモデルの違いもクロスプラットフォームツールキットを推奨しない理由であると主張しています。