この記事はスターフェスティバル Advent Calendar 2021の8日目です。
こんにちは、スターフェスティバル株式会社 ソフトウェアエンジニアのYoshifujiです。今年のアドベントカレンダーとしては2度目の登場です。
弊社では今年、はじめてReact Nativeでネイティブアプリを開発し、リリースまで漕ぎ着けました。今回はReact Nativeのキャッチアップからアプリのリリースまでの間でやったこと、感じたことについて書きます。
なぜReact Nativeなのか
今回のアプリ開発を行ったチームでは、それまでWebアプリケーションのフロントエンド開発にReactを採用しており、その書き方の大部分を流用できるReact Nativeは非常に導入しやすいものでした。
Flutterは？
React Native以外の有力な候補として、Flutterがありました。Flutterは、クロスプラットフォームでアプリ開発を行うためのフレームワークで、Googleによって開発されています。
パフォーマンス面や生産性の面から非常に注目されているフレームワークですが、触ったことのないDartという言語を一から学習するコストと天秤にかけた結果、短期間でリリースまで持っていけそうなReact Nativeを採用することに決めました。
Expoは使う？
React Nativeでアプリを開発しようとすると、まず一番にExpoかReact Native CLI のどちらを使うかを選択する必要がありました。
ExpoはReact Nativeを使ったアプリ開発をサポートするフレームワークで、端末固有の機能の一部をExpoSDK APIとしてサポートしています。
QRコードで実機確認をできたりと、開発や公開時の便利機能が含まれているところに魅力があるフレームワークですが、一方でAnalytics SDKなどのネイティブ機能の組み込みに制約があります。当初の要件ではExpoで十分でも、機能追加に応じて毎度Expoで実現可能かどうかを検討する必要があり、いずれ限界がやってくるのではないかと考えました。
React Native CLIでは実機確認の時点でXcodeやAndroid Studioをインストール・設定する必要があり、初動コストは高く感じられましたが、ネイティブ機能やライブラリの組み込みやすさを重視してこちらを選択しました。
主な使用技術
この1年で2本のネイティブアプリをリリースしたので、その2本で使用した主な技術を列挙してみます。
- React Native
- TypeScript
- GraphQL
- Apollo Client
- Firebase
- Firebase Authentication: ログイン永続化
- Firebase Cloud Messaging: Push通知
- Firebase App Distribution: 開発バージョンのアプリ配布
- その他Firebaseの諸々
- Auth0
- fastlane: deploy, distribute の自動化など
キャッチアップするためにやったこと
公式ドキュメントをめちゃくちゃ読む
これはどの技術をキャッチアップするうえでも基本となる行動ですが、とにかく公式ドキュメントを読みまくりました。
キャッチアップ当初だけではなく、開発中も頻繁にお世話になります。推奨されるやり方が変更になっていることも多く、最近では公式で用意されているコンポーネントが続々と非推奨になっていき、コミュニティパッケージを使用するよう促しているものが増えてきているようです。
OSSのコードを読み漁る
開発する中で、認証と永続化はどうやるのか？画面遷移は？アニメーションは？クレジットカードの扱いは？など、正解がわからないものを手探りで進めていく必要がありました。
そのときに一番参考になったのが、OSSのコードです。公式で紹介されているものをよく閲覧しました。
これを読み漁ることでいろんな実装のベストプラクティスを感じることができました。ありがとう。
React Native本体のコードを読む
これも特にReact Nativeに限った話ではありませんが、よく使うコンポーネントやイベントがどういうふうに実装されているのかを知らないと挙動がイメージできないケースがあったので。
実装を読むのはちょっと気合が必要なことでしたが、得体の知れないネイティブコンポーネントもコードを読んでみると意外と単純なものだったりします。
辛かったこと
実機だと動かない現象
シミュレータでは問題なく動くのに実機に持ち替えた途端に動かない、ということは度々ありました。当初は実機でのデバッグに慣れておらずとても苦労しました、、特にAndroidは実機での挙動がシミュレータと異なることが多かったです。XcodeやAndroid Studioを使用した開発環境への理解も必要で、React NativeだけでなくiOS/Android開発に関する記事を探して学びつつ、少しずつ慣れていきました。
外部ライブラリの検討
画面遷移、決済、認証、テストなど、外部ライブラリに頼ることはとても多かったのですが、その度に自分たちが開発しているアプリにマッチするものを探すのに苦労しました。React Nativeで使えて、TSで書けて、Expoではなくて、、といった条件を重ねていくと、使用できるライブラリが限られます。これだ！というものを見つけても、バージョン依存の関係でお見送りする例もあり、悲しくなりました。
また、「React Native」で検索すると「React」向けのものがよくヒットするので、それを排除しつつ調査するのもストレスでした。
英語ばかり読んでいる
日本語の信頼できる情報ソースが少なく、気づけば何時間も英語のドキュメントを読んでいることが多かったです。英語、読んでいこう。
よかったこと
スピード感
慣れ親しんだReactベースの開発なので、書き方がわからなくて手が止まる、といったことはありませんでした。状態管理やコンポーネント設計など、アプリ特有の事情はあるにせよ、WebフロントエンドをReactで開発するのと同じ容量で検討することができました。
ある程度のネイティブの知識が必要なのは間違いありませんが、「ネイティブのことは知らんけどReactはバリバリ書けるよ！」という人でも開発に参加できるのは素晴らしい。
デモを共有してテンションを上げた
なにぶん初めてアプリを開発したので、とにかく楽しかったです。
少し作っては動画をSlackで共有しテンションを爆上げしていました。ヌルヌル動くネイティブアプリが徐々に出来上がっていくのはたまらない快感で、それに伴って開発スピードも上がっていきました。
また細かくデモ動画を共有していたので、仕様の認識が異なっていた部分などをすぐに擦り合わせることができ、手戻りも少なく進めることができました。これはWebの開発にも活用できる開発スタイルだと思います。
社内へのインパクト
アプリ、作れるよ！と社内に知らしめることができ、今後の事業の意思決定に大きめな選択肢を作ることができたのではないかと思います。現に最初のアプリのリリースから半年後に、2つ目のネイティブアプリをReact Nativeを使って開発・リリースすることができました。
1つ目のアプリをリリースできていなければ起こりえなかった意思決定だと思うので、会社にとっても大きなインパクトを残せたと感じています。
最後に
以上、ざっくりとですが初めてネイティブアプリを開発した時のことを振り返って書いてきました。ネイティブアプリの開発はとても楽しいので、これからも学び続けていきたいですね。
弊社はもっともっと多くのエンジニアメンバーを欲しています。ネイティブアプリに関心のある方も、そうでない方も、どうかお気軽にご連絡ください！
Discussion
Expo managed なアプリではなくても expo-hoge 系ライブラリ使用できますよ