プロポーザル

現代のServer-Sideにおいて、Observability（可観測性）は必須の存在です。マイクロサービスやCQRSなどの分散システム、サーバーレスモデルでは、ログ・メトリクス・トレースを集約して観測できることが運用上必須となっています。
Server-Side Swiftを採用する際、主軸として使う場合でもマイクロサービスの一部として導入する場合でも、OpenTelemetryなどの業界標準との連携は避けて通れません。
本トークでは、Apple公式のswift-log、swift-metrics、swift-distributed-tracingの役割と連携方法を解説し、OpenTelemetryを通じて様々な監視サービスと接続する方法を紹介します。

実践的なライブデモ
Vapor + AWS Lambdaを使用したCQRS/Event Sourcingシステムの実装を通じて、AWS CloudWatchとX-Rayによる分散システムの監視を実演します：

• 分散トレースによるリクエストの流れの可視化
• Lambda関数間の呼び出し追跡
• イベント処理の監視
• 処理速度のボトルネック特定

SwiftはiOSアプリ開発で培った型安全性と高いパフォーマンスをサーバーサイドでも活用できます。CQRS・Event Sourcing・Serverlessのような複雑な分散システムこそ、Swiftの強力な型システムとApple公式の監視ツールが真価を発揮します。
Server-Side Swiftの導入を検討している方、本格的な運用に向けて準備したい方に、実践的な監視システムの実装方法を提供します。一緒にServer-Side Swiftで本番環境に耐えうるシステムを構築する一歩を踏み出しましょう。

「アクセシビリティ機能を使用してこのコンピュータを制御することを求めています。」

macOSでアプリを初めて開いた際、このような許可ダイアログが表示されたことはないでしょうか。
ダイアログの内容からはどのような許可を求めているのか理解しずらいですよね。

実はこれ、かなり強力なコンピュータ制御の権限を得ようとしていることをご存知でしょうか。
この権限を使えばキーロガーや画面監視アプリなんて簡単に作れてしまいます。

そんなことを知らずに何気なく許可していた方は、本トークでmacOSのセキュリティリスクを再確認することができます。
アクセシビリティの許可をすることでどのような処理ができるのかをコードベースで理解し、そこからどのような危険性があるかを説明していきます。
ただし、危険とは言いつつも開発者としては非常に面白い機能も使えるようになるため、技術面でも興味深い内容となっています。

AIによって自動化が急速に進化する今だからこそ、コンピュータの制御を可能にするアクセシビリティの許可は正しく理解しておく価値があります。
きっとみなさんのMacにもアクセシビリティ許可をしているアプリがあるはずです。

ぜひご覧ください！

Apple Style Guide は、Apple 製品に関する用語や表現のガイドラインです。UI やドキュメントでどのような言葉、どのような表現を使うべきかが記載されています。

Apple のガイドラインといえば、Human Interface Guidelines があります。これは iOS アプリ開発者に必読のガイドラインとして知られています。一方 Apple Style Guide のほうは、よく知らない開発者も多いのではないでしょうか。しかし実はこれも知っておくべきガイドラインです。このガイドラインに従うことで、ユーザーの混乱を防止できます。

たとえば、「Apple ID」ではなく「Apple Account」が正しい表記です。Apple Style Guide を読めばこのような適切な表記がわかります。不正確な表記は、アプリやドキュメントの信頼感を損ねます。

また、「クラッシュ」という表現は UI やドキュメントでは避けるべきです。読者によっては、ハードウェアやソフトウェアの損傷を連想するかもしれません。代わりに「予期せず終了する」「応答しない」などの表現を使います。こうしたことも Apple Style Guide に記載されています。

Apple Style Guide は他にも、インクルーシブな記述、数値や単位の表記、コードなどの技術的な表現、国際的スタイルでの表記について書かれています。多くのユーザーにアプリやドキュメントを利用してもらうために、重要な内容です。

本トークでは Apple Style Guide から、iOS アプリ開発のために知っておきたい内容をピックアップして解説します。正確な表記やよりよい表現を知り、アプリの信頼性を向上させましょう。

ウォンテッドリーのモバイルアプリでは、Kotlin Multiplatform（KMP）を使ってビジネスロジックを共通化しています。
一方で、iOSエンジニアにとってKotlinは馴染みが薄く、不安を感じる方も多いのではないでしょうか。
私自身、Swift中心の開発を続けながら、1年間KMPを導入したプロジェクトに関わってきて、「iOSエンジニアとしてKMPとどう向き合うべきか」を日々模索してきました。

本セッションでは、私自身がこの1年で得た、iOSエンジニアとしてKMPと関わるうえでの学びと工夫を、以下の3つの観点から共有します。

1. 設計の重要性
   ウォンテッドリーではビジネスロジックを担うReactorの設計書を書いてチーム内でレビューをしてから実装を行います。丁寧に設計を行うことで、出戻りや仕様のズレを防ぐことができ、KMPとiOS側の開発がスムーズに連携できるようになります。

2. Preview駆動開発との相性
   ロジックとUIの責務を明確に分けることで、Previewによる効率的な開発が可能となり、KMPの共通ロジックとも無理なく共存させることができます。

3. AI活用によるKotlinのキャッチアップ
   Kotlinに不慣れな立場でもAIを活用することで、レビューや仕様理解がしやすくなり、日々の開発に必要な知識を実践の中で補うことができます。

このセッションが、KMPの導入に不安を感じているiOSエンジニアや、導入を検討しているチームの方々にとって、実践的なヒントや前向きな視点とともに、成長の機会になると思えるきっかけになれば幸いです。

RxSwiftのコードを読んでいくと、Observerパターンやイベント伝播の考え方など、「プログラミングの基礎」に立ち返る瞬間があります。本LTでは、RxSwiftの代表的な要素（Observable, Observer, Subscribe, Dispose）を題材に、実際のソースコードを一部追いながら、そこにある基本的な仕組みを解説します。
たとえば、イベントの購読処理はどう保持され、どこで通知が発火するのか？この流れを理解することで、RxSwiftが単なるライブラリではなく、基礎的な設計原則に沿って構築されていることが分かります。
また、こうした理解は、CombineやSwiftUI（@State, @Publishedなど）の仕組みを学ぶ上でも大きな助けとなります。
リアクティブなコードに苦手意識を持つ方や、ライブラリの「中身」を通じてプログラミングを深く学びたい方に向けて、基礎を見直すきっかけとなるLTです。

皆さんのアプリでは、依存性注入（DI）の仕組みを効果的に活用できていますか？
私たちの開発する大規模モバイルアプリ『GO』では、コンポーネントベースのアーキテクチャを採用しています。
しかし、現在採用しているアーキテクチャ標準のDI機能では、コンポーネントの追加やリファクタリングの際に大量の定型コード(ボイラープレート)を手動で修正する必要があり、生産性や開発者体験の低下が課題となっていました。

この課題を解決するため、新たなDIフレームワークの全面的な導入を決定。
導入にあたり以下の2つの大きな挑戦がありましたが、これらを乗り越え、約半年という短期間で導入を完遂しました。

1. 500以上あるコンポーネント間の複雑な依存関係を考慮した、段階的な導入計画の策定
2. 並行して進む大規模な新規開発プロジェクトへの影響の最小化

本トークでは、導入前の課題分析から、開発影響を最小限に抑えた導入計画の策定・実行プロセス、そして開発速度の向上を達成するまでの実践的なアプローチについてお話しし、アプリ全体に影響する大規模な技術刷新を計画・実行する上での勘所や注意点を共有します。
このトークでお話しする内容が、アプリ全体へのDIフレームワークの導入時の注意点や、アプリ全体に影響する大規模な導入時にどのような点を考慮するべきかなど、皆様のアプリ全体を見据えた改善活動を進める際の一助となれば幸いです。

会場でお会いしましょう！

WWDC 2025においてSwift製のContainerization Frameworkがオープンソースで公開され、主にバックエンドエンジニアの間で注目を集めました。
このセッションでは、普段Swiftを書くマジョリティであるネイティブアプリのエンジニアと、コンテナをよく知るけどSwiftはまだ勉強中の僕が交わる交差点として、Swiftで書かれたContainerization Frameworkの実装を深掘りします。
参加される皆さんがコンテナ技術やフレームワークの設計思想を理解することで、単にコンテナを立ち上げたり動かしたりするだけでなく、フレームワークを活かしたツールの制作などができるようになるかもしれません。
また、フレームワークの裏側で使われる幾つかのOSに近い部分や基礎技術要素についても触れることで、これまでのツールとの違いについても解説します。

Swiftでのサーバー開発の可能性について考えてみませんか？
また、iOSエンジニアであっても、サーバーまで網羅するフルスタックエンジニアへの跳躍を考えたことはないでしょうか？

Swiftでのサーバー開発にチャレンジしてみます。Server Side Swiftプロジェクトは長い間開発されてきましたが、実際のサービスで使われている例はまだ多くはありません。ぜひ、わたしといっしょにVaporを体験し、Server Side Swiftのエコシステムをいっしょに育てていけたらうれしいです。

今回のトークセッションでは、WWDCでも何度か紹介されてきたVaporフレームワークに注目し、簡単なサーバーアプリを一緒に作ってみます。プロジェクトの初期化から、実際のWebやアプリでの使い方、Dockerを使ったサーバーのデプロイまで、一つのTODOアプリを作りながら解説します。クライアントからサーバーまで全てを網羅するSwiftエンジニアになりませんか？

＜アジェンダ＞

• Swift開発者の新境地！Vaporで開くサーバーサイドの世界
• Vaporプロジェクト、立ち上げガイド
• APIの設計と実装
• サーバーとDBの賢い連携術
• Webコンテンツの表示ロジック
• Dockerコンテナ化とデプロイの秘訣
• Swiftで広がる可能性：次なる挑戦へ

「アプリにリアルタイム通信を導入したいけれど、サーバ構築の学習コストや使用するライブラリ選定に不安がある」──そんな理由で導入をためらった経験はありませんか？
iOSアプリエンジニアの私もゲーム開発で同じ壁にぶつかりましたが、「標準技術であるApple純正フレームワークだけでリアルタイム対戦アクションゲームを作り上げる」という道を選びました。
さらに、WWDC25にて発表されたWi-Fi Aware Frameworkというインターネット不要の新たなP2P通信フレームワークの登場により、今あらためてリアルタイム通信の可能性が広がっています。

このトークでは、私が個人開発したSpriteKit製の対戦アクションゲームを題材に、Apple純正技術を活用したリアルタイム同期の構成や設計の工夫を紹介します。

• GameKit × GameCenterを用いたオンライン対戦のマッチングと通信設計
• MultipeerConnectivityを用いた近くの端末とのオフライン通信の構築
• WWDC25にて発表されたWi-Fi Aware Frameworkのオフライン通信への活用と検証
• 各通信方式の通信範囲、レイテンシなどの比較と選定ポイント
• アクションゲームにおけるプレイヤー座標やダメージ処理を例にしたデータ同期設計

また、トークでは実際のゲームを用いたデモを通して、3つの方式がユーザー体験に与える違いをご覧いただけます。
「サーバ構築せず、Apple純正フレームワークだけでここまでできるのか！」という驚きとともに、「自分のアプリにもリアルタイム通信を組み込みたい」と感じてもらえるような、実践的なトークをお届けします。

Xcode Previewsは2019年のXcode 11でSwiftUIと共に導入されました。リアルタイムでUIのプレビューを確認できる機能で、開発者のUI構築を効率化します。Xcode 15では #Preview マクロによってプレビュー定義の簡素化と、UIKitのView/ViewControllerのプレビューがサポートされました。またXcode 16ではstatic framework内でのプレビューもサポートされるなど、年々進化しています。

私たちが開発しているアプリにおいても、Xcode Previewsの導入によるUI構築の高速化、開発者体験と開発生産性の向上を目指して、部分的に試行されていました。そのアプリは非常に大規模なマルチモジュール構成で、アプリの起動速度を速くするためにdynamic frameworkではなくstatic frameworkを使用しているため、そのままではプレビューを使えませんでした。一時的にdynamic linkに設定変更してプレビューを使う試みもありましたが、しばらくするとビルドできなくなっていることもしばしば。

先述のXcode 16でのstatic frameworkサポートにより、アプリの起動速度の高速化とXcode Previewsの両立ができるようになりました。しかし実際に検証を始めてみると、特定の条件下でプレビューがクラッシュするなど、導入は一筋縄では行きませんでした。本トークではそうした実際の課題と解決策をケースごとに解説し、どのように実用化に至ったのかを紹介します。またXcode Previews活用の現状と今後の展望についてもお話しします。

iOS18でQRコードが生成できない───ッ！？

この事件は、文字列として扱われる16進数を、QRコードにData型として渡せるようにそのまま16進数に変換する際に、nilが返ってくるようになっていたことで起こっていました。
この事件の真相とは如何に。そしてこの問題を解決する過程で得たデータ変換のテクニックとは───

また、第2の事件も勃発します。表示はできるけど読み取れない───ッ！？

QRコードには様々な仕様が存在し、仕様が満たせないと読み取ることができないのです。
しかしiOSにおいてQRコードの生成には一般的にCIFilterのCIQRCodeGeneratorを使用しますが、これはQRコードに含めるデータと誤り訂正レベルしか指定することができません。
どのようにQRコードの仕様を満たせば良いのか───そのテクニックを紹介します。

話すこと

• 16進数関連のデータ型変換
• Foundationの実装変更による影響
• QRコードの仕様を満たすためのデータ変換

Flutter を扱う上でもっとも悩まされる要素のひとつに「状態管理」が挙げられます。

Flutter にはローカルな状態を扱う StatefulWidget とグローバルな状態を扱う InheritedWidget という仕組みが標準で用意されているのですが、これだけでは対処しづらいアプリ開発の課題と解決策が長年議論されてきました。その結果、 Riverpod や Bloc をはじめとするサードパーティのパッケージ（ライブラリ）が開発・公開され、ざっと挙げただけでもその数は 50 をゆうに超えています。

一方で SwiftUI に目を向けると、@State や @EnvironmentObjectをはじめとする標準の property wrapper で状態管理を簡潔に行えるため、追加でライブラリを導入するということは少ないようです。

そんな状況の違いはあれど、「不要になったデータを適切に破棄したい」「非同期処理を伴う状態を過不足なく表現したい」「状態の生成・更新処理を抜き出してテストしたい」といった、「状態管理」という共通の観点において発生する課題には共通する部分も多いはずです。そしてその課題を解決するためのアイデアは多く知っておいて損はありません。

「数え切れないほどのパッケージが存在する」ということは、「数え切れないほどの議論とアイデアがそこで生まれてきた」ことを意味します。このトークでは、そんな Flutter が時間と労力をかけて議論してきた状態管理の課題とその対処法を、「50 を超えるサードパーティのパッケージ」のドキュメントとソースコードを私が読んで得た知識と経験を元に整理して共有します。

それにより、アプリ開発において発生し得る課題と対策案を先回りして知ることができる、そんな発表を目指します。

QRコードには様々な仕様が存在していることをご存知ですか？
例えば、QRコードを構成するセルの数を「バージョン」と呼び、バージョン1から40までの規格が定義されています。

iOSでQRコードを生成するとき、一般的にCIFilterのCIQRCodeGeneratorを利用します。
しかし、このCIQRCodeGeneratorで指定できるパラメータは、QRコードに含めるデータと誤り訂正レベルの2つだけに限られています。
世の中のQRコード読み取り端末によっては、特定のQRコード仕様のものしか読み取れないことがあります。では、どのようにしてQRコードの様々な仕様を実現したら良いでしょうか？

本トークでは、QRコードの仕様を紐解くことで、iOSで自由自在に仕様を満たしたQRコードを生成する魔術を伝授します。

• CIQRCodeGeneratorの挙動を利用したQRバージョンの操作
• 誤り訂正を利用した疑似フレームQRコードの生成
• 分割QRコードの生成

このトークを通して、iOSにおけるQRコードマスターを目指そう！

UIKitで作られたアプリにSwiftUIを導入する際の具体的な方法を知りたくありませんか？
開発中のUIKitプロジェクトにSwiftUIを取り入れた経験をお話ししたいと思います。
私たちのプロジェクトでは、ローカル地図機能(NaverMapSDK)を使うために、主要な部分をUIKitで構築する必要がありました。しかし、SwiftUIについて学ぶうちに宣言的UIの魅力に惹かれ、現在のアプリにどう適用できるかを模索しました。
試行錯誤の末、UIKitとSwiftUIを適切に組み合わせた「ハイブリッドな構造」を考案し、幾度かの設計改善を経て、プロジェクトへのSwiftUI導入に成功したのです。
本トークセッションでは、導入にあたっての課題や試行錯誤、そして実際に得られた知見について、実践的な観点からお話しさせていただきます。

<アゼンダ>

• Shucleアプリの概要
  • 使用した技術スタック
  • プロジェクトの構造
• プロジェクトへのSwiftUI導入
  • アプローチ案
  • 最終デザイン案
  • 試行錯誤を含む開発秘話

普段開発でCoreLocationを使っていますが、常に位置情報を更新すると多くのバッテリー消費をしてしまいアプリ削除される要因になってしまいます。逆にバックグラウンド時は何もしないと位置情報を扱うアプリでは思うように位置情報の取得ができずに体験を損なうことになります。そこでバッテリーを抑えつつ、必要な情報を取得するTipsをお話できればと思います。具体的に、ジオフェンスの入出、LocationPushの活用、速度に応じたDistanceFilterの可変、AppDelegateのLaunchOptionを活用したバックグラウンド起動時の工夫について詳しく解説します。

iOS アプリで位置情報トラッキングを実装する際、意識すべきなのがバッテリー消費の効率化です。
位置情報を扱うには Core Location フレームワークの利用が欠かせませんが、デフォルトパラメータのまま使用すると、1時間で20%以上のバッテリーを消費することがあります。
特に位置情報をバックグラウンドでトラッキングするような常駐アプリでは、バッテリー消費はユーザー体験に大きな影響を与えるため、チューニングが必要になってきます。

チューニングにあたってはアプリのユースケースに応じた適切なアプローチを選択することが重要です。
例えば、目的地に近づいたら通知を出すようなアプリの場合、位置情報の精度を落とすことでバッテリー消費を低減できますが、精度によっては反応が遅れたり、通知されない問題が出てきてしまいます。

本セッションでは、ユースケースごとにバッテリー消費を抑えつつ位置情報をトラッキングするための最適な方法を、これまでの開発で得た知見を交えてご紹介します。

内容:

• Core Location の基本実装とバッテリー消費のメカニズム
• バッテリー消費を抑えるためのアプローチ
• ユースケース別の実装方法
• バッテリー消費を半減させたチューニング事例

対象者:

• 位置情報を使った iOS アプリを開発している、またはこれから開発を始めようと思っている方
• 位置情報アプリのバッテリー消費に課題を感じ、改善策を探している方

SwiftはiOSやmacOS開発だけでなく、サーバーサイドやLinux環境でも活用されています。このトークでは、そのSwiftを用いてオープンソースゲームエンジンGodotを活用する方法を紹介します。

Godotは軽量でありながら本格的な2D/3Dゲームエンジンです。iOS、Linux、macOS、Windowsプラットフォームへのエクスポートが可能です(※)。Godotの標準言語は独自スクリプト言語GDScriptおよびC#ですが、GDExtensionという仕組みを通じてほかの様々な言語でも開発が可能です。SwiftGodotは、このGDExtensionによってGodotのAPIにアクセスできるようにした「言語バインディング」です。Swiftで直接ゲームロジックを記述できるため、型安全性やモダンな言語機能を活かしながらのゲーム開発が可能になります。
(※ Godot自体はWebや各種コンソール機へのエクスポートも可能ですが、現時点でSwiftGodotを利用した場合での確認がされていないものについては列挙を避けました。)

実際に開発したカジュアルゲームのコードとデモを通じて、SwiftGodotの導入方法や基本的な使い方を解説し、ゲーム開発に踏み出す第一歩をお手伝いします。Swiftの新たな活用方法として、マルチプラットフォームなゲーム開発という選択肢を探ってみましょう。

Siri、Spotlight、ショートカット、Widget…。近年のiOSでは、アプリのUIに触れなくても機能を呼び出す手段が増えています。
その中心にあるのが「App Intents」です。
本セッションでは、App Intentsの基本的な仕組みとiOS 18以降で広がった用途を紹介しながら、「今、自分のアプリでどう使えるのか」がイメージできるようになることを目指します。

App Intentsはアプリの機能やデータを構造化して、Siri・Spotlight・ショートカット・Widgetなどから呼び出せる形で公開できるApple公式のフレームワークです。
自然言語や検索、トリガー操作を通じて、アプリを“意図”で動かすための仕組みと言えます。

本セッションは「App Intentsを実際に導入したことがない」iOSエンジニアを主な対象とし、以下の内容をお話しします：

・App Intentsの実装方法
・SiriやSpotlightなど、各文脈でのIntentの使われ方
・iOS 18やiOS 26で追加された新たな統合先（Apple Intelligence・Widgetなど）
・実装時につまづきやすいポイントと回避方法

App Intentsはまだ一般的とは言えませんが、Apple Intelligenceとの統合が進む中でアプリの呼ばれ方・見つけられ方を根本的に変える技術です。
今後、App Intentsを書くことが“公開インターフェース”の設計になる時代に備えて、まずは基本と導入の第一歩を押さえてみませんか？

iOS 17以降に登場したAssistive Accessは、主に認知障がいのある方々に向けて設計されたアクセシビリティ機能です。
Appleらしい洗練されたUIを保ちながらも、情報量を制限し、最も重要な機能にフォーカスするこの仕組みに触れて、多くの開発者が「UIにおける認知負荷」について再考するきっかけを得たのではないでしょうか。

本セッションでは、認知にやさしいUIとは何か？という問いを出発点に、Assistive Accessが示した設計原則やSwiftUIによるアプリ実装の手法を通して、日々のアプリ開発に活かせる設計の考え方を掘り下げます。
また、iOS 26から導入されたAssistiveAccessシーンタイプやaccessibilityAssistiveAccessEnabled環境値を活用した表示分岐など、SwiftUIでAssistive Accessを取り入れる具体的な方法も紹介します。

さらに本セッションでは、Assistive Accessの背景にある設計思想を心理学やHCI研究の文脈から深掘りします。
認知負荷理論やヒックの法則を手がかりに、「選択肢を絞る」「明確な誘導を行う」といったAssistive Accessの設計要素を理論的に捉え直します。

また、非言語表現の設計や状態変化の制御といった細部にも注目します。
例えば、「アイコン＋ラベル」の併用による視認性向上、操作不能なジェスチャーの排除、破壊的なアクションへの再設計など、認知的ハードルを下げる工夫は通常のアプリ設計にも多く応用可能です。

このセッションを通して、認知に配慮したUIとはどうあるべきかを理論と実践の両面から捉え、支援技術の知見を一般アプリの設計改善へと活かす視点を得ていただければと思います。

Swift 6の導入に苦労している現場が多い中、Swift言語はすでに次のステップへと進み始めています。
Swift 7では5つの「Upcoming Feature Flags」がデフォルトで有効化され、型システム、モジュール設計、並行性の挙動において重要な変化が生じます。
本セッションでは、これらの変更がどのような文脈で導入されようとしているのかを、Swift Evolutionの提案に基づいて読み解きます。

（現時点で）対象とする機能は以下の5つです。
・ExistentialAny
・InternalImportsByDefault
・MemberImportVisibility
・InferIsolatedConformances
・NonisolatedNonsendingByDefault

それぞれの機能は、単なる文法変更ではなく、型安全性・依存性の明示・並行性制御といった観点で、Swiftの設計上の一貫した方向を示唆するものと捉えられます。
本セッションではそれぞれの提案が登場した背景や、過去の関連するSwift Evolutionとの関係性を整理しながら、言語仕様の変化を体系的に理解する手助けを目指します。

また、これらのUpcoming Feature Flagsを事前に有効化する方法として、SwiftPMやXcodeでのフラグ指定方法についても簡潔に紹介します。
日々の開発に無理なく取り入れながら、将来の言語仕様変更に備える知識を得られる構成です。

将来のSwiftを正確に予測することはできなくとも、これらの仕様変更を通じて言語が解決しようとしている課題や、設計上の一貫性を読み解く視点は、日々のコード設計にも役立つはずです。
Swift 7の未来を一歩先取りし、変化を安心して迎えるための材料を共有します。