iOSDC Japan 2023に参加してきました

2023年9月25日 18:16

はじめに

家の中で運動する環境を作ることにハマっているかむいです。

一昨年と昨年に引き続き、今年もiOSDC Japan 2023(以降: iOSDC)に参加して来ました。今年は懇親会も再開され、久々にオフライン会場でお酒や食べ物を片手に開発者同士で談笑が出来る環境が戻って来ました🍻

REALITYは昨年に引き続きスポンサーとして協賛し、参加者に配布されたカタログ内に企業紹介を掲載させて頂きました。
自分も今回はデザイン制作に携わり、無事カタログに掲載されたのを確認した時は心が躍りました。

残念ながら自分はオンラインのみの参加となりましたが、今年も参加したセッションについて感想をまとめていこうと思います！

UIのブラックボックスを探る

Pocochaのnoppeさんのセッション。カスタムUIを作る際にはデザイン追従コストとiOSのお作法に慣れているユーザーが離れるリスクがあり、前者はOSのアップデートで陳腐化する可能性が、後者はスクロールの慣性やアクセシビリティ等がシステムUIと異なると発生することなどを説明してくれました。

カスタムUI(特にカスタムナビゲーションバー)を作る話はすごく共感でき、トレードオフを意識して、無駄にカスタムUIを作らない(システムUIに重きを置く)のがコツというのはごもっともだなと感じました。

まずUI品質の理想値であるシステムUIのお作法を分析して解析する必要があります。お作法全てがブラックボックスになっているわけではなく、基本的なものはHuman Interface Guidelinesにまとまっているのでそこから学ぶと良いとのこと。
また他サービスのUIを真似ても明確に設計思想や意図を汲み取ることは難しく、ユーザーが理解できるのかの視点が大事だと説明していました。

発表後のQ&Aでは、歴史がある or 大規模な開発だとシステムUIとカスタムUIの線引きが難しいという話がありました。カスタムUIを止めるというケースでは、影響範囲が広いこもあるので、できるとこから地道に対応していくしかなく、カスタムUIを取り入れたいというケースでは、純正だとユーザーに価値が届けられないが故の選択ではあるが、届けたいユーザーに対して失われるアクセシビリティ、離れるユーザーとを考慮した上での議論が必要ということを上げていました。

Swift Packageを使った巨大な依存グラフのキャッシュ戦略

LINEのgiginetさんのセッション。これまでビルドの高速化のために活用していたBazelの利用を徐々に減らし、Swift Packageを使った標準の仕組みに置き換えをしているというお話でした。その中でビルド済のSwift Packageをキャッシュし再配布する仕組みとしてScipioというライブラリを作成し、その使い方を合わせて紹介していました。

LINEほどの巨大なプロジェクトだと恩恵が大きい部分を、どこまで弊プロダクトでも活用できるかという視点で見てましたが、後述するビルド済Frameworkをリモート環境に置き、そこから開発メンバーが取得しに行く仕組みは良いなと感じました。

LINEは以前より大規模プロジェクトとしてのビルド環境のケーススタディをアウトプットしており、昨年はBazel導入を紹介したビルド変遷についてiOSDCでも発表していました。しかし最近はメンテコストの方が比重として勝り、ビルド環境がメンテされず負債化していました。またApple Siliconの登場でメリットが限定的になっていたと説明していました。詳細は社内ブログにもまとめられています。

そこで標準のビルドシステムを使い、膨大なビルドシステムを自分たちで管理しなくて済む開発環境を目指したけれど、LINEの規模感とプロジェクト構成の都合上、Derived Dataに保存するのは成果物が揮発しやすく、アプリケーションと依存関係のビルド成果物を分けて扱うことが難しいという課題がありました。そこで新たにビルド成果物をキャッシュし、再配布しやすい形に変換するためのツールとしてScipioを作成されたとのこと。

これはSwiftPMを利用しXCFrameworkを生成するビルドツールで、Swift Packageを再配布可能な形に変換するためにライブラリとして用意したとのことです。機能としてはCarthagoに似ていますが、xcodeprojファイルをプロジェクト側が設置する必要がある問題があるのに対し、Scipioはその点を克服している、まさに名将の名前の由来通りの機能と言えますね。

Scipioの利点はSwiftPM + Xcodeベースで作られているためSwiftPMがメンテされる限り大きく変更はされづらく(壊れづらく)、依存がSwift Packageなので通常利用で問題なければ通常の統合方法に戻せる(辞めやすい)という点を上げていました。辞めやすさはどの新しい仕組みを入れたとしても重要になるポイントですね。

最後にLINEでこのビルドシステムを活用した際の話について、段階的に導入を進めており効果として導入前に比べPrebuildタスクがキャッシュありの状態で3.5倍早くなり、合計時間もキャッシュありの状態で1.75倍早くなる効果が出たそうです。また、CIの仕組みの中でもScipioを使い、キャッシュを開発者間で共有できる仕組みを使い、Frameworkのビルドを不要にできたことを説明していました。

こういうのは標準APIいいよね

LIFTる。の庄司さんのセッション。多くの3rd Party製ライブラリに依存していた部分について、どのように削除対象を決め、削除を進め、逆に何を残したのか、そこから見えてきた生き残るライブラリの共通点や、今後の導入チェックポイントについてをお話していました。
弊社でも同じ取り組みを進めているので、チーム内で共通認識としてこうした内容を言語化するのは良い取り組みだなと思いました。

これらを実施する理由として、関心ごとや悩み事の対象となり、何らかのアップデートが入ったとしても、放置するとキャッチアップコストが上がったりOSのアップデートについていけなくなることを説明していました。

残す or 新たに選定するライブラリのポイントとして、呼び出し箇所を小さくまとめられているか、要件に対して大きすぎないか、標準APIに無い仕組みか、将来置き換えがしやすいかといった点を上げていました。

取り組んだ結果として、実装のバラつきがなくなり、メンテナンス性は向上できたとのこと。また副次効果として、Dynamic Libraryを減らせたことでアプリ起動時間を約40%短縮出来、アプリサイズを約70%小さくできたとのことです。

また最後に不可逆なパラダイムシフト（Objective-CからSwiftといった劇的な進化など）として、アプリの寿命はパラダイムシフトよりも長く、今イケているコードもいずれ陳腐化することを指摘していました。同じくアプリの寿命はエンジニアの寿命（在籍期間）よりも長く、引き継いだエンジニアのパフォーマンスを下げることもありうるため、いつでも置き換えがしやすいようにテストやドキュメントの充足化は大事だと話していました。

Mastering SwiftSyntax

岸川さんのセッション。Swiftマクロの登場により、今後さらに学んでいく必要があるSwiftSyntaxについて、概要からAPIの紹介、SwiftLintの既存ルールをSwiftSyntaxで置き換えるなど実践的な紹介をしてくれました。

以前弊社ではSwiftLintのカスタムルールを使い、正規表現を用いて[weak self]漏れを検出するという仕組みを作ったのですが、それもSwiftSyntaxで置き換えが可能だと思っているので今回のセッションから学びを得て実現したいと思いました。

SwiftSyntaxを学ぶにあたり、岸川さんが開発されたWeb上でソースコードの任意の箇所がどのSyntaxTreeの構造部分に対応しているかをグラフィックに表示してくれるSwift AST Explorerの紹介がありました。とても便利なツールだったので活用していきたいと思いました。

ソースコードを文字列として探索, 置換する仕組みであれば上記の取り組みのように正規表現でシンプルに書けるケースもあります。しかしコードの合間にコメントがあり、検索したいテキストがそこにも記述されていると処理が複雑になります。SwiftSyntaxではコメントや空白といったノイズを除去する仕組みがあり、ソースコードの実行に関係のないテキストはTriviaという特別なノードとして扱われます。これらのテキストを除去してシンプルに探索, 置換できる仕組みが提供されているのは大きな特徴だなと感じました。

SwiftSyntaxのAPIの章では、操作するためのAPIとして全体を辿る処理を任せるSyntaxVisitorと、別のノードに置き換える仕組みも合わせ持つSyntaxWriterの2つがあることをまず紹介していました。

その中でSwiftSyntaxのParserについて、文法エラーがあったとしても自動的に辻褄が合うようにソースコードを修正して構文解析を続行する仕組みがあるとのことで、その優秀さに驚きました。ただSwiftマクロではコンパイラの型チェックまで完了した後で文法エラーになるSyntaxTreeは渡ってこないので、不完全な文法エラーを含むSyntax Treeの扱いをどうするか考慮が必要とのことでした（エラーについてはhasErrorプロパティを使うことでわかる）

Swift AST Explorerにもこの仕組みが入っており、別言語のソースコードやめちゃくちゃな文法を入れてみることで確認ができます。

またコンパイラがSwiftマクロを展開する際には、自動的にSwiftSyntaxを整形してくれる機能が備わっている(SwiftBasicFomatの仕組みを利用)ため、基本的に自分でTriviaを挿入することを気しなくて良いことも挙げていました。これらの恩恵を得られてた上で、Swiftマクロに取り組めるのは嬉しいですね。

最後にSwiftSyntaxをマスターするには手を動かして慣れるだけなので、Swift AST Explorerを活用する他、SwiftLintのルールをSwiftSyntaxを使って書き換えるなども良い練習方法だと述べられていました。以下は上から順に取り組みが簡単なものからマスターするための取り組みを列挙してくれています。

複雑さに立ち向かうコードリーディング

shizさんのセッション。医療業界に勤めていた時の知見をコードリーディングに活用するお話しでした。認知プロセスを初めて知りましたが、これを妨げない取り組みを開発に活かすアプローチが新鮮で面白かったです。

人が複雑さを感じる要因として認知プロセスの低下が上げられ、認知プロセスの分類ごとに対策を紹介してくれました。

例えば一時的に記憶を保持する短期記憶では、記憶する容量に限界が起きることを取り上げ、限界を防ぐためにチャンク化と長期記憶へのインプットを対策に上げていました。前者は人間が一度に情報を処理できる単位をグルーピングし、振り返ることで物事を覚えやすくするものでした。後者は短期記憶に負荷が高まるのを回避すべく長期記憶を活用し、その際のポイントとして似た記憶同士を紐づけるスキーマや定期的に情報に触れることなどを話されていました。

また認知プロセスの活用につながる汎用的な対策として文章読解の7つの習慣を取り上げ、感覚記憶を活用し集中できる環境作りを行うなども良いことを話されており、普段我々が無意識に取り組んでいることが、実はこうした観点から実践できていることを感じ取れて面白かったです。

おわりに

今年は社内でiOSDC共有会を実施し、各々が見たセッションの概要を説明しながらメンバー間で発表内容と感想を共有し合う時間をとりました。おかげで見逃していたセッションの知見も得て、改めて資料やセッションのタイムシフトを見返そうと思えたので良い共有の場だと感じました。

『ブログを書いてシェアするまでがiOSDC』がiOSDCの謳い文句ですが、今年もそれに応えるべく3年連続で感想を書きまとめることができました。

普段の業務でも「あれiOSDCのセッションで話されていたな…」と思い返すことがあり、それが長期記憶として残っているのも、こうしたアウトプットによる恩恵だと思っています。

来年もまた参加し、あわよくばCfPが採択され登壇し、ブログ投稿もセットで臨みたいと思いました。