この記事はReact Nativeアドベントカレンダーの14日目の記事です。
当日夜になってしまいましたが、、
はじめに
こんばんは。ムゾウの渡辺と申します。
ReactNativeでのアプリ開発を3年ほどやっており、
ちょうど1年ほど前からはExpoでの開発を特に多く扱っています。
去年の今頃は、RNのビルドで疲弊していたせいもあり、Expoサイコーという気持ちだったのですが、
1年ほど開発、運用を続けていく中で、なかなかうまくいかない経験だったり、XXXだったらなーということも増えてきている昨今です。
この記事ではそんな1年の振り返りとして、Expoでの辛かった思い出をまとめて見ようと思います。
Expo辛かったことまとめ
1) ネイティブレイヤーでエラーになった時に辛い
究極、これに尽きるのですが、Expoでネイティブ層のエラーに直面するとかなり詰みます。
仕様面の調整や、他の方法で要求を満たすことができないか検討するしかないのですが、
新規の機能開発であればそういった方法も比較的柔軟にとれるものの、
Expoのversionのアップデートなどでそういった事態に遭遇した場合、かなり苦しい状況に追い込まれます、、
今年あった中で一番辛かったものは、、
Expo34=>35にupgradeしたあと、iosでfcm経由のpush通知が全てクラッシュしてしまう
でした。
原因は、apnのpayloadでdataとして渡しているものがfcmのクラシックなapi経由ではjson形式で渡されており、34まではそれをjs層のexpo内でdataとして展開していたのですが、35ではネイティブレイヤーで一部解析するようになったためでした。
ネイティブの方のコードにブレークポイントをつけて手元でビルドできるわけでないので、原因を突き止めるまでも辛いのですが、わかったところで改善することもできず、、
この件に関しては、fcmの別のapi経由でapns用にpayloadを設定することで解決できたのですが、かなり時間がかかりました。。
他にも
- expo32 => 33に変えた時に、ReactNativeのcamerarollの内部挙動が変わっており取得した画像の順番がめちゃくちゃになる(ExpoのMedialiblary使うように置き換えて解決)
- Number.prototype.toLocaleString()がandroidで動かない(どっちかというとjscoreの問題?)
- 未だ原因不明のネイティブレイヤーのクラッシュ
などなど、何かあった時に手元でビルドできないことの苦しさを感じることが何度かあった一年でした。
(他のExpo使いの方はこのあたりどう調査しているのでしょうか、、xcodeでクラッシュログ拾ったりadb logcatでみたりの範囲から推定する、、以外ないのでしょうか、、情報求む、です）
2) リリースビルドでの確認が必要な機能があると、生ReactNativeよりも生産性おちる
1にも関連するのですが、ビルドが必要な機能があると、実装&確認の時間が効率が落ちてしまします。
自分の場合は、↑にも書いたプロジェクトでpush通知にfcmを利用したケースで、expoアプリでの機能確認ができず、大幅に確認工数をさかれてしまいました。。
3) publishのversion管理が辛い
EXPOの利点として、組み込み済みのOTAアップデートがあるかと思います。
code-pushのように別途アカウントを設定したり、native moduleを組み込んだりすることなく使うことができるので非常に便利！ではあるものの、実際にうごいているコードがどのpublishバージョンなのか、わかりにくくなってしまうことがあるかと思います。
自分のかかわっているプロジェクトでは、別途publishのversionの番号を管理するファイルを作成し、アプリ内で表示するようにしています。
code pushだとこの辺りのバージョン管理がわかりやすく、バージョンを取得するapiもあるのでちょっとexpo側も改善されないかな、、と期待しています。
4)Expoのサーバーが落ちている時に遭遇すると絶望する
ダイレクトに遭遇したのは2回ほどですが、たまにExpo落ちていてしばらくビルドが全くできないときがありました。
自分の場合、8月の月末でその日確認予定の機能のビルドを準備していたところ遭遇してしまい、かなり焦りました。
twitterのexpo_statusなどを見ていると、大きな障害のときには情報が乗っていたりするようです。
https://twitter.com/expo_status/status/1167112503991472134
5)ReactNativeの方では修正された不具合がExpo同梱のReactNativeに採用されるまでの時差
これももうどうしようもないといえばどうしようもないのですが、、
例えば日本語がAndroidで下が見切れるようになってしまう、などReactNative側でたまにとんでもない不具合が急に噴出していたりするので、そういったものの対応が遅くなると、辛い気持ちが強くなります。
https://github.com/facebook/react-native/issues/25297
とはいえ、expoも定期的に新しいversionが出ていますし、なんせupgradeがそこまで辛くない！ので待てば解決、です。
結局Expoでよかったのか
上述したとおり、最初の印象と比べるとデメリットに気づくことも多かった一年ですが、逆にいうとそれ以外は快適に開発を進めることができました。最初のころは生ReactNativeでつかっていたころにnative moduldeのライブラリでやっていたことの置き換えに戸惑ったりもしましたが、ある程度要件の調整で目処が立ってしまうとほぼほぼのアプリはExpoで開発の効率はあがったのではないかなと思います。
特にReactNativeのアップデートと比較すると圧倒的ににupgradeが簡単で、それだけとってもreact-nativeアプリと比較し運用中の負荷は減りました。
（2019年は夏のAndroidX対応などupgradeが必須のイベントが多かったので、だいぶ助けられました）
とはいえ、最近はautolinkにfast reloadにunimoduleにと、生ReactNativeでの開発快適性もだいぶ良くなっていますので、、
今後は案件、要件に応じてExpoも生ReactNativeも両方うまく使っていきたいです。
-
明日は@nitakingさんの「参考にできないAndroidのイケてないrender制御」です