LISTENアプリ開発の背景
こんにちは、ninjinkunです。
TechVoice Advent Calendar、私は既に申し込んでいたのですが、まだ結構空きがあるようなので、この空きを時々埋める活動をしていこうかなと思います。
私はninjinkunといいまして、今はLISTENのアプリの開発をしているエンジニアです。
今回のアドベントカレンダーでは、おそらく皆さんLISTENのアカウントは持っていらっしゃると思うので、
もしかしてそのアプリをダウンロードしてくださっている方もいるかもしれませんし、まだの方もいるかもしれないんですけど、
ぜひ使ってほしいというのと、もっと突っ込んだ、もうちょっとエンジニア向けみたいな細かい話をしていこうかなと思います。
今回はFlutterについてお話ししようかなと思います。
LISTENアプリはFlutterという技術、プラットフォームで作られていて、
アプリは主に使われているOS、iOSとAndroidを両方に提供するというのが最近は主流なんですが、もちろんLISTENも両方に提供しています。
ただこれはそれぞれに対してアプリを作る必要があって、iOSだと今はSwiftという言語でiOS SDKを使って作る。
Androidだと今はKotlinという言語を使って、Jetpack Composeとか最近はAndroid SDKは使うんですけど、上にいろいろさらにレイヤーが乗っかって作られているというので、
何にせよそれぞれに対して専用で作らなくてはいけないというのが今までの世界で、
私も両方のOSに対して10年ぐらいアプリを作る仕事を昔はしていました。
なんですけど、特に少ないリソースの組織になるとiOSエンジニアとAndroidエンジニアを両方が買えるというのは結構コストになるし、
単純に時間もかかるし、というわけで両方のプラットフォームに向けて同時に作れないかというテクノロジーが時代によっていくつか出てきていて、
私も古くはTitaniumという技術とかリアクトネイティブを試したこともあったし、
Cordovaというもうちょっとウェブに近いようなプラットフォームを試したこともあったし、いろいろ使ってみたんですけど、
どれも結構欠点があって、なかなかこれをずっと使うのは辛いなというものではあったんですが、
リッスンは今回私が一人で作るということもあって、同時にやはり提供するのは無理だなと思って、
特に最近はFlutterとさっき言ったリアクトネイティブというこの2つがクロスプラットフォームを実現する主要なフレームワークとして、
結構採用例も増えてきていたので、今回はこれを使ってみようかなと思いました。
コトリンマルチプラットフォームとか、スイフトでアンドロイド向けアプリを作るみたいな技術も出てきているんですけど、
この技術選定をした2024年年末時点では、どちらもスイフトのほうはなかったし、コトリンのほうは確かプレビューがあるぐらいだったかな。
なのでちょっと選択肢に入っていなかったですね。
そうなると、さっき言ったリアクトネイティブとFlutterというこの2つの技術の勝負というか、
どちらかを採用することになる技術選定を行うんですけど、ここでミスると後にすごく響くので、
ずっとリスナーアプリをプラットフォームと一緒にその上でメンテしていく必要があるので、ここはすごく重要な、
言ってみればエンジニアの腕の見せどころでもあるわけですけど、比較しましてFlutterにしております。
Flutterの特徴と他技術との比較
何が違うかというと、リアクトネイティブのほうは、
リアクトというWeb向けのビューを作る技術をモバイル向けに転用したもので、
言語はJavaScript TypeScriptを使い、特徴としてはUIはリアクトで書くんですけど、
リアクトで書くと裏側ではネイティブのiOSのコンポーネントやAndroidのネイティブのコンポーネントが使われて、
それぞれのプラットフォーム向けに描画が行われるという、なので使用感としては結構ネイティブアプリみたいな使用感になると。
Flutterのほうはここがまた違っていて、言語はDartというあまり馴染みがない言語で書くんですけど、
描画の部分が完全に自作というかオリジナルのものが載っていて、
OS向けの各OSが用意しているそういう描画レイヤーを使わずに、
最近中身変わったんですけど、もともとはSkiaという描画エンジンを使っていて、
どうしているかというと、このDartで書かれたUIのコードが直接Skiaで実行されて、
画面にはそのSkiaのレイヤーが描画をするということで、
こうするとOSの描画ロジックを使わずに出てくるので、
同じコードで全く同じものがiOSとAndroidに出せるということになるんですよね。
これはメリット・デメリットがありまして、
メリットはOSのアップデートの影響を受けずに、
例えば最近だとiOSですとLiquid Glassという新しい見た目が導入されているんですけど、
こういうものにOSがアップデートしてもアプリが追従しなくていいし、
例えば両方で統一できるので、AndroidでデバッグしたらiOSでも全く同じ見た目が出るので、
デバッグが片方で大体動作が保証されるというメリットがあります。
デメリットとしては同じものが出てしまうので、
例えばAndroid向けのマテリアルデザインで作るとiOSもマテリアルデザインで描画されると。
これがMixy2というアプリがありますけど、
これをそのまま使っていて、iOSでも完全にマテリアルで描画されていますね。
人によっては違和感を感じるかもしれない、iOSっぽくないと思うかもしれないような仕組みになっていて、
一長一短ですねという感じですね。
こういうふうに比較を行うときは、
プロコンリストみたいなメリットデメリットを書き出して比較するのが大体セオリーなんですけど、
Flutterはそういうふうにして見た目を統一できたり、デバッグが片方で済むけど、
それぞれのOSの見た目に合わせるのは結構難しいことがある。
もう一つデメリットとしては、
FlutterはGoogleが作っているフレームワークで、
他の会社でも採用されているんですけど、主にGoogleがメンテナンスしていますと。
最近GoogleがFlutterに対する人員を減らしているという話があって、
本当かどうかは分からないですけど、どうも界隈ではそう言われているというので、
先行きが心配であるとか、あとはGoogleはいろんなサービスを修了させていますので、
Googleを信じられないという人たちもいると。
なのでGoogle一緒に偏っている、メンテナンス偏っているのがあまり信じられないという人たちがいると。
React NativeのほうはFacebookが作っていて、
さらに例えばAirbnbとかそういういろんなプレイヤーが採用していますので、Amazonとか。
あとはさっきのブルースカイっていうSNSのアプリなんかもReact Nativeですね。
あとDiscordもReact Nativeじゃないかな。
いろんな人たちが採用しているし、
メンテナンスも開発もFacebookに偏っているわけではなさそうで、
いろんな人たちが参入しているという感じで、
開発体制にも違いがあると。
そういう少しポートフリー的になっているのがいいというのでReact Nativeを選ぶ人たちもいますと。
じゃあ今回なんでFlutterにしたのかというとですね、
Flutterの選定理由
私は結構両方で簡単なPodcastアプリを作って比較してみるっていうことをしたんですね。
その使い勝手で見た感じ、
どっちも書き味にはそんなに差がないなっていう。
書きどっちでも作れるしどっちでもいいなっていう風になったんですけど、
一つ決め手になったのが、
React Nativeは素のReact Nativeっていう状態と、
さらに上にもう一段Expoっていう層をかぶせるっていう使い方があって、
今は後者の方が主流なんですね。
このExpoはですね、かなりいろんなものを提供していて、
そのネイティブの部分を統一して提供してくれたり、
あとはOTAっていうオンラインアップデートを提供してくれたり、
すごくその開発体験を向上させる層を提供してくれていて、
正直多分Expoを使わずに開発するのは今はかなりハードモードなのではという、
それぐらいもうExpoありきの世界観になってますと。
私はですね、これは素晴らしいレイヤーである反面、
少しこういう層がですね、3層になってるっていうのは気になって、
つまりネイティブの層、React Nativeの層、Expoの層っていう、
この3つの層に依存してるっていうのはですね、
結構少人数開発としては辛いんじゃないかなと思っていて、
これは何かっていうと、
それぞれのレイヤーのアップデートの影響を受けるわけですよね。
なのでまずはアプリ作るぞって、
継続的にメンテナンスするぞっての時に、
iOS、Android、そのネイティブの知識を追っかける必要がある。
彼らの発表を見たりとか、ニュースをキャッチする必要があり、
React NativeはさらにReactに依存してますんで、
ReactのアップデートとReact Nativeのアップデートの情報を追っかける必要がある。
そしてExpoの情報を追っかける必要があると。
もしどれかがアップデートしたら追従しなくちゃいけないっていうね、
追っかける先が増えるっていうこと自体が、
ちょっとね、しんどいなっていう。
フルタイムでやるんだったらできると思うんですけど、
ちょっとね、リッスンのアプリ開発を始めた時は、
完全にパートタイムで始めてたので、
これはちょっと一人開発には辛いんじゃないかなという、
実際やればできたかもしれないですけど、
結構自分は技術選定の時に、
依存先が多いものは避けるっていう、
これは割と一つの考え方であるんですけど、
というので今回は、
できるだけ追っかける先が一つに統一されているFlutterの方を選びました。
開発体験とユーザー体験
Flutterの方は正直Flutterの情報さえ追っかけていれば、
基本的にはあまり問題はないですね。
OSの下の方に依存している、
例えば今回ですと音声再生とかね、
そういう部分はOSのコアの部分叩くんで、
というかネイティブの部分か、
そっちはアップで追っかける必要があるんですけど、
例えばUIの層とかは知らなくても何とかなるっていう感じなんで、
今回はそういう依存先が少ない、
そしてオーニュースが少なくて済む方でFlutterを選びました。
そして今開発をもう大体1年ぐらいやってきて、
今のとこはFlutterでよかったなというふうに思ってますね。
OSの例えばテレで作ってしまうと、
iOSに寄せるのが大変みたいなところは、
ここはFlutterはCupertinoというもう一つのウィジェットが用意されていて、
これはiOSの見た目を再現したUIウィジェットになっていて、
これとマテリアルを割と差し替えるということを結構頑張ってやった結果、
今のとこ自分のiOSユーザーとしてはiOSっぽいUIが実現できているかなと思います。
最新のリキッドグラスには全然対応できていないんですけど、
それは今のところやらなくていいかなと思っているので、
この使い方の見た目、ユーザー体験は結構よくできたのではないかなと思います。
逆にマテリアルのほうが若干iOSっぽくなってしまったかなというところはあるんですけど、
自分は今のところユーザー体験には満足しているし、
開発体験としてもFlutterはすごい素晴らしいかなと思いますね。
これは多分React Nativeと一緒だったんでしょうけど、
かなりiOSでしっかりデバッグすればAndroidでも大体動くと。
たまに例えばListenですと、最初は音声が連続再生されないとか、
バックグラウンド再生されないとか、いろいろベータ版の間は不具合があったんですけど、
そこさえ潰していけばUIのレイヤーでは基本的に差異が出ないというのは本当にありがたいなと思いましたね。
たとえばダウンロード機能みたいなややこしい機能を作るときも、
本当に一つのコードで両方のプラットフォームで問題なく動いてくれたんで、
両方のプラットフォームでデバッグするというのはかなりしんどいので、
それが一元化されたというのはとてもありがたいですね。
という感じで今のところはFlutterは最高だなと思っております。
また本当にフルタイムの仕事でこの技術選定になると今は違うかもしれないですけど、
今のところはListenアプリやFlutterでとてもいい開発体験が得られているんで、
いいんじゃないかなと思いますね。
おそらくもともとオープンソースのフレームワークですんで、
AIとの相性も悪くなくて、
DARTという言語を私は正直このListenアプリを作るまで一応も書いたことはなかったんですけど、
AIに書いてもらうことにより全然いい感じに書けてます。
多分DARTの最新の機能とか使えてないんでそこをアップデートしていく必要はあるんですけど、
そのあたりのこの書き方古いなみたいな感が働かないのは
ちょっと経験がない以上しょうがないんですけど、
そのあたりはDARTの最新情報を追っかけたりして少しキャッチアップしている。
さすがにこの書き方今はしないでしょうみたいな指示を何とか出しているつもりではあるんですけど、
少なくともAIと協業する分には全然DARTも書けるなという感じですね。
そんなに癖がない言語でもあるんで。
という感じでTechBoysアドベントカレンダーの中で
Listenアプリの話をしていく最初の回はFlutterについてでした。
それではありがとうございました。
