Future Tech Blog
フューチャー技術ブログ
Cultureカテゴリ

try! Swift Tokyo 2025に参加してきました！

はじめに

HealthCare Innovation Group(HIG)1の橋本です。

初めてtry! Swift Tokyo 2025に参加してきました！

参加報告として、興味深かったセッションや参加して感じたことなどを共有します。

try! Swift Tokyoとは

公式HP の記載の通り、Swiftに関する国際カンファレンスです。今年は、2025年4月9日~11日の3日間で開催されました。

イベントについて
Swiftを使った開発のコツや最新の事例を求めて世界中から開発者が集います。
日頃のSwiftの知識やスキルを披露し、協力しあうことを目的に、2025年4月9日 - 11日の３日間開催します！

開催場所: 立川ステージガーデン

会場は、昭和記念公園が隣にあったり、自然と調和した商業施設も隣接していたり、とてもリラックスできるような場所でした。（立川ステージガーデンの椅子がとても座りやすく、セッションの視聴に集中することができました。）

try! Swift Tokyo 2025のアプリ

try! Swift Tokyo 2025を楽しむための公式アプリがありました。

アプリ自体は、フルSwiftUI x TCAというモダンな構成で実装されているとのことなので、GitHubレポジトリから中身も見てみたいなと思います。

機能としては、スケジュールや会場までのルート、AI通訳などがありました。中でもAI翻訳がとても便利で、英語のセッションもリアルタイムで翻訳してくれていたので、とても助かりました。Flittoさんありがとうございました。

  • AI通訳機能画面

visionOS対応もしており、Apple Vision Proユーザーの方は、会場に表示されている壇上のスライドの上に、AI翻訳のウィンドウを表示させて見れてとても便利でしたという声もありました。（自分も体験してみたい。。。）

image.png

良かった・役に立った・もっと理解したいと思ったセッション

私が視聴して良かった・役に立った・もっと理解したいと思ったセッションをいくつか紹介します。

try! Swift Tokyo 2025の全セッションはtry!Swift TokyoのHPのタイムテーブルからご確認ください。

iOS17,16,15での新機能(セッション動画はこちら)

タイトルの通り、iOS17,16,15それぞれで新しい利用できるようになったAPIを紹介する発表でした。
WWDCのセッション動画で利用できると知っても、使えるようになるまでにタイムラグがあったりするのでこのタイミングでiOS17,16,15のAPIをいくつかキャッチアップできたのはとても良かったです。具体的には以下のAPIの紹介がありました。

紹介のあったiOS 15.0+で使えるAPI:

  • formatted()
  • privacySensitive(_:)
  • .toggleStyle()
    • togglestyle(_:) → .toggleStyle(.button)などを使うことで組み込みのボタンの振る舞いが得られる

紹介のあったiOS 16.0+で使えるAPI:

  • UIHostingConfiguration
  • TextField(_:,text:,axis: .vertical)
    • init(_:text:axis:) → TextField(_:,text:,axis: .vertical)を使うことで、文字数が長くなったときに、テキストを途中で折り返し、テキストを全量表示できる
  • Color.gradient
    • gradient → デザイナーからの指定がないようなプロトタイプ作成のようなとりあえずグラデーションをかけたいときに便利

紹介のあったiOS 17.0+で使えるAPI:

日本語でのSwiftプログラミング(セッション動画はこちら)

Xcode,Swiftにおいて、日本語の識別子は基本的にサポートしている。パフォーマンス面でも問題ないとのこと。
テスト関数名は、日本語にしてもいいかな何て思ったりもしました。

Swift Testingでは、XCTestのテスト関数で必須であったプレフィックスtestが不要になるので、次のようなイメージで書くのも良いかもと思いました。

- @Test func foodTruckExists() {
+ @Test func フードトラックが存在する() {
  // Test logic goes here.
}

⚡️ Swift × Android: Skipが切り拓くクロスプラットフォーム開発の未来(セッション動画はこちら)

SwiftとXcodeを使って、iOSとAndroidのアプリを作成できるツールSkipの実用性と今後クロスプラットフォーム対応の主流となるかについて、スピーカーが実際にアプリを作成したときの経験が紹介されていました。

  • 基本的にはSkipによって変換、生成されたコードでAndroidアプリのUIは期待通りになる。
  • 2つのモードのうち、Native Modeを使うことをおすすめするとのこと。主な理由としては、もう一方のモードTranspile ModeではSwiftからKotlinに変換ができないAPIをがいくつかあるため。
  • 既存で開発しているiOSアプリにSkipをそのまま適用は難しいとのこと。理由としては、iOSアプリで使用しているライブラリの一部がAndroidでサポートされていない。しかし、UIに関してはSwiftUIもそのままAndroidアプリに変換できるようにコンパイルできるようになってきている。
  • スピーカーは、Skipがクロスプラットフォームのメインストリームに数年でなるのではとのこと。

skiptools/skip-uiのSupported SwiftUIをみても多くのものがFull Supportになっているのも確認できました。これを見ても、純粋？なiOSエンジニアがクロスプラットフォーム対応するときには、Skipも有力候補に入ってきそうだなと感じました。
私自身は、Kotlinを書いたことがないので、SwiftのコードをそのままAndroid対応することができるSkipはとても魅力的に映るために、時間をみつけてSkipを触ってみたいと思いました。

参考資料:

Foreign FunctionとMemory APIとSwift/Java相互運用性(セッション動画はこちら)

SwiftとJavaを相互に利用する方法について紹介がありました。
開発段階であるライブラリswiftlang/swift-javaをAppleのエンジニアでContributorであるKonradさんがお話されていました。

swiftlang/swift-javaでは、SwiftとJavaを相互運用するために次の２つのアプローチがあります。

  • JavaKit
  • JavaのAPIを直接呼ぶことが可能にするSwiftライブラリ
  • jextract-swift
  • jextractと類似したSwiftからJavaを効率的に呼び出すために使用するJavaソースを抽出するツール

内容は私には理解が難しい部分が多々あったが、弊社ではJavaを使う案件が多いので、該当レポジトリの内容とセッションを見直したいと思いました。セッションの中で、UIをSwiftUIで残りの内部ロジック等をJavaに寄せることができるようなお話もあり、とても興味深いものでした。

SwiftUI を最適化するためのレンダーループの理解(セッション動画はこちら)

SwiftUIを最適化するために、理解が必要なSwiftUIのレンダリングの仕組みや具体的な例を用いて表示遅延が起こる原因や解決策についての紹介がありました。

SwiftUIViewがどのようにレンダリングされているかという質問に対しては、レンダーループを理解することが近道です。

レンダーループ(Render loop)

レンダーループ(Render loop)とは、アプリのUIがどのように更新され、画面に表示するかを管理する継続的なサイクルを指します。

レンダーループのサイクル:

  1. Event Phase
    • 何かしらのイベント/状態変化を検知する
  2. View Update Phase
    • Event Phaseでの変更を元に、新しいView階層を構築する
    • そのとき、以前のView階層と比較を行い、UIを更新するために必要な最小限の変更セットを作成する（この機能は、UIKitにはなく、SwiftUI独自のものであり、これによりViewの描画が最適化されている）
  3. Render phase
    • SwiftUIが新しいView階層をGPUで処理可能な形式に変換する（これには、色、形、画像などの視覚に関するプロパティが含まれる）
  4. Display Buffer
    • Render PhaseでDisplay Bufferが作成される
  5. Display
    • Diplay Bufferのピクセルデータをユーザー用の最終的な視覚情報に変換する

サンプルプロジェクトによる例示

サンプルコード: https://github.com/pradnya-nikam/trySwiftTokyoPrad2025

サンプルコードの雲をたくさん描画するViewでは、動く雲の数が多くなるにつれて動きもっさりしてきます。描画時のCPUの状況を見ると、徐々にCPUの使用率が上昇していくことが紹介されていました。これはRender Phaseですべての雲の位置を計算、雲の形を描画し、視覚効果を適用しているためです。このため、Render Phaseに割り当てられているフレーム内で処理がしきれなくなってしまい、ラグが発生してしまいます。

そこで、.drawingGroup()を適用して、ラグを解消します。

CloudView()
    .drawingGroup() // これを加えるだけ

drawinggroup(opaque:colormode:)

このメソッドを使うことで、画面上には見えないオフスクリーン上でMetal APIを使用して、一つのイメージにまとめて描画することでパフォーマンスを改善させています。
実際に、CPUの使用率も、適用前の112%から33%ほどまで下がっていました。

Cherry Blossoms! App:

反対に、桜が散っていくアニメーションがあるViewでは、.drawingGroup()を適用することで逆に、動きが遅くなり、不安定になってしまいました。この理由はこのアプリの花びらは削除と作成を繰り返すため、このメソッドで解決するようなシチュエーションではないとのことです。

このように、drawingGroup()を使わない方よい例は以下の4つです。

  1. Views with Dynaminc Content → Viewのコンテンツが頻繁に変更されるもの
  2. Text Views → テキストを表示するときのレンダリングは複数なレイアウトとグリフ管理があるため
  3. Views with interactions → 予期しない変更が生じる可能性がある
  4. Special Visual effect like some blending modes maynot work properly

本セッション内容は、SwiftUIを普段使っている私にはとても勉強になりました。レンダーループについては、サンプルコードを手元で動かしつつ、Instruments等を使ってパフォーマンスに関して色々実際に検証してみたいと思いました。

参考資料:

さいごに

今回は一般参加で、try! Swift Tokyo2025に参加しました!

次回は別の形(スタッフやスピーカーなど)で参加してtry! Swiftのコミュニティの発展に貢献したいと感じました。

英語話者が多いイベントということで、久しぶりに英語を聞いたり、話したりしましたが学生時代より聞き取れなかったり、言葉が出ないということがあったので英会話をまた始めたいなと思うきっかけになりました。

セッションでは、技術的な知識だけではなく、取り組む姿勢や心持ちみたいなことも話されている方でいて、様々な面で良い刺激を受けることができました。来年の開催も楽しみにしています！

  1. 1.医療・ヘルスケア分野での案件や新規ビジネス創出を担う、2020年に誕生した事業部です。設立エピソードは未来報の記事をご覧ください。 ↩