こんにちは。株式会社PREVENTでiOSエンジニアをしている佐藤です。
先日try! Swift Tokyo 2025というSwift言語に関する国際技術カンファレンスに参加してきました。
この記事では、このイベントに参加して特に印象に残ったセッションについて紹介します。
iOS 17, 16, 15などの新機能
このセッションでは、iOS15〜17で登場した便利なAPIを紹介してもらえるというものでした。
iOS15から使えるAPIでさえ知らないAPIがあったので、まだまだ知らないことが多いなと大変勉強になりました。
またこんな便利なAPIあったの！？と感動を覚えたセッションでもありました。
例えば、Date型を簡単にString型に変換できるformatted(date:time:)やformatted(_:)というAPIがiOS15から使えるようになっていたようです。
Date→String変換がDateFormatterを用いた従来の方法よりもかなりすっきりとした書き方ができるようになりました。
この手の処理の実装はよく遭遇するので、業務でも大活躍しそうですね。
また、iOS16から使えるUIHostingConfigurationの紹介も印象的でした。
UIKitでSwiftUIを使用するにはUIHostingControllerを使うしかないと思っていましたが、UIHostingConfigurationを用いる別の方法が用意されていました。
UIHostingConfigurationはイニシャライザのクロージャで直接SwiftUIでUIを組めるので書き方も非常に簡潔かつ直感的になりました。
現状UICollectionViewCell or UITableViewCellのUIをSwiftUIで実装したい時に使えるようなので、その場合には積極的に使用していきたいですね。
ここでは紹介しきれませんが、そのほかにも様々な便利APIの紹介がありました。
マイナーだけど便利！みたいなAPIが多かったので、きっと私と同じく感動される方が多いのではないかなと思いますので、興味があればぜひセッションの動画を見てみてください！
SwiftUI を最適化するためのレンダーループの理解
このセッションでは、SwiftUIでアニメーションするときのプロセスであるレンダーループの仕組みを解説されていました。
アニメーションは以下3つのフェーズが繰り返されることで実現されているようです。
- Appでの処理(アプリのメインスレッドで行われる処理)
- Render serverでの処理(画面描画を行うアプリとは別のプロセスが行う処理)
- ディスプレイの更新処理というが繰り返されることで実現されているようです。
※公式ドキュメントより引用
これらのフェーズのどこかで時間がかかりすぎることで、画面の更新がフレーム単位で遅れてしまうとアニメーションがカクっとする、いわゆるhitchが発生します。
以下の図ではAppでの処理が1フレームに収まり切らずRender serverでの処理が次のフレームで開始出来なかったので、その分画面の更新が遅れることになりhitchが発生します。
※公式ドキュメントより引用
こうしたパフォーマンスのボトルネックになりうるフェーズは、Appでの処理のほか、Render serverでの処理もあるようで、こういった知識があると、UIのパフォーマンスの問題に直面した時に修正箇所の特定に役立ちそうと思いました。
どのフェースがボトルネックになっているかは、Animation HitchesというXcodeのinstrumentsを使って確認できるようです。
こちらはセッションには出てこない内容で、以下WWDCのビデオで言及されていました。
以下ドキュメントでもレンダーループの仕組みについて、詳しく解説されていてセッションの動画と合わせて見てみると、より理解が進みましたので、興味のある方は是非ご参照ください。
モジュラーなデータパイプライン設計
DataSource（データ層）、Translate（データ変換層）、Consumer（Presentation 層）というように、役割ごとにモジュールを分けた設計を解説するという内容でした。
上記のようにモジュールを分けることで、一般的には以下のようなメリットがあると思います。
- それぞれの責任ごとに分割することで、可読性が上がりかつ不要な依存が減り変更に強い設計になる
- 依存の向きをDataSource->Translate->Consumerとしておくことで、DataSourceといった下位のコンポーネントの修正が容易になりかつ上位のコンポーネントには影響を及ぼさない安全で拡張性の高い設計になる。
- DataSourceは取り替え可能なので、ユニットテストでは容易にモックすることができてテスタビリティが高い設計になる。
このセッションで紹介されていたこととして、さらにDataSourceをモックすることで開発体験を向上させるアプローチがありました。
DataSource のモックとして FileWatcher を使うことで、ファイルをDataSourceとして利用する例が紹介されていました。
ファイルなので出力を変えたいときはファイルを変更するだけよくて、アプリを再ビルドせずに出力結果を切り替えられるため、簡単にアプリの様々なケースの挙動を確認できて開発体験が向上するという話でした。
このように、先述したメリットだけでなく開発時にはDataSourceを意識せずにいられますし、紹介された便利なツールを利用する選択肢が増えるメリットがあるということが私としては学びでした！
物理的にモジュールを分けずとも、依存関係を意識した設計にすることで上記のようなメリットは享受できると思うので、今回学んだメリットも考慮して設計できるようにしたいですね。
総括
今回は、特に印象残ったり、勉強になったセッションを取り上げて紹介しましたが、そのほかどれも本当に勉強になるセッションばかりでした！
try! Swift Tokyoの特徴はやはり国際カンファレンスということで、セッションの大半が英語なのでリアルタイムで全てを理解し切るのはなかなか難しいですが、それゆえに何とか理解しようと公開されているyoutubeや関連する記事でさらにインプットするので、そういう時間も込みで大変刺激的で勉強になったイベントでした。
ぜひ来年も参加したいです！！！
Discussion