見出し画像

Android(iOS)はクロスプラットフォームの夢を見るか

クロスプラットフォームを皆が求め、まだたどり着けない

モバイルエンジニアの悩みはAndroidとiOSの両方のアプリを書かなければならないこと。
スマホが流行してからずっとこの二大巨頭は維持され続けており、おそらくこれからも我々モバイルエンジニアはAndroidアプリとiOSアプリを書き続けるのだろう。

クロスプラットフォームについてよくまとめられているスライドがあったので是非読んでほしい。

これまで多くの人たちがこの問題を解決しようと取り組み、様々なものが生まれてきた。xamarin, react native, flutter, phonegap, kotlin-MPP, etc...
しかし、いまいち流行らない。多くのプロジェクトでは結局kotlin(java)とswiftを書き続けている。これは結局framework側がAndroidとiOSの違いを吸収しきれていないのが根本の原因だ。どのframeworkを採用してもAndroid専用、iOS専用のコードはどこかに生まれてしまう。そして、それが積み重なると2つのアプリを書いているのと同じ、もしくはそれよりも酷い状況になる。世の中のエンジニアはそれが分かっているから避ける。

Kotlin-MPPの割り切りに感動した

しかし、その中でもkotlin-MPPはロジック部分はkotlinが担保するからUIはそれぞれで頑張ってくれ。という割り切った考えをしている。よくよく考えればUIとロジックすべてが共通化されている必要はない。もちろんされていたほうが嬉しいが、現実的に難しいのは歴史が物語っている。そして、UIはプラットフォームごとに異なる。AndroidはAndroidらしい画面、iOSにはiOSらしい画面というものがある。そもそも画面が共通ではないので、ここを担保せず、ロジックのみに着目したのは素晴らしい。

それでもkotlin-MPPは夢を見ている

美しいクロスプラットフォームの姿は
・UIはそれぞれのプラットフォームごとのUI
・ロジックはクロスプラットフォーム

だが、現実として実現が容易なのはおそらく
・UIは共通(各プラットフォームが用意している部品を使わず、自力レンダリング)
・ロジックはプラットフォームごと

だろう。クロスプラットフォームが苦戦している理由が、frameworkがOSの差を吸収できないことだとしたら、ネイティブAPIに触るロジックこそ一番共通化が難しいはずだ。

Flutterに光明を見た

Flutterは自力でレンダリングし、UIに関してはAndroidとiOSの共通化を実現している。ロジック部分も頑張って担保しようとしているが、正直まだまだ共通化できていない。
しかし、MethodChannelと呼ばれるそれぞれのネイティブのAPIを呼び出すための口が用意されている。これを呼ぶとネイティブ側のメソッドが呼ばれ、引数のcallbackを呼ぶと呼び出し元に値を返すことができる仕組みだ。詳しくはリンク先を見てもらえば理解できるはず。
FlutterはReactに似た記述をする仕組みになっていて、ReduxやFluxといったアーキテクチャが採用しやすい。そして、Reduxアーキテクチャにおいて、ネイティブのAPIを触る可能性がある部分はMiddlewareのみである。Middlewareから先の処理を全てMethodChannelでネイティブ側で処理をして、callbackで値を返し、middlewareでそれを扱う。これは意外と良い形なのではないかと思っている。

銀の弾丸ではない

この方法はまだ試したこともない妄想レベルなので、うまくいくかもわからない。(やってみたらダメダメかも)
また、仮に実現したとしてもiOSアプリがかなりAndroidっぽい画面になってしまう。これはFlutter故どうしようもない。React Nativeにも同じような仕組みがあったらそっちでもいいのかも。
どちらにしろ、WRITE ONCE RUN ANYWHEREはまだまだ未来の話となりそうだが、少しでも自分の苦痛を取り除きたく考えてみた。
もし、試してみてよさそうならQiitaあたりにコードとともに載せたい。

この記事が気に入ったらサポートをしてみませんか?