try! Swift Tokyo 2025 3日目の感想も、雑に綴っていきます。
1日目、2日目の感想はこちら。
SwiftSyntax: eval の力、善にも悪にも
SwiftSyntax を使って Swift の構文を評価する、という内容でした。
「自分でも SwiftSyntax を使えば Swift のコードを評価できるんだ」と思わせてくれるセッションで、Swift のパース処理の仕組みに対する理解がかなり深まる内容だったと思います。
ただ、私自身はなかなかついていけず、Swift Syntaxの知識をもう少し身につけた上で、再度見直したいですね。
セッション内で使用されていた Swift 構文を評価するプログラムのリポジトリも公開されています。
https://github.com/nicklockwood/SwiftSyntaxTalk
Swift で物を動かしてみよう!
Swift を使って物理のシミュレーションを行うという内容でした。
簡単なシミュレーションであれば軽微な計算量で実装できますが、現実世界の物理現象を再現しようとすると膨大な計算が必要となり、普通に実装するととても時間がかかってしまいます。
そんなときに Apple が提供している Accelerate API を使うと、圧倒的に高速かつ簡単にシミュレーションが可能になるそうです。
https://developer.apple.com/jp/accelerate/
SwiftUI API デザインの教訓: 手続き型 API と宣言型世界の橋渡し
SwiftUI でカメラ機能を実装する際の API デザインを紹介するセッションでした。
「SwiftUI の View は画面ではなくアプリケーション構造を表している」という言葉がとても印象に残りました。
そういう見方をすると、SwiftUI の宣言的な記述の幅が広がるし、AVCaptureSession のようなクラスも View の中で宣言的に書く設計に納得感が出てきます。これは新しい書き方だなと感じました。
ただ、リアルタイムでは詳細な実装までは追い切れなかったので、セッション内で紹介されていた実装リポジトリをぜひ見てみたいです。
https://github.com/niw/CaptureUI
Apple プラットフォームにおけるセキュリティリサーチとバウンティハンティング入門
バグバウンティ制度でAppleに貢献するための方法を、解説するという内容のセッションでした。
Apple では、セキュリティホールを報告すると報奨金が支払われるというのが、バグバウンティ制度らしいです。
これは、発見された脆弱性が第三者に売られてしまうことを防ぐ狙いがあるとのこと。
日本でも同様の取り組みをしている企業があるのか、気になりました。
また、Apple の API をリバースエンジニアリングする手法も紹介されており、アセンブリを読む必要はありますが、Objective-C に近い読み方ができるらしく、慣れれば思ったより読めるそうです。
通知に彩りを加えよう
通知で Genmoji を使おうとしたときに、文字に置き換えられてしまうという問題に対するアプローチについての話でした。
チャットアプリなどを作る上では知っておきたい内容で、これが実現できると通知の表現力がグッと広がりそうです。
ただ、自分としては「どうやって Genmoji を通知に使えるようにするか」という肝心な部分の理解が追いつかなかったので、もう一度見返したいです。
作って学ぶ正規表現 -やさしい Swift Regex 入門-
Swift Regex を使った正規表現のマッチング方法や効率的な書き方について解説されていました。
Swift Regex がどのような流れでパースやマッチ処理を行っているのかが図を使ってとてもわかりやすく説明されており、何度か見返せば内部の仕組みレベルで理解できそうです。
特に覚えておきたいのは「バックトラックを減らすことでマッチ処理の効率が大きく変わる」という点。
バックトラックの有無で処理速度が5倍も変わるケースがあるそうです。
また、セッションで紹介された Swift Regex の仕組みを学べるリポジトリはこちら。正規表現の仕組みを調べたいときに参考になりそうです。
https://github.com/kishikawakatsumi/TryRegex
Foreign Function と Memory API と Swift/Java 相互運用性
Swift と Java を相互に使えるようにする内容でした。
単に呼び出せるようになるだけでなく、両言語間のメモリ管理や構造体の扱いの違いをどうやって解決しているのかまでが解説されていました。
普段 Apple プラットフォーム開発ではあまり意識しない低レイヤーの概念が多く出てきたこともあり、個人的には少し難しく感じました。
ただ、Java はプラットフォームに依存しないという特徴があるので、Swift/Java の相互運用が進むことで、Swift を使える場面が広がっていくのはとてもワクワクするなと思いました。
ライブラリはこちら。
https://github.com/swiftlang/swift-java
Swift コード生成の可能性を解き放て
Swift Macros、Swift Package Plugin、Swift Syntax を活用して、Android の Dagger のような DI ライブラリを実装するという内容でした。
正直、それぞれの技術を単体で使うイメージは持っていましたが、「3つを組み合わせることで型を跨いだコード生成までできる」というのは新しい発見でした。とても参考になる内容でした。
Dagger を Swift で再現するというユースケースでしたが、他にもいろんな場面で応用できそうです。
SwiftSyntax の可能性を改めて感じました。
このセッションを解説した記事もすでに公開されています。
https://blog.smartbank.co.jp/entry/2025/04/11/unlock-the-potential-of-swift-code-generation
SwiftUI を最適化するためのレンダーループの理解
SwiftUI におけるアニメーションの仕組みや、ラグの原因とその解決方法について解説されていました。
SwiftUI (おそらく UIKit も) では「レンダーループ」という仕組みでアニメーションが実行されており、その仕組みを知ることでラグが起きる理由が理解しやすくなります。
この「レンダーループ」という考え方を初めて知れたこと自体が大きな学びでした。
レンダーループについては WWDC の動画でも解説されているので、あわせて見ておくと理解が深まると思います。
https://developer.apple.com/jp/videos/play/tech-talks/10855
SwiftUI の 8 番出口
SwiftUI で UI を実装する際に、うまくいかない部分を SwiftUI で解決すべきか、それとも UIKit に切り替えるべきかを「8 番出口」というゲーム風に解説する内容でした。
とにかくスライドが精巧すぎて、思わず内容よりそっちに目がいってしまいました…。
ただ、実務にすぐ活かせる知見がたくさん詰まっていたので、改めて見返したいセッションです。
こういった構成を「ゲーミフィケーション」と呼ぶのかな、と思ったり。
モジュラーなデータパイプライン設計
DataSource（データ層）、Translate（データ変換層）、Consumer（Presentation 層）というように、役割ごとにモジュールを分けた設計を解説する話だったと理解しています。
特に「DataSource を上位の設計方針（Presentation やドメイン層）から切り離すことで、実装に集中できる」という点が印象的でした。
開発中の DataSource のモックとして FileWatcher を使うことで、アプリを再ビルドせずに出力結果を切り替えられるため、開発体験が向上するという話もとても共感できました。
DataSource を柔軟に切り替えられる設計にしておくことで、開発ツールも導入しやすくなるという点は、新しい発見でした。
以上、最終日3日目の感想でした！
全日程通して思ったのは、今の私では理解するのは難しくレベルの高いセッションが多かったというところです。
オーガナイザーの方がオープニングで、難しくて分からなくても勉強するきっかけになったりするでも良いというようなコメントがあって、この言葉に支えられたなー思っています。
本当に勉強したい内容が増えましたし、すごいエンジニアにたくさんいてめちゃくちゃ刺激を貰えました。
また来年も行きたい！運営や登壇者の方、イベント中お話ししてくれたみなさん、本当にありがとうございましたー！