トーク

最近、フル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を安全かつ効果的に適用できるロードマップを描けるようになります。

教員時代に、学校で使えるアプリをなんか作れないかな？
そう思ったのが僕の個人開発のスタートでした。

たまに停滞しつつもコツコツと個人開発を続け、現在累計DL数は9万を超えました。
開発の過程で、ダウンロード数が伸びたり、アクティブユーザーが増えたり、収益が上がったり、ユーザーから直接フィードバックをもらえたりと、様々な喜びや発見がありました。これらの経験を通して、個人開発の「面白さ」を強く感じています。

この記事では、私が見つけた個人開発の「面白さ」を皆さんにお伝えしたいと思っています。具体的には、以下のポイントについて記載する予定です。

本記事で紹介予定の内容

• 何に面白さを感じたのか
• 個人開発を続けるために意識したこと
• アプリの収益を伸ばすために試したこと

このトークを通じて、皆さんが新たに個人開発を始めてみよう、あるいは一度止まってしまったプロジェクトを再開しようと感じていただけたら嬉しいです。ぜひ、個人開発の魅力を一緒に発見しましょう。

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

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

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

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

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

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

iOSDC Japan参加者のみなさんなら、きっとiPhone、iPad、MacBookを持っていますよね！人によってはVision ProやHomePod、Apple TVもお持ちかもしれません。
私達にとっては仕事道具ですが、世間ではAppleプロダクトを使用していることは一種のステータスとも捉えらており、「おしゃれ」や「スタイリッシュ」の代名詞の一つということもできます。

そしてさらにこのスタイリッシュさは「無国籍」です。アメリカでも日本でも、喫茶店でMacBookを広げた姿は国を問わずスタイリッシュと言えるでしょう。
そのため私達はこれらAppleプロダクトを持っていれば世界中どこの国でも「スタイリッシュ」に仕事をすることができます。

でも、なぜAppleプロダクトは世界中どこで使っても「スタイリッシュ」なのでしょうか？

ソフトウェアのUI/UXの良さでしょうか？それともハードウェアのデザインが良いからでしょうか？
もちろんAppleプロダクトはソフトウェアのUI/UXは良いですし、ハードウェアのデザインも最高です。

実は、Appleプロダクトがそのイメージからは一見無関係に見える「建築」の世界からきた「素材」によってもスタイリッシュさが支えられていますとお話したら驚くでしょうか？

このLTではみなさんと一緒にモダニズムの生い立ちと、私達ソフトウェアエンジニアには意外に見えるガラスやアルミニウムといった「素材」の2観点から、Appleプロダクトがスタイリッシュに見える理由を深堀りします。
ソフトウェアエンジニアである私達が普段は見落としがちな「素材」という現実世界の要素が、なぜ「スタイリッシュ」に繋がっているのかを知ることで、皆さんの「プロダクト」作りに素材という新たな視点をもたらすことができれば幸いです。

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

SwiftUIでのUI構築において、GeometryReaderとScrollViewは画面サイズや位置情報を活用した柔軟なレイアウト制御に不可欠なコンポーネントです。しかし「思ったように動かない」「SafeAreaやネスト構造でレイアウトが崩れる」といった課題に直面する開発者も多いのが現状です。

本セッションでは、これらのコンポーネントの動作原理を基礎から丁寧に解説し、実務で遭遇する典型的な問題とその解決策を具体的なコード例とともに紹介します。特に、GeometryReaderの座標系の理解、ScrollViewのオフセット制御、パフォーマンス最適化の観点から、正しい使い方と避けるべきアンチパターンを明確化します。

さらに、PreferenceKeyやAnchorPreferenceなどの代替技術との使い分け、実際のプロダクトで活用できる応用パターン（カスタムスクロールエフェクト、動的レイアウト調整など）も解説し、SwiftUIらしい宣言的UI設計のベストプラクティスをお伝えします。

初学者のつまずきポイント解消から、中級者以上の設計力向上まで、幅広いレベルの開発者にとって実践的な知見を提供し、日々の開発業務で即座に活用できる内容を目指します。

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の性能評価や比較
• 基礎的な音声処理理論

εε＝┌|▼▼|┘ ｳｯﾎｳｯﾎ

Xcodeは素晴らしいIDEって伝えなきゃ

ｳｯﾎｳｯﾎ └|▼▼|┐＝33

本LTでは、Xcodeの素晴らしいところをウホフクロウが軽快に紹介します。
5分間でXcodeをより快適に使えるようになるはずです。

●話すこと
・Xcodeの素晴らしいところ

●話さないこと
・Xcodeの素晴らしくないところ

ウホフクロウを生暖かい目で見守ってくれると幸いです。

iOS アプリの開発において、Xcode 標準の静的解析機能は便利です。しかしながら、開発チーム独自のルールやアクセス制限など細かな要件を十分にカバーすることは難しいです。

本記事では、SwiftLint のカスタムルールを活用して、静的解析を強化する方法を紹介します。非推奨メソッドの使用制限や、アクセス範囲を特定のファイルやディレクトリ内に絞り込むことなどを可能にし、コード品質と保守性の向上を図るための考え方と実践的な導入手法を解説します。

WWDC 2025で待望のSwiftUI向けWebKitが発表され、SwiftUIでWebViewを扱いやすくなりました。
WKWebViewには多くのプロパティやView操作のメソッドがあるため、宣言的UIに適合させるのは容易ではありませんでした。
例えば進む/戻るボタンの表示制御や、ナビゲーションの動作にはWKWebViewへのアクセスが必要です。

SwiftUI向けWebKitでは、WKWebViewを持つWebPageクラスをStateとして扱うことで、WebViewをStateの写像として宣言的に記述できるように設計されています。

一方、私たちはこれまでWKWebViewを宣言的に扱うためのライブラリとして、cybozu/WebUIを設計・公開してきました。
WebUIではproxy APIを通じてSwiftUIからWKWebViewにアクセスできるよう設計しています。

本トークでは、WKWebViewの宣言的UIへの適合を例として今後のSwiftUIに最適なインターフェース設計の指針を提供します。
SwiftUI向けWebKitとWebUIの設計を比較して、よりSwiftUIらしい宣言的なインターフェース設計を掘り下げます。
また、ObservationとObservableObjectの変更監視の機能差から、「なぜ今SwiftUI向けWebKitが登場したのか」についても考察し、これからのインターフェース設計に必要な技術要素にも言及します。

本トークを通じてこれからのSwiftUIインターフェース設計指針と技術的背景について学びます。

対象者

• 宣言的UIの設計原則を深く知りたい開発者
• UIKit ViewのSwiftUIラッパー提供者
• SwiftUIで複雑な状態を扱うView設計者

話さないこと

• 今後のWebUIの開発方針

LLMエージェントによるコーディングが民主化されたことで、プログラミングに新しい時代が到来しました。"Vibe Coding" という言葉が生まれ、多くの人が数行のプロンプトだけで実際に動作するアプリやWebサイトができあがってしまうのを体験しています。

その中で、こう思われた方もいるでしょう。「で、これを仕事で真面目に使うにはどうしたらいいんだ？」と。

詳細はお任せでゼロから適当に作らせればいい個人の遊びとは違い、業務としてのプロダクト開発には例えば以下のような制約やルールがあります。

• 機能要件が予め詳細に決まっている
• デザイン資料の通りにUIを実装する必要がある
• コーディングルールがある
• gitのブランチ運用など開発フローに関する決まりごとがある

本セッションでは、Anthropic社が提供するClaude Codeを実際にiOSアプリの開発業務で活用し、その中で得られた実践的なノウハウをお話します。

• Webアプリを作るのとは違う、iOSアプリ開発ならではの難しさに立ち向かう
• コンテキストが長くなることによる性能低下を防ぐために適度に記憶をリフレッシュする
• 要件定義と実装の工程を分けることで並列に進められるようにする
• AIエージェントをチームの一員として迎え入れるための準備
• プロンプトで指示しても無視することがあるのを、ToDoリスト機能で確実に実行させるようにする

このセッションで、業務にClaude Codeを組み込む際のコツを知っていただき、LLM時代のiOSアプリ開発者としての姿勢について考えるきっかけとなれば幸いです。

SwiftはもともとiOSを中心に発展してきた言語ですが、最近ではその適用範囲が広がり、小型ゲーム機「Playdate」でも活用できるようになりました。

本セッションでは、白黒ディスプレイと物理ボタン、手回しクランクを備えたミニマルなゲーム機「Playdate」を題材に、その開発手法をご紹介します。Appleが新たに公開した「swift-playdate-examples」を活用することで、Swiftを用いてPlaydate向けのゲームを開発する環境が整いつつあります。

開発環境の構築手順を解説し、制約の多いデバイスで直面する独自の課題を取り上げながら、シンプルなゲームを作成するプロセスを共有します。さらに、リソース制限下でのSwift開発に役立つ実践的なヒントをお伝えし、実際にSwiftで制作したPlaydateゲームをデモします。

クリエイティブコーディングやゲーム開発に興味がある方、そしてSwiftの新たな可能性を探りたい方に向けて、iOSアプリの枠を超えたSwiftの魅力を、遊び心あふれる視点でお届けします。

【セッショントピック予定】

• swift-playdate-examples の概要
• Swift製ゲームをPlaydateで動かすための構築手順
• クランクや物理ボタンによるインタラクション設計
• リソース制限下でのゲーム開発における工夫とテクニック
• 制約された環境だからこそ見える Swift の柔軟性と強み

「このアプリ、自分に使える？」
そんな問いに応えるのが、WWDC25で発表されたAccessibility Nutrition Labelsです。
これはVoiceOverやSufficient Contrast、Captionsなどに対応しているかどうかが食品の栄養成分表示のようにラベル形式で表示されるもので、ユーザーはアプリのダウンロード前に自分に合ったアプリかどうかを判断できるようになります。

開発者はApp Store Connect上でアプリのアクセシビリティ機能対応状況について登録でき、その内容がAccessibility Nutrition Labelsとして表示されます。
今後このラベル表示は新規アプリやアップデート時に必須化される予定で、Appleは明確な評価基準や申告手順をガイドラインとして公開しています。
たとえばSufficient ContrastはWCAGの推奨コントラスト比（4.5:1以上）を満たしているかなど、項目ごとに具体的な条件が示されています。

このトークでは、Accessibility Nutrition Labelsの概要や各項目の評価基準を整理した上で、iOSアプリでこれらの基準をどのように満たすか、具体的な実装例を交えて紹介します。
VoiceOver対応のための accessibilityLabel や accessibilityHint、Dynamic TypeやReduce Motionといったシステム設定への対応などの実装方法に加え、XcodeのAccessibility Inspectorを活用した検証手法も解説します。

アクセシビリティは一部のユーザーのためだけの機能ではなく、誰もが恩恵を受けられる設計原則です。
このトークを通じて、あなたのアプリの「アクセシビリティ健康診断」を始めてみませんか？

シニアエンジニアに必須の能力はなんだと思いますか？そうですね、WWDCでの引率能力ですね。後輩たちを博物館や交流会へ連れていきApple Parkへ辿り着かなくてはいけません。
そこで選択肢に挙がるのがレンタカーです。ライドシェアより安く済み、アジア人女性150cmの私が知らない人の車に乗る不安からも解放されます。自動運転タクシーはエリア外だしサービス一時停止してたし。
とはいえ異国での運転は楽ではありません。ご想像の通りの右側通行左ハンドル。愛車の倍の体積のアメ車。そして日本とは違う道路のつくり。ペーパードライバーを脱して1年ですが運転しないことにはスキルが身につきません。やっていきましょう💪

本LTでは、スキルアップのため私がアメ車に初挑戦した経験をもとにサンノゼの交通事情を紹介します。
CarPlay（アメリカのすがた）にも触れますよ！さっそくCarPlayからお昼のピザの注文を……えっ？電話じゃないと注文できないの？？ていうか数百メートル先にHazard Aheadってなになに！？！？

話すこと

• 日本との違いは右側通行だけじゃなかった…
• 助手席からあるとありがたいサポート
• アメリカのCarPlayを研究だ🔍

対象者

• 観光や交流もしなくちゃもったいないと思っている人
• 正直ライドシェアに乗るのが怖い人
• アメリカにおけるCarPlay（navigation, quick food ordering）に興味がある人🍕

私はSwiftUI学園２年生のまつじ！

今日は転校生が来るって聞いてたのに遅刻遅刻〜〜！ViewHierarchyを口に挟みながら走ってたら角から出てきたコに...！キャッ！ぶつかっちゃった
もうなんだったの！あいつ！ってイライラしながらホームルームに出席すると...! 転校生ってあいつじゃん!

freddi先生新作。ドタバタ☆恋愛コメディ！始まる三角関係！UIViewControll太くん！私のためにあいつと争わないで〜〜〜〜〜

どっきどき！学園モノ４コマ漫画「SwiftUI学園 ~発動編~」堂々のスタート！

ますますグローバル化が進み、海外からのリクルートも活発になっている現状を踏まえ、多くの技術者が英語力の向上を求められています。そんな中で英語学習に苦労している方々に向けて、WWDCの動画を活用したシャドーイング学習法を紹介します。発表者は元英会話講師であり、その経験を活かして、効果的な英語学習法をお伝えします。シャドーイングは、リスニングとスピーキング能力を同時に鍛える効果的な方法であり、特に最新のiOS26に関するWWDCセッション動画を教材として使用することで、英語力と技術知識を同時に習得できます。

具体的には、シャドーイングのやり方、効果、そしてシャドーイングを継続するためのモチベーション維持のコツや、効果を最大化するためのテクニックを共有します。元英会話講師としての視点から、実践的なアドバイスや学習のヒントも提供します。このトークを通じて、参加者は英語学習と技術習得を同時に進める新しいアプローチを体験し、WWDC動画を活用した学習の楽しさと有効性を実感できるでしょう。英語力を向上させたい方、WWDCの動画たまってるな〜という方、そして効率的な学習法を探している方にとって、ぜひ聴いていただきたい内容です！

2022年に公開されたApp Intentsですが、皆さんはもう活用されていますでしょうか？

最近のmacOS TahoeではSpotlightからの活用が可能になり、App Intentsの用途は着実に広がっています。しかし、カンファレンスや実際のアプリケーションで話題になることは、まだ少ないと感じます。

本トークでは、まずApp Intentsの概要とその基本的な利用方法を振り返ります。
その後、App Intentsに対応することでAppleエコシステムがどのように発展していくのかを考察します。

現在、MCPやモデル性能における大競争が繰り広げられていますが、Appleファンである我々はAI時代にどのように向き合っていくべきなのでしょうか？
このトークを通じて、その考え方の一例を皆さんと共有できれば幸いです。

Cybozuで内定者アルバイトをしている中、テストマイグレーションの一環でSwift Testing、Parameterized Testを導入していた最中、異常なパフォーマンスの低下を検知しました。
なんとその倍率７５万倍?！

これはヤベェ...と独り言をいいながら色々検証した結果ある結論にたどり着きました。
「Xcodeが悪いんじゃね？」
このシンプルな結論にたどり着くまでに考えた、原因探索やそれまでのフローは簡単に調べたら出てくるものではありません。

そこで、このテーマを人生初めてのiOSDC登壇テーマとして
「XCTestからSwift Testingへの移行におけるParameterized Testの採用で75万倍のパフォーマンス低下に直面した件」 についてお話します。

[本セッションで取り上げる内容]

• ParameterizedTestとは何か？（軽く）
• Swift Testing導入中に起きた75万倍のパフォーマンス低下に直面した時どのような対処を取ったのか
• ここで学んだ原因の探索におけるプラクティス

WWDC24から多くのプロダクトのテストを担うようになったテストフレームワークである Swift Testing
参加者の皆さんが関わるプロダクトでも導入が進んでいるのではないでしょうか？
AIによるコーディングの台頭により、今後おそらくもっとテストに対する意識は高まってくるでしょう。

AIで効率化されたナウでヤングでトレンディな開発を行う今！　テストについてのルーキーズLTを "5分だけ" 聞いてみませんか？