production.log

株式会社リブセンスでエンジニアをやっている星直史のブログです。

トップ > 仕事 > ReactNative製AndroidアプリからさらにiOSアプリ実装が終わったのでKPTを行う

ReactNative製AndroidアプリからさらにiOSアプリ実装が終わったのでKPTを行う

仕事 技術 Snapmart

この記事はReact Native アドベントカレンダーの23 日目の記事です。

概要

SnapmartのAndroidアプリはReact Nativeで実装されています。
iOSアプリはSwiftで実装されているのですが、この度、React Nativeで置き換えることにしました。

手順は、まずAndroidアプリを作り、それからiOSアプリを置き換えることにしました。*1
今回は、ReactNative製AndroidアプリからさらにiOSアプリ実装が終わったので、そのKPTを行います。

Keep

動作しない部分の洗い出しと、修正が迅速に行えた

iOSのエミュレーターで動作させたときに、すぐに動いた訳ではないのですが、下記切り分けがスムーズだったので、滞りなく修正ができました。

  • AndroidOnlyのオプション使用
  • React Nativeが提供するコンポーネントのOS別の差分

Android Onlyのオプション使用

こちらは単純にAndroidしか動作しないオプションを使用していたため、iOSでは動作しないという問題でした。
今回頻繁した具体的な問題は、Text Input コンポーネントの複数行入力で使用するnumberOfLinesオプションです。 当初何の気なしにAndroid Onlyオプションを使っていた自分を呪いました。 OSによって実装を分けることはクロスプラットフォーム開発の利点を殺しかねないので、用法用量は適切に！

React Nativeが提供するコンポーネントのOS別の差分

動作確認を行なっていると、しばしば「Androidと微妙に挙動が違うよね？」というコンポーネントがありました。 最も差分があったのはPickerでした。

Androidでは、Pickerと選択後の値表示が一つのコンポーネントで完結するのですが、iOSでは、Pickerは単純に選択肢を表示するだけのコンポーネントでした。
そのため、iOSでは別途Textコンポーネントを用意し、onPressでPickerを発火させるといったことをしなければなりません。
問題の解は見えているのですが、腑に落ちない*2ため、react-native-picker-selectを使用することにしました。
(その他、小さい問題は、Textコンポーネントのstyleとして、borderColorが動作しないというものもありました。)

ほとんどが、上記2パターンで切り分けできたので、

  1. 不具合報告がある
  2. コンポーネントのオプションを調べる
  3. 2で問題ない場合、OS別の差分であると断定し、修正

という感じで、サクサク修正することができました。

Problem

動作確認の負担が重い

Snapmartアプリは比較的小規模なアプリであるとはいえ、手動テスト項目は250件にもなります。 これらをデバイス別(iPhone 6, 8, X)で行うため750件になります。 通常業務も行いながら、テストを実施をしているため、全て完了するのに、おおよそ1週間ほど必要になります。

負担は非常に大きいです。

Appleの審査になかなか通らなかった

いざ、Appleへ審査申請をしましたが、7度却下されました。 具体的な却下理由は下記の3点です。

  1. メタデータ(App Storeで使用する写真の解像度)が不適切(ガイドラインに沿っていない)
  2. ログインできない
  3. ボタンが動作しない(！)

1,2はしょうもないミスだったのですが、3の指摘で5度の却下と1ヵ月前後レビュアーさんとのやりとりや修正作業を行いました。

ボタンが動作しない指摘の修正

Appleの審査はiPadで行われ、*3最新のOS(この記事執筆時点では12.4)で動作させているようです。
また、最新のエミュレーターではOSが12.2までしか上げられませんでした。
さらには、Expo Clientアプリを経由したアプリの動作と、ビルドした.ipaファイルを実機にインストールしたものでは、若干挙動が異なりました。

そのため下記差分が重なり、不具合を特定するのに時間がかかってしまいました。

  • iPhoneとiPadの筐体の違い
  • OSのパッチバージョンの差分
  • .ipaファイルでの動作確認不足

また、これらは一見落ち着いて切り分けできているように見えますが、「Appleのレビュー担当者のミスなのでは？」「なぜiPadを使っているのか？」「もう一度ビルドしたら挙動が変わるかも？」といった、問題を直視せず、憶測で修正するといった愚行を重ねてしまいました。
まず、他人(Appleのレビューの方)が行なってくれたことは何一つ間違っていなかったことと、親切に受け答えしてくれたので、「自分はなんてことをしてしまったんだ...」という思いになりました。
それと同時に、未知の物に対する不安は判断精度を低くしてしまうことも自分なりの発見でした。

事実を基に落ち着いて判断。問題解決の鉄則ですね。

Try

Detoxを導入

今回のiOS実装だけではなく、Expo SDKのバージョンアップでも全体的な動作確認は行います。また、Expoのバージョンアップの頻度は非常に短いです。
規模が大き目のリリースのたびに、動作確認をメンバーにお願いするのは負担、効率、スピードなどを考慮すると、極力避けたいです。
また、動作確認に関しては、E2Eテストである程度自動化できます。
それを実現するのがDetoxです。

github.com

アプリの様々な機能のうち、主要機能から攻めていきたいと思います。

まとめ

React NativeでAndroidアプリを作成したのちに、iOSのReact Nativeチャレンジしましたが、Androidと同様の仕様で挙動させること自体は簡単でした。
自分の場合、初のApple審査申請で日和ってしまい、落ち着いて的確な判断ができなかったことが、遅延した原因です。
また、リリースサイクルの中で手動によるボトルネックが問題として認識できました。

*1:当初そもそもAndroidアプリがなかったため。

*2:OS別の処理は極力書きたくない

*3:iPadで提供する/しないに関わらず