はじめに

はじめまして。TISのインシュアランスサービス部およびデザイン＆エンジニアリング部に所属している瀧です。

私はモバイルアプリの新規開発プロジェクトに2年間従事し、数十万ユーザー規模のアプリをReact Nativeで開発・運用しました。

本記事では、実際の開発・運用を通じて得た「気づき・教訓」、そして私が開発を始める前に「これを知っておきたかった」と感じたことを共有します。

これからモバイルアプリの開発を始めようとしている方にとって、少しでも参考になれば幸いです。

1. スマートフォン固有の機能を活用する際は、あらかじめ最新の仕様をリサーチする

たとえば、モバイルアプリでプッシュ通知を利用する場合は、Androidの「通知チャンネル」機能について理解しておく必要があります。

この点を正しく把握していないと、通知の優先度やチャンネル名などの要件を見落としてしまう恐れがあります。

プッシュ通知やディープリンクといったスマホ固有の機能を活用する際は、事前に最新の仕様を確認し、理解しておくことが重要です。

Fintanで公開しているReact Nativeのサンプルアプリケーションにも、プッシュ通知機能の実装方式が記載されているので、ぜひ参考にしてみてください。

2. 強制アップデート機能を入れる

アプリは、端末がWi-Fiに接続している、バッテリー残量が十分である、自動アップデート設定がオンになっているなど、OSごとに定められた条件を満たしている場合にのみ自動的にアップデートされます。

さらに、App StoreやGoogle Playはアップデートの実行を制御するための「強制アップデート」機能を提供していないため、アップデートを確実に適用させることはストア側では制御できません。

そのため、致命的な不具合の修正やセキュリティ対応を確実にユーザーへ反映させるには、アプリ内で強制的にアップデートを促す仕組みを実装する必要があります。

プロジェクトでは、強制アプリアップデートで紹介されている実装方式を参考に実装しました。

3. 採用するサードパーティライブラリの Issue 状況を確認しておく

モバイルアプリを開発する場合、フレームワークで用意されているものだけでは実現できない機能を開発することがあります。

その際にはサードパーティ製のライブラリを利用することも検討しますが、ライブラリを選定した上で、そのライブラリのIssueを事前に確認し、既知の不具合や、その対応状況などを把握することで、後からトラブルに直面することを未然に防ぐことができます。

実際に私もリリース後に、サードパーティライブラリの既知の不具合に直面し、patch-packageでパッチを当てて対応せざるを得なくなった経験がありましたが、もし事前にIssueを確認していれば、こうした問題を事前に回避できたと痛感しました。

ユーザーから見れば、問題の原因がサードパーティライブラリにあろうとアプリ自体にあろうと、すべて「アプリの不具合」として認識されるため、ライブラリ選定には十分な責任を持つ必要があります。

今回の経験を通じて、ライブラリ選定時のリスク確認や事前調査の重要性を改めて認識しました。

ライブラリの選定については、サードパーティライブラリの導入の記事が参考になります。

4. ファーストビューに重要な情報を配置する

重要なボタンが、ユーザーが画面をスクロールしなければ見えない位置に配置されていることは、ユーザビリティの観点から大きな問題となります。

実際、プロジェクトのユーザビリティテストにおいても、重要なボタンが画面の下部にあるため、スクロールしないと気づけないという課題が指摘されました。

状況によってはコンテンツの高さを調整するなど、ユーザーがアプリを開いたときに最初に目にする「ファーストビュー」に重要な情報を配置するようにしましょう。

アカウント追加ボタンがファーストビューに表示されないレイアウト（左）と、表示されるレイアウト（右）

5. 特定のUI要素に注意する

  • スクロール
    ページに表示されるコンテンツ量に応じて、ユーザーが快適に操作できるスクロールのスピードや慣性になっているか注意しましょう。
    また、ネイティブ画面と WebView 画面を比較し、スクロール時の操作感に違和感がないかも確認することが重要です。
    プロジェクトのユーザビリティテストでは、特定の画面でスクロールの慣性に違和感があるという報告がありました。
    原因を調べたところ、react-native-webviewを使用してWebView を表示していた際に、スクロールの減速率（decelerationRate）のデフォルト設定が高めに設定されていたことが原因であると判明しました。
  • ローディングインジケーター
    処理速度の遅い端末や通信環境の悪い場所では、ページの読み込みに時間がかかることがあります。こうした場面では、待機中であることが明確に伝わるようにローディングインジケーターなどを適切に表示することが重要です。
    実際のテストフェーズでも、APIのレスポンスが想定より時間がかかることに気づき、ローディングインジケーターの表示が不十分だと分かりました。

  • In-App Browserのテキストボックス

    iOS（Safari）では、入力フォームの文字サイズが16px未満の場合に自動的にズームしたり、フォームに青色の枠線を表示するなど、アクセシビリティやユーザビリティを向上させるための機能があります。

    これらの挙動が発生したときに違和感のないデザインとなっているかを、注意する必要があります。

    通常のテキストボックス（左）と、Safari独自の枠線が表示され、枠線が二重になったテキストボックス（右）

6. プラットフォームの差異に注意する

React Nativeでは、１つのプログラムでAndroid、iOS両端末で動くのが大きなメリットですが、AndroidとiOSのプラットフォーム間で挙動の違いがたくさんあります。

プロジェクトで実際に経験した点をいくつか挙げますが、開発時は注意が必要です。

モーダル

iOSではReact NativeのModalを同時に2つ表示できません。

例えば、エラー発生時にモーダルを表示する場合は、同時に複数のエラーが発生しても、複数のモーダルが同時に表示されないよう制御する必要があります。

読み上げ機能

AndroidのTalkBackとiOSのVoiceOverについては、テキストや素材の読み上げ方が異なります（そもそも読み上げが行われない場合もあります）。

そのため、アクセシビリティ要件として読み上げ機能に対応する際は、TalkBackとVoiceOverの両方で実際に動作を確認し、許容できる読み上げ内容になっているかを検証する必要があります。

アンインストール時に端末に保存されたアプリデータの扱い

アプリをアンインストールした時の端末に保存されたアプリデータの扱いですが、KeyStore/KeyChain領域に保存したデータの扱いには以下の違いがあります。

Android：削除される
iOS：削除されない

そのため、expo-secure-storeなどを使用してこれらのデータ領域を利用している場合は、挙動の違いに注意が必要です。

アプリのライフサイクル

AndroidとiOSには、アプリのライフサイクル管理の違いがあります。

この知識は普段の機能開発では意識しないかもしれませんが、不具合調査やテストの際に役立ちました。

実際、以下のような不具合対応の際に、ライフサイクルに関する知識を原因の特定や対応方針の検討に役立てることができました。

具体的には、AndroidでアプリのIn-App Browser（認証用Web画面）を開いたままアプリをバックグラウンドにし、再度アプリアイコンをタップしてフォアグラウンドに戻した際にエラーが発生する、という障害がありました。

一方で、Appスイッチャー（ホームボタン2回押しで表示されるタスク一覧）からの再起動では問題は発生しませんでした。

このような症状を前にしたとき、「ライフサイクルの状態遷移による処理の違いが原因ではないか」と仮説を立てて調査を進めることができました。

もしライフサイクルの仕組みを知らなければ、どこから手を付けてよいか分からず、原因特定にさらに時間がかかっていたと思います。

このように、アプリのライフサイクルへの理解があることで、思いがけない不具合が発生した場合のヒントになります。

アプリのライフサイクル管理の記事にライフサイクルに関する説明がありますので、目を通しておくことをお勧めします。

ライブラリの挙動

OSや環境によっては、ライブラリの挙動に微妙な違いが生じることがあります。

実際に私たちのプロジェクトでも、ライブラリの仕様を十分に理解していなかったため、Androidで一部の機能が期待通りに動作せず、後から代替手段を検討せざるを得ない場面がありました。

こうした問題は、公式ドキュメントを丁寧に読むことで、事前に仕様や制限、プラットフォームごとの違いに気づける場合があります。

トラブルを未然に防ぐためにも、ライブラリのドキュメントには一通り目を通し、挙動や制約を事前に把握しておくことが重要です。

7. モバイルアプリならではのテスト観点を網羅する

「ダークモード」や「横向き画面」、「キーボードの制御」、「フォントサイズ変更」など、モバイルアプリならではのテスト観点がたくさんあります。

Fintanのテスト種別＆テスト観点カタログでは、このようなモバイルアプリならではの観点が網羅的に整理されています。

プロジェクトでも、テスト観点漏れの対策としてこのカタログを活用しました。

8. モンキーテストをする

ユーザー目線で様々な操作パターンを試すモンキーテストは、必ず実機で積極的に実施することを推奨します。

実機によるモンキーテストでは、エミュレーターでは再現しにくい端末固有の挙動や、UX上の問題を発見することができました。

9. ビルドパイプラインとプログラムを定期的にメンテナンスする

モバイルアプリの継続的な配信を円滑に行うためには、ビルドパイプラインやプログラムの定期的なメンテナンスが欠かせません。

実際、プロジェクトで不具合修正をリリースしようとした際、ビルドパイプラインで使用しているXcodeのバージョンが古かったためにエラーが発生し、スムーズにリリースできなかった経験がありました。

この出来事から、OSやストアのポリシー、SDKバージョンのアップデートへの追従が不十分だと、いざという時に迅速な対応が難しくなることを実感しました。

Androidアプリの場合

Google Playの要件では、targetSdkVersionを毎年更新することが求められています。新しいAPIレベルがリリースされた後、一定期間内にそのAPIレベルに対応したtargetSdkVersionを適用しないと、新規アプリの公開や既存アプリの更新が制限されます。

iOSアプリの場合

App Storeでは、Appleが指定する最新のXcodeおよびiOS SDKでビルドしたアプリの提出が、一定の猶予期間後に必須となります。これは、年次のiOSリリースに合わせて定期的に行われています。

そこで、私のチームでは、ビルドパイプラインとストアへのアップロード作業を定期的に実施する対策を講じました。これにより、ストアの仕様変更やSDK更新によるビルドエラーや警告を早期に発見し、問題発生時にも迅速に対応できるようになりました。

ただし、こうした対応は問題発生後の対処に過ぎません。OSのリリーススケジュールや開発ツールのアップデート情報を事前に把握し、年間の開発計画に組み込むことも同様に重要です。

10. 証明書の更新を定期的にする

iOSアプリの開発・運用では、署名に使用する証明書やプロビジョニングプロファイルの有効期限（通常1年間）に注意してください。

これらは有効期限を過ぎると、新しいビルドやApp Storeへの配信ができなくなります。

そのため、証明書やプロビジョニングプロファイルの有効期限を事前に把握し、期限切れ前に更新作業を行う運用フローの整備を推奨します。

とくに運用担当者が交代した場合など、更新漏れが発生しやすいので、定期的なチェックリストやリマインダーの設定を検討しましょう。

まとめ

今回の記事では、React Nativeでのモバイルアプリ開発において、私が経験から得た「気づき・教訓」や「知っておきたかったこと」を共有しました。

要件定義から設計、実装、テスト、そして運用に至るまで、モバイルアプリ開発ならではの注意点が多く存在します。

これらの情報が、これからモバイルアプリ開発に携わる方々にとって、少しでも開発のヒントや効率化に役立つことを願っています。