プロポーザル

Actor境界はSwift concurrencyにおいてデータ競合を防ぐための強力な概念ですが、実際のアプリ開発においてはこれが障壁となることがあります。Actor境界を跨ぐデータの受渡は通常非同期で行われますが、これを同期的に行わなければならないことがあります。例えばレガシーなスレッドベースのAPIを使う場合、引数として渡すコードブロックにおいて、そのActor context外のデータに同期的にアクセスすることが必要になることがあります。

このトークでは、AVFoundationを用いてサウンドを再生する例を題材にして、こうしたケースにおいてもActor境界を安全かつ同期的に跨ぐ方法について説明します。Custom actor executorや、OSAllocatedUnfairLockやMutexといったロックAPIを用いることで、unsafeキーワードを用いることなくActor境界外のプロパティにアクセスし、Swift 6でコンパイル可能な実装方法を紹介します。
Swift concurrencyとともに、どんなAPIも安全かつ効果的に利用できるようになりましょう。

私はいわゆる“飛行機オタク”で、BoeingやAirbusといった大型旅客機を操縦できるフライトシミュレーターをよくプレイします。
おそらく多くの人が一度は夢見るのではないでしょうか？「本物に近いコックピットを自宅に再現してみたい！」という願望を。
それを実現するための一つの手段として「TrackIR」のような視線トラッキングデバイスがありますが、こちらも価格が高く、なかなか気軽に手を出せるものではありません。そんな中、ある日YouTubeで「iPhoneを使って代替している」事例を見つけ、「これなら自分でもできそうだ」と思い立ち、iPhoneを使った自作の視線トラッキングデバイスアプリを開発してみました。

このトークでは、iPhoneのARKitを使ってリアルタイムでYaw（ヨー）/Pitch（ピッチ）/Roll（ロール）を取得し、それをUDP通信でローカルPCに送信。PC上のOpenTrackというプログラムにデータを受け渡し、最終的にMicrosoft Flight Simulatorに視点データとして連携させるまでの流れをご紹介します。

扱うトピックは以下の通りです：
• ARKitのFace Tracking（ARFaceAnchor）から取得できる顔の姿勢データの活用
• UDP通信の実装
• OpenTrackの仕組み、設定方法
• フライトシミュレーターゲーム（MSFS）と連携した話

このプロジェクトを通じて、ARKitのFaceTracking機能が想像以上に高精度であり、iPhone単体でも本格的な入力デバイスとして十分活用できることを実感しました。
市販のデバイスを購入せずとも、身近なデバイスと少しの工夫で、理想に近い環境を作ることができるという発見は、なかなか面白いトピックだと思います。

このセッションでは、継続的デリバリーの理想と現実の狭間で、マンガアプリのリリースプロセスに刻まれた
「シュプール」(雪面に残る軌跡) のような、私たちの改善の歩みを実例とともにお伝えします

• Branch Policy
  • Git Flow から Trunk Based Development への移行の過程とそのメリット
  • Code Review と CI の連携を最適化するために実施した取り組み
  • Feature Flag の管理と運用方法の改善
• Versioning Strategy
  • 優先度変更による Version の混乱を乗り越え、わかりやすく迷わない、Calendar Versioning を採用した経緯
  • Release Note 作成の自動化と情報共有の方法
  • Slackbot を活用した差分出力の簡素化
• Release Cycle
  • Release Train を用いた安定的で計画的なリリース
  • 属人化を避けるためのリリースフローとその実施例
  • 予期せぬ事態でも慌てない Hotfix 対応の実践

本セッションでは「あすけんiOSアプリ」における実践事例をもとに、テスト戦略をどう立て、どう現場に根づかせたのかを紹介します。
当社では、テスト運用が属人化していたり、テストが不足していたり、テスト書くこと自体が目的になってしまっていました。
ただ、ユニットテスト、UIテスト、E2E、さらにはスクリーンショットテストとCI/CDの連携など、全部網羅的にやることは現実的ではないです。
そのため、今の自分たちにとって、本当に必要なテストだけを選び取り、属人化を減らしてチーム全体で理解・運用しやすいテスト戦略を目指しました。
昨今の生成AIとの協働も考慮しつつ、テストの設計や現場で工夫したことなど、運用を見直すヒントを提供します。
例えば、AIを活用して、ユニットテストのコードを生成する取り組みなどをやりました。

ただし、試行錯誤は続いているのでうまくいっていない部分も語っていきたいと思います。 「テストはあるけど、なんとなく不安」「CIが形骸化している」「リリースのたびにUI崩れが怖い」
そんな現場にとって、戦略的にテストを設計・運用する事例や考え方を提供する内容になっています。

アジェンダ

1. 背景と課題
2. テスト戦略の再設計
3. テスト運用方法や手法
   • テスト設計
   • スクリーンショットテスト
   • CI/CDなど
4. 生成AIとの協働
   • テスト設計・運用におけるAIの活用例
5. 継続的な試行錯誤と課題

AIS（自動船舶識別装置）の非搭載などを理由に、小型船舶の海難事故は毎年2000件以上も発生しています
この長年の課題を解決するため、我々は2015年からiPhoneを用いた事故防止アプリの開発に取り組んできました
本発表は現在国立高専の教員兼iOSエンジニアである発表者が、過去数年間の開発で直面した技術的課題や法的な課題と、それらを現代のiOS技術やSwiftでいかに解決できるか説明するためのテーマです

本発表では最初に各開発フェーズでの実施内容と課題に関してお話します

• Phase 1 (2015-2016):
  • プロトタイプをiOSアプリとWebViewで開発
  • 他船との接近判定時のパフォーマンス問題
  • 電波法59条の抵触に関する問題
• Phase 2 (2017-):
  • フルネイティブアプリ対応、Apple Watch連携
  • 海上での電波利用状況の調査、操船中に通知へ確実に気づくためのUI/UXの設定と検証
  • 他船の位置情報提供・管理に関するプライバシー問題

次に本セッションでは、国土交通省から現在出ている安全航行支援アプリのガイドラインとUIのイメージ・注意点に関して説明します

• 例）GPS誤差を考慮した船の接近警告の判定と表示方法
• 例）通信不能時の判定と表示方法

最後にはパフォーマンス、UI/UXといった課題に対し、現在のiOSが提供する技術（SwiftUI、Swift Concurrency、Watch Complicationなど）を駆使してどのようにアプローチできるかを解説します
位置情報を利用した接近検知機能を持つアプリの実装方法と今まで発生してきた課題、当時の様々な実験結果を共有することで、船に限らずリアルタイムな位置情報処理に取り組む方々に知見を提供することを目指します

筆者はIT企業でiOSアプリ開発をする傍ら、国立弓削商船高等専門学校（以下、弓削商船高専）の情報工学科教員としてプロダクトやシステム開発に関する講義を行なっています。

弓削商船高専のような国立高専では卒業生が身につけるべき知識や能力の到達目標として「モデルコアカリキュラム（以下、MCC）」が定められています。
特に情報系分野では、プログラミング/アルゴリズム/コンピュータの仕組みといった知識・技能に加え、それらを統合して課題解決にあたる「創造性・デザイン能力」の育成が重要視されています。

筆者はSwiftとAppleエコシステムは現代の「ものづくり」のプロセスと非常に親和性が高く、以下のような理由からMCCが目指す能力を育む上で多くの利点を持つと考えています。

• 学生が日常的に使うiPhoneやiPadで動作するアプリケーション開発は、学習への強い動機付けとなる
• SwiftUIとXcodeのプレビュー機能はコードの変更が即座にUIに反映されるため、手を動かしながら試行錯誤することを多く体験できる
  • MCCで求められている「エンジニアリングデザイン能力」 の育成に適している

本セッションではこのMCCの理念である「ものづくり」を通じた社会実装教育を、SwiftとAppleエコシステムを使って実現するためのアプローチを考察します。

• 直感的なSwiftによるプログラミング基礎教育
• SwiftUIのパフォーマンス改善といった実践的課題から学ぶアルゴリズムとデータ構造
• LLVMを基盤とするSwiftの特性を活かしたコンパイラへの理解

本セッションを通して高専教育のカリキュラムや授業構成に関する問題点や新たな可能性を見つけ、未来のiOSアプリエンジニアを育てるためのより実践的なカリキュラムや授業の作成に繋げたいと思います。

2025年2月、AppleはビルドシステムのSwift Buildをオープンソース化しました。
Swiftコンパイラに始まり、xcodebuildやSwift Package Manager、swift-driver、llbuild、果てはClangやldまで、Swiftのビルドを支えるツール群は多様で、それぞれの役割もわかりづらいです。

この複雑怪奇なシステムたちはどのように協調・動作しているのでしょうか。

このトークでは、オープンソースSwiftを中心に、Swiftビルドシステムの全体像を解説します。また、今回新しく公開されたSwift Buildの内部を紐解き、ビルドパイプラインを駆け抜けましょう！

• コンパイラの基本、ビルドとリンクのおさらい
• Swiftのビルドを支えるツールたち
• XcodeプロジェクトとSwift Packageのビルドパイプラインの違い
• Swift Buildの登場と新しいビルドパイプライン
• Swift Buildのアーキテクチャを見てみよう

「バイブコーディングでAIにコードを書かせたけど、本当に動くの？」そんな不安を解消する、AI駆動の自動開発・自動検証システムを構築しました。本セッションでは、Claude CodeなどのAIコーディングアシスタントが生成したモバイルアプリのコードを、AIが自動的に動作確認する仕組みを紹介します。

具体的には以下のような内容をカバーします：

• AIによるコード生成後の自動動作確認フローの構築
• 生成されたUIコンポーネントの自動スクリーンショット検証
• AIが書いたコードに対する自動E2Eテストの生成と実行
• 問題検出時のAIへのフィードバックループの実装

「AIがコードを書き、AIが検証し、AIが修正する」完全自律型の開発サイクルはどこまで実現可能なのか？実際の開発事例とデモを通じて、AIによる自動コーディングの品質保証という新たな課題への挑戦をお見せします。

生成AIの進化により、Stable Diffusionをはじめとする画像生成技術が急速に注目を集めています。その流れを受けて、iOSアプリでも画像生成・加工の技術を取り入れたいというニーズが高まりつつあります。
iOSアプリで画像処理を実装しようとした場合、Core Image、Metal、CoreML、サーバサイド処理、さらには生成AI関連のAPIなど、選べる技術は多岐にわたります。

便利な選択肢が増える一方で、「結局どれを使えばいいのか分からない」「画像処理は難しそう」と感じて手が止まってしまう方も多いのではないでしょうか。

本トークでは、画像処理技術を利用してiOSアプリで独自の画像アニメーションを構築した経験をもとに、各技術の特徴と使いどころを整理します。
トークでは、独自アニメーションを実装するための要件を起点に、各要素技術（Core Image / Metal / CoreML / サーバサイド処理 / 生成AI関連のAPI）を使いながらアニメーションを構築していく過程を、実践的な形式で紹介します。
単に技術を羅列するのではなく、アニメーションの実際の動作を見せながら、「どのような場面でその技術を選ぶべきか」といった選定の観点を中心に、各要素技術を比較・検討していきます。

画像処理に興味はあるけど、何から手をつければいいか分からない。そんな方に向けて、iOSで使える技術やアプローチを実例とともに紹介します。
実は私自身も画像処理の専門家ではありません。でも、様々な技術を試す中で「意外と面白い」「ポイントさえ押さえれば自分でも作れる」と感じました。
本トークを通じて、画像処理は「難しそう」ではなく「ちょっとやってみたい」と思えるような、そんなきっかけを届けられたら嬉しいです。

このセッションでは、ビルド高速化のノウハウをまだ持っていないAppleプラットフォーム開発者向けに、具体的にどのようにビルド速度を改善できるのかを解説します。

アプリ開発中は、実装やCI/CD等で沢山ビルドすると思います。
ビルドの時間が遅いと、単純に開発者にとってストレスになるだけでなく、開発のテンポが悪くなり実装内容に見合わない大きなコストがかかることになります。
WWDCのセッションビデオや公式ドキュメントより、Xcodeのビルドシステムの仕組みを見てみると、ソースコードの量やマシンスペック以外にも様々な原因でビルド速度のボトルネックになる要因があることがわかりました。
皆さんの関わっている、プロジェクトのビルド設定やソースコード自体がビルド速度のボトルネックになっていることが、あるかもしれません。

本トークでは数あるビルド時間が伸びてしまう原因のうち、解消したときに短縮できるビルド時間が大きいと思われるものを3つに厳選して、重要なチェックポイントと修正方法をそれぞれ解説します。
具体的には、次の内容に関連した原因についてお話しします。

• 並列ビルドの最適化ができていない
• 依存ライブラリのコンパイル時間が長い
• コンパイル時の型推論時間が長い

例えば、Xcodeでは並列に複数のビルドタスクを進めることができますが、プロジェクトの依存関係によっては並列で処理できない部分が発生することがあります。
このような問題をどのようにして発見し、どうやって改善するのかそれぞれ詳しく説明します。
サンプルコードや、実際のプロジェクトで取得したビルド時間のベンチマークを比較して、実際どれぐらい早くなるのか、も見ていきます。

業務、プライベート問わず、普段の開発でビルド時間に悩まされている開発者にとって、是非聴いていただきたい内容です！

アプリ開発において、UIの品質担保は誰しもが一度はぶつかる課題だと思います。
解決策として、E2Eテストやスナップショットテスト、実機テストが挙げられます。
その中でも、swift-snapshot-testingを使ったビジュアルリグレッションテスト(以降VRTと呼ぶ)に焦点を当てていきます。
※VRTとは、変更前と変更後のコードで対象画面のスナップショットを比較することで、UIのデグレを検知するテストです。

「UIテストは運用コストが高い」と、諦めた経験のある人はいませんか？
導入初期は運用できていたものの、少しずつ放置されていき、運用されなくなってしまった経験はありませんか？

本トークでは、そんな運用コストの課題を
CursorやClaude Code Github Actionsを使って解決した方法をお話しします。
また、以下のテーマに触れながら進めていくので、検証から運用まで具体的にイメージすることが出来ます。

• 技術選定の内容と理由
• ChatGPTが提案するコードのセキュリティの問題
• CIの実行時間の課題
• カバレッジ計測の自動化
• テスタブルなUI設計
• Cursor, Claude Code Github Actionsの活用方法

導入後の現在も、品質や設計・自動化面で改善を続けており、
それらを余すことなくお伝えできればと思います。

「VRT導入時、どのようなことを考慮したら良いかよくわからない」
「VRTの導入を検討しているが、実際にチームで運用し続けられるか悩んでいる」
「運用が止まってしまっている」
そんな方々に参考になるセッションとなれば幸いです。

開発者にとって、使いやすいSDKドキュメントはプロジェクトの成功に不可欠です。にもかかわらず、ドキュメントの整備や運用には多くのハードルがあり、「後回しになりがち」「仕様と乖離しやすい」「更新が面倒」といった課題を抱える現場も多いのではないでしょうか。

本セッションでは、Xcode に標準搭載されている DocC と GitHub Pages を活用し、開発コストを抑えつつ、ユーザーにとって“使える”ドキュメントを自動生成・公開する方法を、実例とともに丁寧に解説します。

以下のような構成で、ドキュメント構築の一連の流れを紹介します：

• /// コメントから始める DocC ドキュメンテーションの基本
• xcodebuild docbuild による .doccarchive 生成とその仕組み
• xcrun docc process-archive transform-for-static-hosting を使った静的ホスティング対応
• GitHub Actions を用いた CI/CD 自動化による公開フローの構築
• Parameters・Returns・Note・Important などを活かしたリッチな Markdown 記法
• ユーザー視点で見やすく、保守しやすい構造設計のポイント

これらは、実際に私たちが開発・提供している SDK に DocC を導入し、社内外に向けたドキュメント公開を運用した経験に基づいています。導入時にハマった落とし穴や、記述の最適化ポイントもあわせて共有します。

自社SDKやライブラリをより使いやすく、メンテナンスしやすいものにしたい開発者に向けた、実践的なDocC活用術です。

最近、フルSwiftUIでの画面を提供するSDKをリリースしました。この経験を基に、SwiftUIのStateの更新方法としてReduxを採用しています。Reduxは古いと言われがちですが、私たちは関数型に近いアプローチを採用することで、テストのしやすさや責務の分離を実現しています。

このトークでは、リアルなコード例を通して、ステートマシンの設計方法やテストのしやすさの改善方法、UI/UX向上への具体的な効果について詳しく説明します。例えば、どのようにしてReduxの責務を持つInterfaceを自作し、Swift Testingを活用しているのかを具体的にお話しします。

お話する内容:

Reduxの基本概念と自作Interfaceの設計方法
Swift Testingを用いたテストのしやすさの向上
UI/UXの具体的な改善事例

このセッションを通じて、Reduxを用いたイベント駆動UIの有効性とその可能性について理解を深めていただけることを目指しています。

アプリが重いと感じた瞬間にユーザーは離れてしまいますが、ユーザーが感じる「速さ」は、起動時間やフレームレートなど複数指標の複合体になっています。
そのため、本セッションでは「起動は95%のユーザーで1.5秒以内」「画面遷移の97%を120fps以上」といった、体感パフォーマンス目標（SLO）を設定し、

1. Swift Tracingで操作ごとの処理時間をラベル付け
2. MetricKitで実機のフレームレートやCPU消費を自動収集
3. CIテストと本番監視に組み込んで、遅くなった瞬間にリリース前でも後でもアラートが飛ぶ仕組み

を順を追って紹介します。
これにより、翌日から「速さを数字で語れるチーム」に変わるきっかけを提供します。

iOS 26で導入された新マテリアル「Liquid Glass」は、透過・屈折・環境光の反射によって奥行きと没入感をもたらします。
しかし実運用には、可読性の低下、端末負荷、アクセシビリティ対応、旧端末サポートなど多岐にわたる課題が伴います。

本セッションでは、以下の7パターンを設計ガイドラインから実装、モニタリングまで体系的に解説します。

1. Surface Token Mapping―既存レイヤーを3階層に再マッピングし、UIを崩さず第一歩を踏み出す
2. Depth Blueprinting―Zオーダーを0–4の等高線で設計し、視差と情報設計の両立を図る
3. GlassEffectContainer Clustering―カード融合・分割を60 fpsで実装する動的レイアウト手法
4. Adaptive Transparency & Motion―Reduce Transparency/Motion設定と連動した酔わないUIの実装
5. Performance-First Fallback―A14世代以下でも動作を維持するBlur解像度ダウングレード術
6. Remote Flag & Phased Roll-out―ABテストとMetricKit監視を組み合わせた安全な段階リリース
7. Design–Dev Co-Tooling―FigmaプラグインとXcode 26 Glass Previewを用いた往復コストゼロの協業

視聴者は、デザインポリシーとコード例を持ち帰り、翌日から自社プロジェクトでLiquid Glassを安全かつ効果的に適用できるロードマップを描けるようになります。

手話とは、表情や手の形・動きによって多様な単語や感情を伝える言語です。
私はもともと大学時代に障がい教育の研究をしており、その中で手話にも関心を持ち、「手話を知らない人が、手話に親しみを持つにはどうすればいいか？」と考えていました。

近年テクノロジーの進歩により、Apple プラットフォームでも多様な機能を備えたOSやデバイスが登場しています。今回はその中でもRealityKit によるハンドトラッキングとVisionProを活用して、自分自身の手で表現した手話の単語を検出・翻訳するツールの実装にチャレンジしました。
この発表では、以下のポイントについてデモを交えてお話しします。

1. 手の関節にマーカーを表示する方法
2. SpatialTrackingSession を用いたハンドトラッキングの基礎
3. カスタムジェスチャーの検知手法

現時点のハンドトラッキングでは、手話特有の表現を正確に認識することが難しいケースもありますが、発表ではそのような制約についてもお話しします。

ハンドトラッキング技術に関心のある方はもちろん、手話という言語の多様性や表現力に少しでも興味を持っていただけるような発表を行います。

皆さんのプロダクトは、Swift 6へのメジャーアップデート、もう対応されましたか？

私たちのチームでは、iOSアプリのSwift6対応を進めようと準備を始めました。
しかし、 そこで直面したのは想像以上に大きな課題でした。
それは、Swift6で新しく導入された「Strict Concurrency Checking」の機能の存在です。
この機能の対応によって、「少しの修正で解決できる」といった簡単な話ではなくなりました。

その結果、私たちは長年使用してきたReactorKitを脱却することを決断します。

このトークでは以下の内容についてお話しします。

• Swift6から導入された「Strict Concurrency Checking」とは一体何なのか
• 脱ReactorKitをどのように進めているか
• まさかの結果とは一体何か！？

これからSwift6対応を検討されている方、ReactorKitを使っている方にとって、きっと共感していただける内容になっています！

Swift Concurrencyは、async/awaitによる非同期処理の簡素化やactorによるデータ競合安全など、私たちに多くの恩恵を与えてくれます。

一方で、「少し使いたいだけなのに、なんだか難しい…」と感じている方もいらっしゃるのではないでしょうか。特に「ただ普通にコードを書いているだけなのに、なぜ警告やエラーが出るのかわからない...」という声をよく耳にします。

Swiftコアチームは、使いやすさを高めるためのビジョンを掲げ、Swift Evolutionのプロセスと独自の機能改善を通じて、これらの悩みを解消しようとしています。先のWWDC25では、この取り組みが「Approachable Concurrency」として紹介されました。

本トークでは、このApproachable Concurrencyについて、主にWWDC25のセッションではあまり語られなかった部分に焦点を当て、以下の内容を深掘りしてお話しします。

1. Approachable Concurrencyに至った背景
2. 具体的な各機能のちょっと深い紹介(Isolated ConformanceによるProtocolのエラー解消、診断ドキュメントのわかりやすさ改善、など)
3. Approachable Concurrencyから見える、目指すべきiOSアプリの書き方

本トークを聞くことで、Approachable Concurrencyの意義を理解し、謎の警告やエラーに悩まされる回数を減らし、皆さんがConcurrencyをより「親しみやすく」感じる一助となれば幸いです。

概要

近年のAIの急速な発展により、従来のコマンドベースの入出力と比較して、自然言語による入出力が一般的になり、ユーザーインターフェースは大きく変化しています。言語学習や運転中の操作など、ハンズフリーでの対話が求められる場面や、VisionOSなどでのキーボード入力が困難な場合において、音声インターフェースの重要性が増しています。一方で、実際に音声AIエージェントを実装しようとすると、チャットUIとは異なる固有の技術的課題に直面することになります。本セッションでは、現在開発中のAI英会話アプリでの実体験を通じて、音声インターフェース特有の課題とはまりどころ、およびその解決策を具体的なSwift実装とともに解説します。

話す内容（予定）

• 音声AI Agentのアーキテクチャ
• AVAudioEngineを活用したストリーミングによる音声入出力
• 状態管理とそれに基づく会話の割り込み実装
• Swift Concurrencyを利用したストリーミングデータパイプライン
• gRPCストリーミングによるリアルタイム通信

話さない内容

• AIモデルの学習方法や理論的背景
• プロンプトエンジニアリングの詳細
• LLMの性能評価や比較
• 基礎的な音声処理理論

アプリの品質保証において、既存の機能が意図せず壊れていないかを確認するリグレッションテストは不可欠ですが、その多くが手作業で行われ、リリース前のiOSエンジニアにとって大きな負担となりがちです。
多くのチームがE2Eテストの「完全自動化」という理想を追い求めますが、サービス仕様上スムーズに認証を通す事が難しかったり、特定のUI要素の操作が困難だったりして、現実的な課題に直面し、導入を断念してしまうケースも少なくありません。

本トークでは、「完璧な自動化を目指さない」という発想の転換から生まれた「半自動E2Eテスト」のアプローチを紹介します。
既存の全手動運用をベースに、課題となる箇所を段階的に自動化していくことで、最小限のコストで最大限の効果を得る方法を実践例と共に解説します。
具体的には、SMS認証やカメラ操作、OS標準アラートといった自動化が困難なシナリオに対し、RubyのOCRライブラリ活用や座標指定、手動介入のタイミングを知らせる音声ガイドなどの工夫を通じて、どのように「手っ取り早く」運用可能な状態を構築したかをお話しします。

実際に導入から5ヶ月間、継続的に利用され、リグレッションテストの効率化に貢献している本システムの具体的な運用実績と、そこから得られた「壊れやすさを気にしすぎない」「最低限のメリットから始める」という、挑戦を後押しする考え方と安心感について共有します。
このセッションを通じて、リグレッションテストの負担軽減を模索している方、E2Eテスト導入の壁にぶつかっている方々が、新しいアプローチを見つけるきっかけとなれば幸いです。