トーク

iOSDC と同い年の OS が Apple のプラットフォームにはあります。
それが watchOS です。
watchOS は、Apple Watch と一緒にリリースされ、そのわずか6週間後の WWDC 2015 において最初に公式プレビューされました。
それ以降、iOS、 macOS などの OS とともに毎年アップデートが行われ、多くのユーザー、開発者に愛されてきました。

このセッションでは、10歳を迎えた watchOS の歴史を5分に凝縮し、ユーザー体験の向上や開発者向け機能の拡充といった具体的な進化のポイントについて説明します。
我が子の成長を見るように、暖かく見守っていただければ幸いです。

光学式マウスの仕組みを知っていますか？
マウスの底にあるLEDで机の表面を照らし、その模様の変化を毎秒数百〜数千回のスピードで撮影。
画像同士を比較して「どっちに動いたか」を計算し、カーソルを動かしているんです。

カメラと画像処理で動きを検出する、まさに小さな画像認識システム。
これってiPhoneでもできそうですよね？
そう思い、意気揚々と始めた「iPhoneを光学式マウスにするアプリ」の開発。
このトークではその過程で得た様々な知見を皆さんに共有します。

このトークを通じて、iPhoneの新たな可能性を探る楽しさを一緒に感じていただければ幸いです。

SwiftUIでUIを実現したいが表現力が足りない。そんなときに便利なのがUIViewRepresentableやUIViewControllerRepresentableです。
しかし、そのRepresentableシリーズの使い方はちゃんとマスターしているでしょうか？
Representableシリーズには、Appleのドキュメントを読むだけではわからない、いくつかの『罠』が存在します。なんなら、AppleのサンプルコードですらハマっているCoordinatorのアンチパターンまで存在するのです。
このセッションでは、そうしたドキュメントを読むだけではわからないアンチパターンに焦点を当て、堅牢なコンポーネントを作るための指針をお教えします。

Swift 6の足音が聞こえる今、私たちのコードは大きな変化に直面します。特にConcurrencyチェックは「警告」から「エラー」へとその厳格さを増し、私たち開発者にはより正確なコードが求められるようになります。この変化に備え、私たちが日頃から頼りがちな@MainActorの使い方、一度本気で見直しませんか？

「UIに関わるかもしれないし、とりあえずクラス全体に付けておけば安全だろう…」

その、善意からくる@MainActorが、実はUIのカクつきやパフォーマンス低下を招く「静かなる技術的負債」になっているかもしれません。ネットワーク通信やJSON解析といった、本来バックグラウンドでやるべき重い処理までメインスレッドを占有してしまうアンチパターンは、今こそ断ち切るべきです。

このトークでは、そんな「@MainActorの汚部屋」状態を具体的なコードで示し、どこに付け、そしてどこに付けてはいけないのかを明確に切り分けます。パフォーマンスとコードの見通しの良さを両立させるための、明日からすぐに実践できる「@MainActor大掃除テクニック」を、5分という短い時間に凝縮してお届けします。

合言葉は「@MainActorは、UIスレッドへの最後の出口だけ」。

このトークを聴き終えた時、あなたはきっとご自身のコードから不要な@MainActorを一掃し、気持ちよくSwift 6を迎え入れる準備を始めたくなるはずです。

「このAIツールを使えば、チームの開発はもっと効率的になるはず！」

そんな純粋な期待を胸に、新卒エンジニアとしてAIツールの導入に挑戦しました。
しかし、その先に待ち受けていたのは、技術的なメリットだけでは乗り越えられない、ツール選定、予算、社内申請、そして導入効果への説明責任といった、いくつもの「見えていなかった壁」でした。

特に当時のiOS開発においては、メインのIDEであるXcodeにAIが統合されておらず、拡張機能も不安定でした。そのため、他の開発環境と比較して、AIツールのサポートが不足していました。また、VSCodeを普段の開発でメインに使うのもチームメンバーに抵抗なく受け入れてはもらえない状況でした。
さらに多くの企業にも当てはまるように、AIツールの導入に関する予算が限られており、検証のための時間も捻出しづらいのが現実です。

本トークでは、そのような状況の中、新卒エンジニアの私が所属チームにGitHub CopilotやCursorをはじめとする生成AIツールを導入する過程で経験した、リアルな失敗談を共有します。
そして、その経験から得た「ツール選定前にチームの課題を明確にすることの重要性」や「導入効果を具体的に示すためのアプローチ」といった、新卒エンジニアが失敗を通して改めて伝えたい教訓についてお話します。

デザイナーからFigmaファイルを受け取って実装する際、コンポーネントの細かい値を確認したり、デザインシステムとの整合性を保つのに時間がかかることがよくあります。

Figmaから公式にリリースされたDev Mode MCPサーバーを使うことで、CursorやClaude CodeからFigmaのデザイン情報を直接取得し、SwiftUIコードの生成を効率化できるようになりました。
公式MCPサーバーならではの正確なメタデータ取得により、より信頼性の高いコード生成が可能です。
このLTでは、実際にiOSプロジェクトで試した活用例をご紹介します。

モバイルアプリ開発において、データの同期や共有が必要な要件に直面したとき、皆さんはどのようなデータ管理サービスを選択しますか？
おそらく次のような意見をよく耳にするでしょう。

「FirebaseのRealtime Databaseがベター！データ同期も簡単だし、他サービスとの連携も楽々！」
「柔軟性を考えるなら、サーバーもデータベースも自前で構築すべき」
「とにかくUserDefaultsに無理やりぶち込んでしまえ！（いや、流石にそれは厳しい……）」

私自身もこうした選択肢で悩む一人でしたが、最近になって「Supabase」というBaaS（Backend as a Service）を知りました。
Supabaseは、Firebaseと異なりオープンソースであるため、カスタマイズ性や拡張性が非常に高いです。またSQLベースでデータの複雑な処理が可能なことや、料金体系が明瞭でコストの予測がしやすいという魅力もあります。

そこで本セッションでは、Supabaseを活用して実際に簡単なアプリを作成しながら、その使いやすさや特徴を皆さんと共有します。
Supabaseを使ってみることで、皆さんの個人開発ライフに新しい選択肢を加えてみませんか？
一緒にSupabaseの世界へ一歩踏み出しましょう！

皆さん、最近健康診断は受けましたか？
実はアプリでも健康診断は行われているんです。

起動時間やHang率など、パフォーマンスデータは自動で記録されています。
ただし、それを確認するにはXcode Organizerを開いて自分で見に行く必要があります。
でも、わざわざ開くのは面倒だし、忙しいとつい忘れてしまいます。
そのまま見逃してしまえば、アプリからのSOSに気づけないままに…。
・バッテリー消費が激しい
・スクロールがカクつく
・画面がフリーズする
こうした不調が続けば、ユーザーのiPhoneからあなたのアプリが静かに削除されてしまうかもしれません。

本トークでは、App Store ConnectAPI × GitHub Actions で構築する自動パフォーマンス監視体制について、5分で解説します。

Next Talk's HINT：
・App Store ConnectAPI（perfPowerMetrics）
・GitHub Actions
・Xcode Organizer

メソッドの命名は、処理の内容を語るものでなければならない──それは世の中に広く浸透し、誰もが当然のように従ってきた原則だった。
実際その教えは、長い間開発の秩序を保ち、プロジェクトの明瞭な設計へと導いてきた。

だがある時、この教えに一つの問いを投げかける者がいた。「ViewModelは、他の層と同じ命名規則では語りきれない存在ではないか。」と。
それは異端とされた。責務をわかりづらくし、統一性をなくし、抽象的で、実装を曖昧にするものだとされた。
それでも、複雑なUIと入り組んだ状態遷移の中で、その考え方は静かに、しかし確かに広がっていった。

これは、かつて正統派とされた命名に意を唱え、新たな視点を持ち込もうとした者たちの物語である。

本発表では、ViewModelの「UIとロジックの境界である」「Viewの抽象化である」という特性を踏まえ、そのメソッドの最適な命名について探っていきます。
また、一般的にメソッド名において是とされる「saveProfile」「fetchItems」のような処理内容中心の命名と比較し、UIイベントに即した「onSaveTapped」「onRetryRequested」といったイベント中心の命名が、どのような設計上の価値をもたらすかを検討します。

命名という小さな選択が、設計にどのような影響を与えるのか。
5分間で一緒に考えてみませんか？

多くのユーザーはアプリを使用する際に「直感的に操作できること」を期待しています。１ユーザーとしてさまざまなアプリを触っていると、「こう思っていたのになんでこうなるんだ？」という違和感を覚えることがあると思います。
おそらくその違和感はアプリの設計の段階で、UI/UXの考慮が抜けてしまっていることが原因で生じているものだと考えられます。
もちろん、技術的な制約や実装上の理由から、理想的なUI/UXを実現するのが難しい場合もあります。
ですが、ユーザーは自分の期待通りにアプリが動作することを期待しています。想定と違うとユーザーは困惑してしまい、求めていた情報に辿りつかなかったり、嫌悪感を抱いて離脱してしまう、そんなことにつながってしまう可能性もあります。
たった一つのボタンの動きやアニメーションだけでせっかくのUIも台無しになる可能性さえあります。

こうした背景から、どのようなUI/UXの抜けがあってユーザーに違和感があるのか、それをどうしたら改善できるのかを考えたいと思いました。

このトークでは、どのようなUI/UXの欠落がユーザーに違和感を与えるのかを具体的に分析し、それをどのように改善できるのかを考察します。具体的には、以下のポイントを中心にお話しする予定です。

・失敗例（実例ではなくサンプルをお示しします）
・失敗をどのように改善できるかについての提案

つまりのところ言いたいこと：UIがいいだけじゃダメですか？→ダメです

「目的地に行ったらスマホ制限解除」というアプリを作っていた時の話です。

開発は順調でした。近所のジムで何度テストしても完璧に動作。「位置判定範囲200mで実装完了！」そう思っていました。

ところが、友人からの一通のメッセージで事態は急変します。
「代々木公園の中にいるのに判定されない！バグってない？」

まさか、そんなはずは...。慌てて現地に向かい検証すると、確かに公園内部で全く反応しません。一方で、同じコードを使ったジムでは相変わらず正常動作。

いったい何が違うのか？
・GPS精度の問題？→同じ精度設定
・デバイスの問題？→同じiPhone
・通信環境？→どちらも良好
・コードの問題？→全く同じ実装

同じ位置判定機能なのに、なぜ場所によって動いたり動かなかったりするのか？

調査を進めるうち、ある重要な事実に気づきました。そして最終的に辿り着いた解決策は、なんとAIに「ある質問」を投げかけることでした。

この奇妙な現象の正体とは？
そして「ある質問」とは一体何だったのか？

同じような位置判定機能を実装している方、実は知らずに同じ罠にハマっているかもしれません。実際コードとデバッグの軌跡をお見せしながら、この謎解きの全貌をお話しします！

概要:
「Apple Walletって何ができるの？」「どんな工程でカードが追加されるの？」「自分のアプリに使えるかな？」
そんな疑問を5分で一気に解決してみせましょう！
このLTでは、PassKitの全体像を爆速でキャッチアップできるよう、要点を絞ってお話しします！

やること:

• Apple Walletへのカード追加フロー解説
• こんなこと、できるんだよ！の紹介

やらないこと:

• 実装の詳細説明（時間の都合上、概要のみ）
• WWDC 25のNDA対象内容

こんな方におすすめ

Apple Wallet未経験で「何ができるか知りたい」方
導入検討中で「うちのアプリに合うか」判断したい方
キャッチアップ時間を短縮したい忙しい開発者

5分後、あなたはPassKitを「知らない技術」から「できるきがするぞぉぉぉぉぉおおお！」に変えられます！
キャッチアップ時間の激減を体感してください！
PassKitの可能性にワクワクしましょう！

Swift File数1700超のSansan iOSアプリでは、コーディングスタイルの乱れが開発効率を阻害する大きな要因となっていました。
この課題を解決するために、Sansanではフォーマッターによる数万行単位の大規模なフォーマットを不具合を発生させることなく完了し、今も一貫したスタイルが守られ続けています。
この取り組みから得られた、デグレのリスクを抑えて安全にフォーマットを進める方法を共有します。

トーク内容
1: スタイルの乱れが生産性に与える影響や統一することによる具体的な生産性向上効果の説明
2: フォーマットによって処理が変わってしまう具体的な事例や危険性の紹介
3: 数万行の差分をデグレリスクを抑えて安全に取り込むための戦略的アプローチ

対象となる方
・ チームの生産性向上に取り組んでいる中堅・リードエンジニアの方
・ コードフォーマットツールの導入を検討している方

iOS 26ではSpeechAnalyzerという革新的な文字起こしAIが登場し、プライバシーを守りながら高精度な音声認識をすることが可能になりました。
この技術は、Appleの音声技術やApple Intelligenceに支えられた強力なライブラリです。

このトークでは、以下の内容に焦点を当てます。
1: SpeechAnalyzerによる文字起こしの仕組みやアーキテクチャについての簡単な説明

• SpeechAnalyzer, SpeechTranscriber, AssetInventoryなどの構成技術と、音声データがテキストに変換される流れを解説します。
  2: iOS 10以降で使用可能だったSFSpeechRecognizerと比較を通じて、どれほど性能が向上したかを解説
• 音声認識の精度や処理速度だけでなく、長い音声データや距離のある音源への対応、オンデバイスでの動作など、できることの幅も大きく広がりました。

トークの対象
・ Apple IntelligenceやAppleの最新技術に興味がある方

*NDAに配慮し、公開されたWWDCや公式ドキュメントなどの情報を元にトークを展開する予定です。

Gemini APIによる動画解析とScreen Time APIを組み合わせ、「腕立て100回が自然に続けるアプリ」を開発しました。
筋トレ継続の課題は、「習慣化の難しさ」と「記録の面倒さ」。
これを解決するため、カメラで撮影した筋トレ動画から回数を自動カウントするAIと、アプリを自動制限するScreen Time APIの融合でこの課題に挑戦しました。

特に注力したのが、プロンプトエンジアリングによるAI精度の改善。
以下の6ステップでプロンプト実装を進めていきました。

① 期待アウトプットの定義
② シンプルなプロンプト作成
③ 単一映像での検証
④ ズレの特定と修正
⑤ 別映像での汎化確認
⑥ 複数プロンプトの統合

この手法により検出精度が40％から95％へ飛躍的に向上し、動画内に音声を含めることでさらなる改善を実現しました。

また、Screen Time API（DeviceActivity, ManagedSettings, FamilyControls）を組み合わせ、目標未達成時に娯楽アプリを自動ブロックする機能を実装。
ユーザーの意志力に頼らず、強制力のある習慣化を実現しました。

本LTでは、AIの利活用に役立つ
プロンプトエンジアリングの実践的アプローチと、Screen Time APIのリアルな活用知見を実際にリリースしたアプリを元にお話しします。

「生成AI 」で新しいユーザー体験を作りたい方に、具体的なヒントを持ち帰っていただける内容です！

「皆さん、もうMCPデビューしましたか？」
LLM活用の真価は、私たちの開発環境が持つ「コンテキスト」をいかに伝えるかにかかっています。
本セッションでは、その答えとなる「Model Context Protocol (MCP)」が、いかにしてiOS開発を根底から変革するかを、具体的な実践例と共にお話しします。

Figma MCPの連携より、デザインデータそのものをコンテキストとしてLLMに渡すことで、面倒な手作業による実装は過去のものとなり、デザインから実コードへの変換がシームレスに実現します。

ローカルMCPサーバーを実装し、あなたのMacをAIの忠実な"手下"に変える方法を解説します。
自然言語で指示を出すだけで、AIがgit操作、ビルド、UIテストといった定型作業を自律的に実行。あなたは創造的な作業にのみ集中すればよいのです。

MCPの可能性は無限大です。将来的にはGitHubのような外部サービスや、社内の内部管理画面ともMCPで連携し、開発に関わるあらゆる情報を繋ぎこんでいきます。

「世界をMCPで繋げる」

みなさまが抱えるプロダクトはもうSwift6へのマイグレーションは済んでいますか？
中には鋭意対応中の開発チームもいるかと思われます。
そんなあなたに「Take your time」と伝えたい...。

Swift 6.2では、Swift Concurrencyの機能が大幅に改善され、これまでのスレッドセーフなプログラミングの考え方がより簡潔になります。
このセッションでは、WWDC25の基調講演と実際の開発現場でのマイグレーション経験をもとに、従来のSwift 6対応がSwift 6.2によってどのように変わるのかを詳しく解説します。

QA依頼、面倒だと思ったことはありませんか？

私たちのチームでは、PRごとにQA依頼を行っており、従来のフローは「ビルドの設定・配信」と「SlackでのQA依頼作成」という、手間の多い作業が分断された状態でした。しかも、どちらにも同じような情報を手動で入力する必要があり、非効率でミスも少なくありませんでした。

そこで私は、このフローをスクリプトとXcode Cloudを組み合わせて自動化することにしました。今では、スクリプトへ最低限の入力をするだけで、ビルド配信からSlackへのQA依頼投稿までが一気通貫で完了するようになり、手間もミスも激減しました。

ここに至るまでの経緯を失敗したパターンも含め紹介します。Xcode Cloudの導入を検討している方にとっても「どのくらいのことができるのか」「どこでつまずくか」などのリアルな参考になる内容をお届けできればと思います。

iOSアプリの配布方法というと「AppStoreで公開」か「社内配布（MDMやTestFlight）」の二択だと思っていませんか？ 実はAppleは、企業や団体向けに「Custom App（カスタムApp）」という第三の配布形態を提供しています。 この配布方法は、App Storeを利用しながら、あらかじめ指定した対象者のみにアプリを安全に届けることができる仕組みです。 業務アプリやパートナー限定アプリなどに非常に適していますが、認知度はまだ高くありません。

本セッションでは、AppStoreの配布方法の進化を振り返りつつ、Appleが提供する「パブリック」、「社内配布」、「プライベート（Custom App）」という3つの主要な配布手段の違いや選定基準、審査プロセス上の違い、組織的な利点や制約をわかりやすく整理します。 私が実際に全国約400店舗に向けた業務アプリの配布をCustom Appを用いて行ったので、それにまつわる経緯や運用方法を交えつつお話しできたらと考えています。

「社内用アプリだけどAppStore配信もしたい」「審査が不安」「配布先を限りたい」──そんな悩みを持つiOSエンジニアやIT管理者にとって、“Custom App”は強力な武器になります。あまり語られることのないこの配布手法の実際を、現場の視点でお届けします。

本トークでは、Kotlin Multiplatform (KMP) を利用したアプリ開発で、AndroidとiOS共通のビジネスロジックにおける状態管理とデータベース（DB）設計を、GitHub Copilotで効率化する方法を紹介します。

KMPはコード共通化の利点がある一方で、KotlinコードがiOSエンジニアには分かりづらく、状態やデータの流れが複雑になりがちです。また、ローカルDB導入時には、テーブル間のリレーションや各カラムの役割が不明瞭になる課題も多くのプロジェクトで直面します。

そこで本LTでは、Copilotを活用した2つのアプローチを提案します。

まず、Copilotを活用したDBのリレーションとカラムの役割の可視化について。既存のSQLスキーマやKMPデータクラスから、Copilotがどうリレーションを推論し、カラムの役割を可視化するのかを具体的なプロンプト例を交えて示します。これにより、複雑なDB構造を把握し、設計のボトルネックを早期に発見できます。

次に、Copilotによる既存の状態の可視化に焦点を当てます。KMPアプリの状態管理は様々ですが、時間の経過で状態遷移や依存関係が複雑化しがちです。Copilotが既存Kotlinコードから状態を解析し、状態遷移図や関連イベントの流れを提案・可視化する方法を探ります。これもCopilotへのプロンプト例を通じて、アプリの内部状態理解と予測可能な状態管理構築のヒントを提供します。