初めまして！食べログシステム本部アプリ開発部でiOSアプリの開発を担当している横川です。
食べログには今年の4月から入社しており、まだ日は浅いですが、毎日楽しく仕事をしています。
今回は先日開催されたiOSDCの2日目（day1）について、気になったセッションや会場の様子などをお届けできればと思います。
過去記事：
iOSDC Japan 2023にゴールドスポンサーとして協賛します！
iOSDC Japan 2023 参加レポート#1 day0のまとめ
目次
気になったセッション
小さなバグが生んだ悲劇、そこから学ぶ耐障害性の高いアプリ設計
発表者はGO株式会社の今入さんで、小さなバグから発生した障害とその対処に関する発表です。
タクシーアプリGOで実際に起きたバグによって、iOSアプリ起動後に通常の数百倍のリクエストが発生し、ローディング状態が続いてサービスが提供できなくなったという内容でした。
ゾッとする障害ですね、、
この障害で対応したことは大きく分けて、下記2つとのことです。
- メンテナンスモードへの切り替え
- バグを修正して、AppStoreConnectへ特急申請し、リリース
ただし、それぞれについて対応時に問題がありました。
まず、メンテナンスモードへの切り替えがうまくいかなかったとのこと。
切り替えがうまくいかなかった原因は、APIに依存した設計になっており、メンテナンス状態かどうかをAPI経由で取得していたため、通常の数百倍のリクエストが発生していることで、サーバやDBの負荷が高まっており、APIのレスポンスが返ってこない状態になってしまっていたことです。
そのため、ユーザーは通信中のままで何が起こっているのか把握できない状態でした。
次に、バグを修正したバージョンをリリースした後のユーザへの利用浸透に時間を要したことです。
当時のアプリには強制アップデート機能がなかったようで、修正版のアプリに更新してくれるのをただただ祈るのみだったとのことです。
これらの課題に対して再発防止策として、Google Cloud StorageにJSONファイルを配置し、それを取得してメンテナンスモードかを判断するようにしたり、強制アップデート機能を追加したりしたようです。
そもそものバグがリリースされた原因としては、
- コードレビューで指摘されていたが、修正されないままマージされてしまった。
- 現状のQAメンバーの規模では、サーバへの負荷にはならなかった。
- API通信の回数確認までは行っていなかった。
- シミュレータでは再現しにくいバグであった。
などがあげられていました。
この発表を聞いて、QAでは規模に依存する障害は見落としがちになるため、API通信が増加するような案件では、細心の注意を払って開発をする必要があるなと改めて感じました。
因みに、食べログでも店舗トップなどの主要な画面は月に1億回以上アクセスされるため、画面で使う情報が追加される場合はあえてAPIを分け、必要な時だけ追加項目を取得するようにしたりと、APIの追加や改修では負荷を意識した設計をしています。また、このような画面のAPIは日々レスポンスをウォッチしていたりもします。
GOアプリではAPI通信の回数が確認できるようなデバックモードの機能を追加して、今は運用しているとのことですが、対応前後の比較をするには良い機能だなと思います。
また、余談ですが、day2のLTでGO株式会社の久利さんが発表されていたアプリの終活 〜その後〜では、JapanTaxiアプリの強制アップデート機能でクラッシュが発生していたとのお話があり、普段使わないような機能が期待した動きをするかなどは定期的に確認する必要があるなーと。
いざという時に使えないと意味ないですからね、、
UIのブラックボックスを探る
発表者は株式会社ディー・エヌ・エーのnoppeさんで、暗黙の仕様となっているAppleの標準UIから仕様を発掘するリバースエンジニアリングの基礎知識などについての発表でした。
多くの場合、開発者の作成するカスタムUIはApple製のUIと比較して品質が悪くなりがちであり、その理由はシステムのお作法を無視してしまうからとのことです。
では、システムのお作法をどのように知るのかというと、以下が挙げられていました。
- Human Interface Guidelines(以下、「HIG」という)を確認する。
- システムコンポーネントを分析する。
※システムコンポーネントとはApple製のアプリやUIKitやSwiftUIのコンポーネントのこと
ここで2のシステムコンポーネントの分析ですが、ビジュアルを分析する方法として、アプリ内部でサーバを立ち上げて、View階層を送るようにするRevealとアプリの起動中に外からRevelServerをloadするために汎用的なリサーチツールであるFridaを利用した方法を解説していました。
※Fridaの利用にはroot権限を持つiPhoneが必要ですが、たまたま手元にあったそうな笑
この方法でApple製のアプリがどのようなView階層なのかなどを確認できるため、アプリ開発の際の参考にすることが可能になります。
インタラクションについては、大事なこととして、「自分にとっての当たり前ではなく、ユーザーにとっての当たり前を実装する」ということが挙げられていました。
参考にするUIを触り、どのようなインタラクションが設定されているのかを確認することが必要になってきます。
見逃しがちな箇所などが発表の中でいくつか紹介されていたため、下記に記載します。
- ジェスチャー
- 補助ジェスチャー
本来の目的に対して補助的なジェスチャーを提供するもの。UIスイッチのパンでの切り替えなど - 不可視トリガー
見た目からは読み解けないもの。シェイク、マルチタップ、3Dタッチなど - 閾値
実際の見た目よりもズレた位置に判定があるもの。キーボードのボタンタッチなど
- 補助ジェスチャー
- 外部デバイスからの入力
- ハードウェアキーボード
- ポインターデバイス
- フィードバック
- ビジュアルフィードバック
- サウンド
※ipaの中にサウンドファイルがあるため、そこから分析可能 - ハプティクス
- ボイスオーバー
また、カスタムUIを作る上でのヒントとして、安易にAppleのUIの真似をせずに参考にしたUIの設計思想を把握することや、UIKitに既にあるものを再実装しないこと、デザインの追従コストを考慮することなどについて共有されていました。
まとめとして、カスタムUIは品質が落ちることを前提とし、トレードオフを意識して無駄にカスタムUIを作らないことがコツ。アプリのコアバリューに絞って実装してみては？とのお話がありました。
この発表を聞いて、普段食べログアプリの開発を行う際は、デザイナーさんとやりとりをしながらUI周りの仕様を決めていくのですが、HIGは意識しつつ、Appleの純正アプリではどのような見た目、インタラクションになっているのだろうと確認することも大事だなと感じました。
要件を決めていく中で、本当にカスタムUIで実装する必要はあるのか？それは標準のUIでは本当に実現できないものなのか？などを考えながら、トレードオフを意識して、今後のアプリ開発に取り組んでいこうと思います。
ルーキーズLT大会
day1ではTrackA,BでルーキーズLTが行われていました。
ルーキーズLTとは、初めてiOSDC Japanで発表するスピーカーによるLT会で、「ルーキーズLT練習会」というものに参加し、歴戦のスピーカーによるアドバイスを受けてから登壇するもののようです。
私はTrackAの会場に行き、会場の入口でペンライトが渡され、最初は何に使うのだろうと思っていましたが、残り時間が僅かになったら振ることで発表者に時間を知らせるとのことでした笑。
ペンライトの色は発表者の推しの色を設定することになっており、ニコニコ生放送のコメントも指定された色でみなさん投稿しており、おもしろい取り組みだなあと感心。
ルーキーズLTでは今年新卒の方も登壇されており、とても元気で勢いのある発表が多かったです。
中には130枚のスライドを5分間で発表するという猛者も、、
ニコ生とオフライン会場どちらも大いに盛り上がっていました。
因みにLTでは時間切れになると銅鑼の音が鳴るようになっていたのですが、TrackAでは時間切れで鳴ることはありませんでしたね。みなさん優秀。
今後の食べログで活かせそうなこと
GOアプリのデバックモードでのAPI通信回数の可視化などは、見えないバグの気づきとしてとても良い機能だなと思いました。
普段、APIが増加するような案件などでは、コンソール上でAPIの確認をしているのですが、デバックモードでの確認は実機単体でも確認できるため、作業効率がアップしそうです。
また、UI関連のことについて、これまでHIGの内容を意識したことはありましたが、AppleのUIなどを分析したりすることで、システムのお作法についての理解をもっと深めて、食べログアプリの改善に繋げていけたらと思います。
まとめ
iOSDCに参加するのは初めてでしたが、非常に多くの学びがあり、また楽しいカンファレンスでした！
ApplePayやPush通知、マクロの話など幅広い分野の話が聞けてとても良い勉強になりました。今回オフラインでは聞けなかったセッションも動画で見てみようと思います。
明日はday2の記事が公開予定のため、そちらもぜひご覧いただけたらと思います。
食べログではエンジニアを募集しています！気になった方は是非下記の採用情報ページをチェックしてみて下さい！
それでは、最後まで読んでいただきありがとうございました。
