React Nativeとは？映画『マトリックス』を例に、非エンジニアでもわかるネイティブアプリ解説

モバイル向けのアプリの設計者にとって、React Nativeは様々な利点を兼ね備えたフレームワークです。React Nativeで設計すれば、”ネイティブUI” を備えたアプリが作れるため、従来のWebView UIと呼ばれるインターフェースを使ったものに比べUXがはるかに向上します。

この記事では、”ネイティブ”とはそもそも何を意味するのか、WebView UI とは何か、優れているポイント等をご紹介します。また、React Nativeが、PhoneGap・Cordova・Ionicなどの従来の設計フレームワークに比べてどのような利点を持つのか、さまざまな点から検証します。

そもそも”ネイティブアプリ”とは？

ネイティブアプリがどう「ネイティブ」なのかを理解するために、あの有名映画『マトリックス』を振り返ります。

私達が現実だと思っている世界は機械たちによって造られた仮想現実である。そして真実に目覚めた人間たちが「ニセモノの現実」から外に脱出し、ここなら本当に自由でいられると信じたザイオンさえも、機械がそのようにプログラムしたバーチャルリアリティである…

これがマトリックスの世界観です。
ある仮想現実が外側の仮想現実世界のシミュレーションとして作られており、そのさらに外に本当の世界がある、つまり「多層構造の仮想現実」を持った世界なのです。

マトリックスの世界観は、PCや電話が持つソフトウェアの構造と多くの共通点があります。

ソフトウェアは、莫大な数の物理的なトランジスターや回路、つまりハードウェアに対する指令の集合体です。ハードウェアを直接動かす生の指令信号は、とくに今日のコンピューターの複雑さとスケールを考えるとなおさらですが、もう私達人間にはほとんど理解できません。物理的な機械を動かす言葉と人間の意志の間に入って「翻訳」してくれるのが、OSやアプリなどのソフトウェアなのです。

より人間が直観的にソフトウェアを利用できるように、ソフトウェアの中でも、機械に近いものから人間に近いものの間で複数の層があります。あるフレームワークは、別のフレームワークの上で指令をまとめて、上に伝える。伝言ゲーム状みたいな感じですね。

この複層構造の中で、ハードウェアに近ければ近いほどそのソフトウェアは、「ネイティブ」だという訳です。

というわけで、”ネイティブ性”はかなり相対的な用語です。アプリをそれだけを取り出してネイティブだ、ネイティブでないという言い方はできず、常に、他のアプリに比べてよりネイティブかどうかという判断になります。

たとえば、アンドロイドのアプリは C++・Java ( Kotlin) ・ Cordovaで作れます。この中では、C++を使用したアプリが 一番ネイティブで、Cordova 使用アプリが最もネイティブではなく、 Java/Kotlinは中間に位置する、という言い方ができます。

“ネイティブアプリ”の利点

では、よりネイティブなアプリを使うとどういうメリットがあるのでしょうか。ネイティブ度が高くても低くてもある意味では一長一短です。一言でいうと、物理的な機械に近ければ多くの自由を得られ、いくつものシミュレーションの層を経ていると自由を失う代わりにそれだけ快適。マトリックスの例えでいえば、「バーチャルリアリティだけが世界だと信じたまま生きる人生もあり」みたいな感じでしょうか。

知らぬが仏という言葉もある

よりネイティブなフレームワークで作られたプログラムは、ハードウェアの特徴に対応してアクセスが効き、それらをより自由に使えます。異なる言語の翻訳やシミュレーションに費やす労力が少ない分、より効率的に動きます。しかし、先ほどのマトリックスの例えでいうと、バーチャル世界で生きるより本当の現実での人生の方が厳しいように、こうしたハードに近い（=Native）アプリを作るコードは書くのも理解するのも難易度が高いのです。

一方で、私達人間にとっては、ネイティブ度の低いフレームワークでコードを書く方が簡単です。プログラミング言語はより理解しやすく簡潔で、私達人間の自然言語に近い語彙を持っています。ハードウェアの構造についての理解とか性能についての理解もあまり必要ありません。

さらにもうひとつ、ネイティブ度の低いフレームワークのプログラムは「持ち運び可能」という利点があります。こうした言語持つ語彙やコンセプトは、元々のハードウェアの特徴に対応するための特定の何かを持っていないので、変更を全然加えずに、まったく違くハードウェアで動かすことができるのです。しかし、こうした楽さ・快適さの代償として、効率や自由がある程度犠牲になります。

モバイルフレームワークの二大陣営

React Nativeを除くと、モバイル向けのフレームワークはふたつのグループのどちらかに分類できます。

ひとつ目は「ネイティブ」陣営。例えばAndroid用の Java/Kotlin、iOS用のObjective-C/Swift。この陣営のフレームワークを使えば、アプリの動作が早くなり、ハードウェアのありとあらゆる特徴に対応が可能です。

UIは、それぞれのターゲットであるプラットフォーム（AndroidあるいはiOS）に合わせてカスタムメイドされているのでさくさく動くし、ストレスなく使えます。しかし、そうした使いやすさが発揮されるのはあくまでひとつのプラットフォームに制限されます。

アプリを設計するには、開発者は２つの異なるフレームワークを覚えなければならず、単純に考えても倍の学習量がかかってくる。これが原因で何万人ものデべロッパーがついていけなくなったのも事実です。

そこで、第二のモバイル向けフレームワーク陣営が登場するわけです。たとえば Cordova/PhoneGap や Ionicなどのフレームワークを使えば、デベロッパーはモバイル向けのアプリを、既存のHTML・CSS や JavaScript の知識で設計できます。

完成したアプリはAndroid でも iOS でもさらにその他のOSでも使えます。しかし動作は遅いし、それぞれのハードの特徴にもアクセスが悪い。なんといっても、ユーザーインターフェースの質が最大のデメリットです。そうしたフレームワークはUIのレンダリングにWebViewと呼ばれるアプリ内でWebページを表示できるコンポーネントを使うので、ここからはこの第二グループたちを「WebViewフレームワーク」と呼ぶことにします。

WebView フレームワークは第一グループのネイティブフレームワークの上に設計されています。つまりWebviewフレームワークは、ネイティブフレームワークの中に走っている仮想世界だ、という感じです。このように捉えると、上述の利点と制限がある理由が掴みやすいかもしれません。

では、両者のいいとこどりをすればいいのでは……？というわけで生まれたのがReact Nativeなんです。

React Native は、ここまで紹介した２つのグループのどちらでもない、３つめのグループを代表するモバイル向けフレームワークです。UIは WebView フレームワークよりネイティブ度が高く使いやすく、一方残りの部分ではネイティブフレームワークにはない、十分シミュレーションされた水準の動作性を保持しています。

React Native製アプリのUIはWebviewUIよりネイティブ度が高い

Cordova のような第二グループのフレームワークを使えば、モバイル用UIをWebの技術を使って設計することができます。そのやり方は、Webブラウザをすべてのアプリにこっそり貼り付けるというもの。これがここでWebViewと呼んでいるものの実態。UI上にあるボタン、メニュー、アニメーションなどなど全てのものは、ブラウザの中でWebページの中で動いているものなんです。

仮想世界の例をもう一度持ち出して説明すると、Cordova製アプリのインターフェースは、ネイティブフレームワークの内側に作り出された仮想世界であるWebブラウザが、その内側に作る仮想世界だ、ということです。

それに比べて、React NativeのUIはWebViewのより一層分だけネイティブ寄りであるということができます。ネイティブフレームワークが自分の内側で動かしている仮想世界という感じ。

React NativeによるUIの強みを決定づけているのがこの構造なんです。React NativeはネイティブUIのウィジェット（ボタンやメニューなどインターフェース上に現れるもの）を直に使っているのに対して、WebViewフレームワークはHTMLやCSSを用いたWebのUIを通してなんとかネイティブフレームワークのUIの見た目や使い勝手をマネしようとしている。

体験上、WebViewのフレームワークで造られたアプリだな、という判別は簡単にできます。スクロールの速さだとか、キーボードの動き方、クリックした後の推移や一般的なUIのスムーズさなど小さなところに違いがでてきます。そういう小さな動作ひとつひとつにネイティブなものとの動作の差が生まれると、積み重なってUXに大きな差が生まれ、ユーザーが不満や苛立ちを覚える結果に結びついてしまいます。

React NativeはJavaScriptで

一方で、React NativeはJavaScriptでコーディングできて、HTMLやCSSと似た文法を使うことができます。Webデザイナーやデベロッパーにとって、参入障壁が低いことは言うまでもありません。

必要があれば、React Nativeはネイティブフレームワークまで”貫通”して、ハードに特有の機能でアプリを補うこともできます。これは映画『マトリックス』で電話をかけるところにちょっと似ています。

では WebView フレームワークは もう要らないのか…？

もうwebviewフレームワークが必要なくなったかというと、それは違います。例えば、すでにWebアプリができていて、それをApp storeにリリースしたいとき。多少ユーザーエクスペリエンスを犠牲にしても、市場になるべく早く出すことを優先するでしょう。また、使用者との相互性が低いコンテンツをアプリが提供している場合。インタラクティブに動く場面が少なければ、Web View で作ってもそんなに困りませんよね。

しかし、そのアプリにおいて UXの重要度が高い場合、あるいはユーザーによる打ち込み、ドラッグ ＆ ドロップや、スクリーンをスワイプしたり…等、インタラクティブな操作が多いアプリの場合は、React Native の使用を検討すべきです。結局上記のような場合は、WebView UIでネイティブUIをマネする努力をすることになるので。

まとめ

この記事では、”ネイティブアプリ”のネイティブが何を意味するか、そしてWebView UI の特徴と、React Nativeがなぜ優れているか、そしてWebViewフレームワークである  Cordova・PhoneGap や Ionic に比較して検証してみました。

（翻訳：Yuko nakamura）