プロポーザル

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

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

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

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

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

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

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

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

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

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

本LTでは、単体テストのフレームワークをXCTestからSwift Testingへ移行したいと考えている方向けに、具体的にどのようにSwift Testingへ移行するのかを経験談を交えて紹介します。

WWDC24で新たに紹介されたテストフレームワークであるSwift Testingも、紹介されてから1年以上経ち導入事例も増えてきていると思います。
そのような情勢もあり、まだXCTestで単体テストを行なっているチームでも、Swift Testingへ移行していきたいというモチベーションが高まっているところも多いでしょう。
しかし、実際にSwift Testingへ移行するときにどのように移行するのが良いのか、どれぐらい大変なのかが掴めないとなかなか踏み出しづらいです。

本トークでは、実際に担当しているiOSアプリプロジェクトの単体テストをXCTestからSwift Testingへ移行した経験をもとに、以下内容についてお話しします。

• 実際の単体テストをXCTestからSwift Testingへ移行した手順
• 移行時の工数感
• 移行時に困ったこと

新しいフレームワークを導入するにあたって、メンバーを巻き込んでいく必要がありますが、実際にどのように説得して、導入まで漕ぎ着けたかというところまでお話しします。

実際に移行した経験からSwift Testing移行のよりリアルな知見を共有できると思います！
Swift Testing移行を考えている開発者にとっては、移行を検討する上で大きなヒントになるはずです！

プログラマーの資本と聞いて、あなたは何を思い浮かべるでしょうか？

これまで読んだ技術書の厚み？
経歴書に書ける経験の長さ？
チーム開発でうまくやっていけるソフトスキル？

いいえ、違います。

腰です。
それも健康な、腰です。

プログラマーの真の敵は刻々と変わりゆく仕様ではなく、集中力を阻害する腰痛です。
そんなわけで、健康な腰の維持のために職場や自宅で昇降式デスクを使われている方も多いかと思いますが、本当に「昇」してますか？
スタンディングデスクなのに最後にスタンダップしたのがいつだったか思い出せない人も多いでしょう。
いいえ、あなたを責めているわけではありません。
人間の意志とは実に弱いもので、楽な方に流れていってしまいます。

しかし、ご安心ください。
立つことが億劫になってしまうのなら、スタンディングデスクに一定時間毎に自動で上昇する機能をつけて、仕組みで解決してしまいましょう。
本LTでは、昇降デスク FlexiSpot、コントローラーとなる M5Stack、サーバーとなる Raspberry Pi, スマートホームを実現するOSSのHomeAssistantとを組み合わせて、FlexiSpotをスマホやパソコンから操作したり、時刻やアクションをトリガーに自動で昇降する機能を実現する方法をご紹介します。

【あらすじ】

社内で突然始まった、Swift 6対応プロジェクト。

しかし、iOSエンジニアはたった2人。
そのうちの1人は、「自分でやるのは面倒だから」という理由で、すべてをもう1人に丸投げしてしまう。

重すぎる作業量を前に、残されたiOSエンジニアは1人で抱えきれないと判断し、他部署や他社のiOSエンジニアなど、あらゆるリソースに声をかけて助けを求めた。

「Swift 6対応を乗り切るためなら、手段は問わない」
そうして集まった応援メンバーの協力もあり、プロジェクトは加速度的に進んでいく。

しかしその裏で、誰にも気づかれぬまま、少しずつ歯車は狂い始めていた。

ようやく作業が完了し、落ち着いたかに見えたその時、そのiOSエンジニアの前に現れたのは、思いもよらぬ「代償」だった…！？

このLTは「てんとう虫コミックス ドラえもん5巻収録『ドラえもんだらけ』」のオマージュです。

本LTでは、テストでHealthCareデータの登録が必要だけど毎回面倒と思っている方に向けて、データの登録を簡易に行うアプローチを紹介します。

HealthKitを用いたiOSアプリでは、テストの際にHealthCareデータの登録が必要になるはずです。
しかし、テスト用にHealthCareデータの登録を簡易に行うためのツールはAppleから公式には出ておらず、手動で登録を行うケースも少なくないでしょう。
手動での登録は、テストごとに煩雑な操作を伴うため、特にE2Eテストの自動化においては大きな障害となり、結果的にテストの工数が増加する要因となります。
私の所属するチームでもその課題に直面したため、試行錯誤の末、CLIコマンド一つで指定の端末に必要なデータを自動登録するツールを作成しました。

本トークでは、実際にデータ登録自動化ツールを作成したことと、それを業務で運用してみた経験から、次のような内容についてお話しします。

• CLIでHelthCareデータを登録する仕組み
• CLIでHelthCareデータ登録を実現するときにハマったこと
• 業務で実運用してみての感想

ツールの実装は単なるシェルスクリプトではなく、XCTestやシェルスクリプトを組み合わせて行いました。具体的な実装方法について、ソースコードを交えながら詳しく説明します。

HealthKitを使った開発をしている、もしくはこれからしようとしている開発者にとっては、テストの工数を短縮する上で大きなヒントになる知見を共有します！

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

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

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

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

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

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

チームでの実装・レビュー遅延やレビューコメントの反映漏れに悩んでいた経験から、Cursorを導入し「実装→レビュー→修正」の開発フローを効率化しました。本発表では、以下の８ステップでCursorを活用し、開発速度と品質を両立できたプロセスを技術的に解説します。

1. 実装方針をCursor上で共有し、建設的なイテレーションを回す
2. テストコードの叩きを用意し、細かく調整
3. ビルドエラー・テスト失敗を即座に把握して修正
4. 文言修正タスクへの迅速対応
5. ログ挿入→デバッグ→バグ修正サイクルの確立
6. チャットログから良い実装の振り返り・ナレッジ化
7. PRテンプレートによる統一された提出フロー
8. レビュー対応とCursorを使ったコメント反映の高速化

Cursor導入前後でiOS開発が如何ほど効率化されたか、導入を検討中のチームに即活用できる提案をお届けします。

UIKitで長年運用しているアプリに、SwiftUI画面を一部導入する機会がありました。そこで採用したのが、iOSDC2023で紹介された「SVVSアーキテクチャ（Store・ViewState・View）」です。

MVVMやTCAも検討した中で、なぜSVVSだったのか？ UIKitコンテキストとの親和性、学習コスト、段階導入のしやすさなど、現場目線で感じた「ちょうどよさ」を共有します。

5分という短い時間ですが、SVVSの魅力と、実際にどうやって導入し、どんな課題があってどう乗り越えたかを簡潔に紹介します。SwiftUIを使ってみたいけどまだ一歩踏み出せていない方、UIKitとの橋渡しに悩んでいる方に刺さる話です！

課題は以下のような内容になります。
・チームメンバーへの理解促進（勉強会・ペアプロ）
・エラーハンドリングが煩雑になる問題
・Storeの強みが活かせない問題
・UIKitからSwiftUIへの遷移の違和感
・UIKitのタブが正しく表示されない問題

「SwiftUIなら、きっとサクサク動くはず！」
そう信じて開発したアプリのスクロールがカクついた時、パフォーマンス改善という大きな壁にぶつかりました。「一体何から手をつければ…？」と途方に暮れたのは、きっと私だけではないはずです。

このトークは、そんな私がXcodeのInstrumentsと格闘し、Viewの描画の仕組みやLazyVStackなどの基本的な知識を武器に、"もっさりUI"を改善していくまでの奮闘記です。

本セッションでは、

• ルーキーがつまずきがちなパフォーマンスの落とし穴
• Instrumentsを使ったボトルネック特定の第一歩
• ViewのIdentityやレイアウトの工夫など、すぐに実践できる改善テクニック

を、失敗談を交えながら共有します。
パフォーマンスチューニングは、ベテランだけのものではありません。この発表が、同じ悩みを持つ皆さんの「はじめの一歩」を踏み出すきっかけとなれば幸いです。

Swift Package Manager 5.6から登場した Build Tool Plugin。
ビルド時にコードやリソースを生成できる強力な機能として、登場から3年が経ち、多くのプロジェクトで利用が進んでいます。

そんな Build Tool Plugin、便利さの裏で「あること」を見落としていませんか？

Derived Data に出力される成果物。
それがどこまでアプリに影響を与えるか、普段どこまで意識してビルドしていますか？

今回の発表では、Build Tool Plugin を通して気づいた“とある落とし穴”と、それにまつわる 実体験からの学びを共有します。
思わず「ヒヤッ」としたその出来事、Derived Dataの奥底から灼熱の有明にお届けします。

本トークでは、Appleが公開した研究向け機械学習ライブラリMLXのSwift向けバインディング「MLX Swift」を用いて、任意のモデルをローカルLLMとして動かす手順を解説します。

具体的には、Hugging Faceで公開されている軽量モデルの選定、モデルへのプロンプト送信と応答の取得方法、そして実際にモデルとの対話を行った際の挙動や、処理速度・メモリ使用量など実用面で見えてきた課題や使い所について共有します。

【話すこと】

• MLXとMLX Swiftの概要
• MLX Swiftを用いたローカルLLMの構築と実行までの実装ステップ
• 実際に動かして見えてきた課題とオンデバイスAIの可能性について

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

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

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

＜アジェンダ＞

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

ゲーム開発といえばUnityやUnreal Engineが代表的ですが、学習コストやライセンス費用に不安を感じていませんか？
実はApple純正フレームワークだけでも、ゲーム開発に必要な、接触判定・リアルタイム通信・ランキング・ゲームパッド対応など、実用に足る機能群がすべて揃っています。
さらに最近では、iOSのゲーム体験を高めるための公式機能が充実してきており、ユーザーがゲームにアクセスしやすくなるような変化も見られるため、ゲームデバイスとしてのiOSに注目が集まっています。

このトークは、ゲーム好きですが一般のアプリしか作れなかった私が、純正フレームワークのみでオンライン通信対戦ゲームを完成させ、インディーゲームイベントへの出展を目指した経験をもとに、以下のトピックについてお話しします。

• 使用したフレームワークと用途について
  • SpriteKit：アクションゲームの土台となる描画・アニメーション・接触判定
  • GameKit×GameCenter：オンラインマッチングとリアルタイム通信
  • MultipeerConnectivity：オフラインでも動く対戦通信の構築
  • CloudKit：スコアランキングの保存・共有、セーブ機能
  • GameController：ゲームパッド対応
• インディーゲーム展示イベントへの出展について
  • 出展時の反応や工夫したこと
  • Swift製のアプリの割合

Swiftで業務アプリを作っているあなたも、すでにゲーム開発に必要な材料を持っていたのです──
Apple純正フレームワークだけでもここまで「戦える」ということを、実例を交えてお伝えします。
ゲーム開発は特別なスキルが必要──そんな思い込みを、そっと壊す5分間です。

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

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

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

また、トークでは実際のゲームを用いたデモを通して、通信方式の違いがユーザー体験に与える違いをご覧いただけます。
「サーバ構築せず、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コードマスターを目指そう！

AIツールをコードレビューに導入してみたものの、期待していたほどの効果を感じられない...そんな経験はありませんか？

CursorやGitHub Copilotなど最新のAIツールを組み合わせることで、ようやく「AIが本当に役立つレビュー環境」を構築できました。重要だったのは、AIに全てを任せるのではなく、AIと人間の得意分野を明確に分けることでした。

このLTでは、実際のiOSプロジェクトのPRを使って、複数のAIツールを連携させたレビューフローを実演します。AIがコードの詳細チェックやパターン検出を担当している間に、人間はアーキテクチャやUX観点での判断に集中する。

この役割分担により、レビュー時間の短縮と品質向上を同時に実現した事例をご紹介します！