TL;DR
- Flutterでモバイルアプリをリリースした。
- 不具合が多数出て、解消に時間がかかった。
- とはいえ、ナレッジがない中でも短期間でリリースできた。
はじめに
こんにちは。レバテックダイレクト開発チームの城井です。
入社以来、ずっとモバイルアプリの開発に携わってきました。
今回は、レバテックで初めてリリースしたレバテックダイレクトのアプリ開発をどのように進めたかについて、その概要をお話しします。
どんなアプリ？
レバテックダイレクト（以下LTD）は、IT専門職特化のスカウトメディアです。
求人検索機能を用いて職種やスキル等の細かな希望条件に合わせて求人の検索ができたり、優良企業やエージェントから「スカウト」が届いたりします。
モバイルアプリという新たな形で、Push通知やアクション時間短縮等によるユーザビリティ・エンゲージメント向上を図り、より手軽で効率的な転職サポートの実現を目的としております。
スケジュール
大まかなスケジュールは以下の通りです。
| トピック | |
|---|---|
| 2023年 7月 | プロジェクト始動/基盤実装 |
| 2023年 10月 | テスト/不具合修正 |
| 2023年 12月 | 審査提出 |
| 2024年 1月 | リリース |
プロジェクトが始動してから約半年でリリースに至りました。
主なプロジェクトメンバーはPM1名、モバイルアプリエンジニア3名、バックエンドエンジニア1名、デザイナー1名、マーケター1名という編成でした。
この期間を大きく3つに分け、各フェーズで行ったことや遭遇した困難などを時系列に沿ってご紹介します。
1.プロジェクト始動/基盤実装
期間：2023年7~10月
技術選定
プロジェクトの最初に技術スタックの選定を行いました。
以下の理由からFlutter×WebViewで開発をしていくことになりました。
- iOSとAndroidの両OSに対してクロスプラットフォーム開発が可能
- 2023年内のリリースが目標
- リリース後の保守運用が容易
これにより、フルネイティブで開発するよりも素早いリリースが可能になったと思います。
しかし、WebViewは常にインターネットに接続して利用する機能であるため、端末のスペックや通信環境に依存しやすく、動作が遅くなることがあるというデメリットもあります。
これについては現状も課題として残っているため、必要に応じてネイティブへのリプレイスやパフォーマンス改善を図っていく必要があると考えています。
画面構成
また、WebViewを使用することが決まった事で、既存のWebページをどのような画面で表示させるかを決める必要がありました。
LTDでは、
- ハンバーガー付きヘッダー＋ボトムバー
- ヘッダー・ボトムバーなし
- タイトルヘッダー・閉じるボタン
の3パターンで全ての画面が構成されています。
実装においては、パターン間の遷移処理や制御に多くの時間を費やしました。
検索画面からの遷移図。分岐が多くて複雑です...
この期間での主な取り組み
-
画面実装の調整
- 新規登録・ログイン画面
- ログイン後のWebView表示画面
- お知らせページなど
-
機能実装
- ローディング
- スケルトンアニメーション
- 連打防止など
-
基盤
- APIリクエスト
- Push通知
- ディープリンクなど
-
システムタスク
- fastlane
- 環境毎のデプロイ自動化
- 証明書とプロファイルの作成など
-
WebView側
- カスタムURLスキーム
- スマートバナー
- API追加など
2.テスト/不具合修正
期間：2023年10~12月
一通り画面や基盤を実装した後、実装者を中心としたプロジェクト関係者でテストを行いました。
しかし、テストで不具合が立て続けに見つかり、修正に追われる日々が続きました。
テストまで不具合が見つからなかった最大の原因は、実機での動作確認をする機会が少なかった事です。
それまではエミュレータを使っての確認が主だったこと、実機でもiOSとAndroid両方で確認する機会が少なかったことから、実機や特定のOSのみで発生する不具合を検知しきれていませんでした。
例
- 遷移先の画面が真っ白になる
- 特定の画面へ遷移するとエラーになる
- OS間で挙動が異なる
- 写真を撮ろうとするとクラッシュする(iOSのみ)
- ファイルアップロードができない(Androidのみ)
これらはエミュレータだけでは検知できない、実機特有の不具合ばかりでした。
実装当初から実機テストを行うフローが確立していれば、より早くリリースできたかなと思っております。
3.審査提出/Reject対応
期間：2023年12月
審査提出に備えたアプリ配布の自動化
不具合の改修が終わりテストも完了した後、審査提出へ向けた作業を行いました。
審査の提出に伴い、ビルドからipaファイル(iPhoneやiPadで用いられる、アプリケーション配布用のファイル)やaabファイル(Androidアプリを公開するために必要なファイル)のアップロードまではワークフローで自動化し、スクリーンショットや説明文等は管理画面から手動で設定しました。
全体作業の一部を自動化することで、一連の作業で人的ミスの発生確率や手間を減らすことができました。
本番デプロイの構成図。
また、環境別の配布手順を覚えて都度手動実行する必要がないという利点もあります。
弊社では、Firebase App Distributionを使用してテストアプリを配布しているのですが、これらも自動化しているため、開発者はベースブランチの管理とトリガーとなるアクションをするだけという状態が実現できています。
審査でのFB
審査提出後、Appleからガイドラインに沿っていないなどの理由で3点FBをいただきました。
(新規登録・ログイン部分でpoor user experienceという指摘を受けたのは少し凹みました。。笑)
新規登録・ログインに関してはダイナミックリンクを使用して外部ブラウザからアプリにリダイレクトさせたり、アプリ内でWebViewを開きカスタムURLスキームを利用して認証させる仕組みを作るなど、二転三転しながら現在の実装に至りました。
修正を加えた後再度審査提出し、無事公開まで辿り着きました。
まとめ
今回は、モバイルアプリ開発の経験がほぼない組織がリリースを達成するまでの過程をまとめました。
これからモバイルアプリ開発に新規で取り組む方々にとって何か少しでも参考になる箇所があれば幸いです。
少しでもアプリに興味が出た方は、以下リンクからDLしてください！
ご意見、ご感想等もレビューにてお待ちしております！！
▼iOS版
▼Android版
また、もしFlutterを用いたモバイルアプリ開発に興味がある方がいらっしゃいましたら、一緒に働きましょう！！！！
Discussion