プロポーザル

Swift Testing は Swift 言語でユニットテストを行うためのフレームワークです。昨年リリースの Swift 6 に組み込まれました。本トークでは、既存プロジェクトに Swift Testing を導入し、実践的に活用していく方法を説明します。

Swift Testing は従来のテストフレームワークである XCTest と共存できるため、既存プロジェクトへの導入がしやすくなっています。新しくユニットテストを追加するタイミングが、最も Swift Testing を導入しやすい機会でしょう。あるいは、既存のユニットテストを Swift Testing で書き換えるのも難しくはありません。

しかし、XCTest と Swift Testing とでは挙動が異なる場合もあるので注意が必要です。例えば、Swift Testing ではデフォルトでテスト実行が並列処理となるため、単純な移行ではテストが失敗することもあります。また、非同期処理のテストにも考慮すべき点があります。これらの課題に対し、どのような注意が必要で、どう対処すれば良いかを具体的なコード例とともに解説します。

さらに、Swift Testing の特徴的な機能であるパラメトライズテストの導入方法と、それによって得られるメリットについても実例を交えて紹介します。効果的に活用することで、既存のテストコードを整理し、より保守性の高い形に進化させることができます。

本トークを通じて、Swift 6 時代のモダンなテスト手法を身につけ、iOS アプリ開発の品質と開発効率の向上につなげましょう。

「APIの開発が遅れていてアプリの開発が進めづらい…」

「このエッジケースの動作確認、どうやって確認しよう？」

「バグが検出されたけど、再現が難しい…」

多くのモバイルアプリ開発現場が、このような課題を抱えているのではないでしょうか。

これはエンジニアの開発作業だけにとどまらず、PdM やデザイナー、QAメンバーにとっても悩みの種となっていました。
アプリの最新仕様の動作確認がスムーズに行えないことで、仕様検討に時間がかかったり、デザイン作成やテスト設計において考慮漏れが発生したりすることがあります。

こういった問題により、職種間のコミュニケーションコストに悩まされ、結果として開発全体のリードタイム増大に繋がっていました。

この根深い課題を解決すべく、iOS / Android アプリで共通の仕組みで利用できる Mock 環境「Hobart」を開発しました。

「Hobart」はエンジニアだけでなく、PdM・デザイナー・QAメンバーなど他職種の方々の業務効率の向上に寄与しています。

下記を中心に、モバイルアプリ開発全体を支える Mock 環境についてお話します。

• モバイルアプリ開発における開発効率低下の要因
• 「Hobart」の仕組みとそれを支えるデバッグモードの全貌
• 生成AIを活用した Mock データ整備の高速化
• 「Hobart」導入後の成果と今後の展望

「一つのコードベースから、複数の異なるアプリを自動生成する」
そんな仕組みが、本当に現実的に運用できるのか？

本セッションでは、ブランドや機能構成が異なる複数のアプリを、単一のSwiftコードベースから自動生成・リリースする仕組みを、設計から実装・運用まで具体的に解説します。

これは単なるテンプレート共有ではなく、iOSアプリを「構成可能なプロダクト」として再設計し、設定情報をコードの外に追い出し、非エンジニアも含めた運用を可能にする仕組みを作る取り組みです。

このセッションでは、以下の実践知を共有します：

・アプリを「構成」として捉える：コードの中に潜む「差分」をどう抽出し、再設計するか
・XcodeGenとFastlaneによる“生成”の自動化：プロジェクト構造の動的生成とビルド・署名の統合
・設定情報をコード外部に逃がす：API経由で注入するApp Metadataとそのセキュリティの考慮
・エンジニア以外でも使えるUI設計：管理画面を介したノーコードな運用ワークフロー
・プロダクトとしての“スケーラビリティ”：技術的負債を生まないための運用と設計戦略

アプリを“作る”という行為を、どうやって“仕組み化”に昇華させたのか。そのプロセスと工夫を、実践ベースでお話しします。

身分証をApple Walletをはじめとしたデジタルウォレットに搭載する動きが、近年世界的に広がっています。アメリカでは一部の州において、州発行の運転免許証の搭載が進んでいます。各国での実証実験が進行しており、これらはISO/IEC 18013-5や-7、23220といった国際標準で定められ、セキュリティやユーザープライバシーに配慮しながら世界中で互換性を持たせる動きが進んでいます。
こうした流れの中で、2025年6月24日から、日本でもiPhoneへのマイナンバーカードの搭載が始まりました。Apple WalletにNational IDを搭載するのは、日本が世界で初めての事例であり、デジタル庁とAppleとの協業によって実現されました。
マイナンバーカードを持っていれば、誰でもApple Walletにmdoc（Mobile Document）として搭載することができ、iPhoneだけでさまざまな行政サービスを利用できるようになります。
これに限らず、開発者もAppleが提供するID Verifier APIを使えば、自分のアプリに年齢確認や本人確認といった機能を国際標準に準拠した形で実装することが可能です。たとえば、酒類購入時の年齢確認や、オンライン口座開設時の本人確認など、民間サービスへの応用が期待されています。
このトークでは、「iPhoneのマイナンバーカード」を活用し、アプリ内、対面、ブラウザの3種類のVerifier APIの使い方とユースケースを紹介します。
また、mdocとはそもそも何であるか、そのデータ構造と検証手法など実装詳細にも触れていきます。
さらに、電子証明書をiPhoneから取り出して利用できる日本のために作られたAPIについても紹介しながらBehind the Sceneにも少し触れてみたいと思います。

コードレビューは、チーム開発における品質担保と知見共有のために不可欠なプロセスです。しかし、「何を指摘すべきかわからない」「観点が人によってバラバラ」「レビューに時間がかかりすぎる」といった悩みは、多くのチームが抱える共通の課題ではないでしょうか。

本セッションでは、iOS開発の現場で実際に起きやすいコードレビューのつまずきやすいポイントを整理し、具体的なコードをもとに「どのような観点でコードを見ればよいのか」を実践的に学びます。たとえば、ViewとModelの関心の分離、命名、非同期処理での注意点、コードスタイルの一貫性、パフォーマンスやセキュリティに関する観点などの多角的な視点を紹介します。

また、「良いレビューコメントとは？」「手戻りを防ぐにはどうすればいいか？」といった、設計やコミュニケーションにも関わる問題についても触れ、レビューの“質”を高めるためのノウハウを提供します。

さらに後半では、効率的なレビューを支援する手段として、AIを活用したコードレビューの手法についても紹介します。GitHub CopilotなどのAIレビュー支援ツールを用いることで、開発者はより本質的な設計や意図の確認に集中する「人とAIの協調によるレビュー」の可能性についても紹介します。

このセッションを通じて、コードレビューの観点を整理し、チーム全体でレビューの質と効率を高めるための実践的なアプローチを学べます。このセッションが、明日からのコードレビューを飛躍させるヒントになるはずです。

セッション内容（予定）

• なぜコードレビューはうまくいかないのか
• コードレビューの7つの観点
• コードレビューでのコミュニケーション
• コードレビュー実践ワークショップ
• 技術育成のためのコードレビュー
• チームで更なる生産性を高める
• 生成AIを用いたコードレビューの最適化

本トークでは、iOS SDK を Swift Package Manager（SPM）+ XCFramework によって構成・配布する設計と、その実運用で得た知見を紹介します。

実際に筆者が提供する SDKを題材に、次の観点から掘り下げます：

• 複数モジュール構成（Core / App / Tracking など）の分離と依存関係の整理
• ライブラリの再利用性を高めるためのディレクトリ構成と Swift Package の切り方
• XCFramework による iOS / Simulator 対応
• BuildTools モジュールを使った SwiftLint / SwiftFormat の一括適用
• 内部で持つUIライブラリにおけるアセット管理のはまりどころ
• 「使う側」にとって安全・簡単に導入できる Package の設計原則

「SDK を作る」こと自体が目的ではなく、「チームで再利用できて、組織として持続可能な仕組みを作る」ことがテーマです。

ライブラリ開発初心者はもちろん、「現場で自作 SDK のメンテ地獄に陥ったことがある人」や「SPM の限界を見極めたい人」にとって、ヒント満載の内容となっています。

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

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

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

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

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アプリ開発者としての姿勢について考えるきっかけとなれば幸いです。

旧ログシステムから新しいシステムへ移行する際、新システムにはiOS SDKが提供されておらず、なんとログ基盤を自作することに！
そんな大規模なサービスの基盤を構築することは、実際にはそれほど怖くありません！
このセッションでは、5000万ダウンロード規模のiOSアプリにおけるログ基盤移行の実践事例を紹介します。

このセッションでは以下の内容について詳しく説明します。

• 行動ログを取るために必要な知識、仕様、注意点
• 完全なテストカバレッジを前提としたインターフェース設計
• 移行に向けた既存実装の整理と置き換え戦略
• Firebase Remote Configを用いたリスクを抑えた段階的リリースプラン
• 完全Swift 6の実装

このセッションを通じて、中〜大規模サービス基盤刷新の具体的な手順と注意点を理解し、実践に役立てていただければ幸いです。

モーダルはiOSアプリで情報表示、注意喚起また選択肢の提案などユーザーへの表示としてよく使われます。
皆さんも一度は設定したことがあるでしょう。

他のプラットフォームのWebやAndroidに目を向けてもさまざまなサービスで多様な形で導入されており、
モーダルという言葉だけで画面の一部または全面にユーザーへの情報の提示がされることが開発者だけでなくサービスに関わる人であればわかる様な言葉になっていると思います。

しかし一口にモーダルと言っても、導入目的や背景によって様々なモーダル導入の手段があります。
例えば、Mapアプリなどでは下半分モーダルの表示がありながらも地図の操作をすることができたり、
iPadの動画アプリでは動画を流しながらも右のスペースにだけコメントや動画の情報が表示されたりと、
その使い方はモーダルのようでありながら、ユーザー操作を妨げないモーダレスなデザインも存在します

本セッションではhuman-interface-guidelinesで言及されているmodalityの内容また、
私のMapアプリや動画アプリでのモーダル導入経験から
モーダルウインドウのような表示をどのようにアプリに組み込むべきか？をサンプルコードを用いて、実際のアプリケーションでモーダルをどのように実装するかを学びます

目次

• モーダルとは？
• どのようにモーダルはサービスで使われているか？
• 様々なmodalityな表示
• モーダルデザインの課題と解決策 ~ 標準のAPIでは表現が難しいモーダル例~
  • アプリの動作を止めないモーダル
  • 特殊なUI表示のモーダル
• まとめ