トーク

iOSアプリ開発において、状態監視の実装方法は時代と共に多様化しています。従来のDelegateやKVOから、単純なクロージャ、Combine、AsyncSequence、そしてSwiftUIのObservationに至るまで、現在では開発者には数多くの選択肢が与えられています。

しかし、きちんと仕組みを理解せず「最新技術だから」「手軽に書けそうだから」といった理由で技術選定を行うと、思わぬ罠を踏み、結果としてプロジェクトに不適切な実装を生むことにもなりかねません。加えて、既存の手法を用いる場合でも、Swift Concurrencyへの対応という現代的な課題は避けて通れません。

本発表では、各状態監視手法の特徴や長所・短所を整理し、どのような場面でどの技術を選択すべきか、その実践的な指針を提案します。皆さんが日々の開発で自信を持って技術選定できるよう、その一助となれば幸いです。

APIが新しいSpeechフレームワークでは大きく改善されたことをご存知でしょうか？AppleはSiriやキーボードに音声入力のインターフェイスを統合しています。新しいSpeechフレームワークはこれまで内部にあったAppleの音声入力の機能を公開することで、より高精度の文字起こしが簡単に、手軽に実装できるようになりました。

また、音声入力の価値は、LLMの登場によって再評価されています。ノートアプリや通話アプリでは、ミーティングノートを自動で作成することが次世代の標準機能とされつつあります。さらに、ライブ配信では文字起こしを活用したリアルタイム翻訳が増えてきており、音声入力がアプリのコア機能として位置づけられることが予想されます。

しかし開発者として、音声入力をアプリに持ち込むことを考えた時にどのようにアプリ全体を設計したら良いのか悩むことが多くあります。どのようにまず音声を取得するのか、リアルタイムと録音済みでの考慮する点の違いはあるのか、抽象化の観点はどうすべきか、Speechフレームワーク以外に同様の機能を提供するフレームワークは何があるのか、どのようにLLMと連携すべきなのか、など開発してみないと考えにくい観点がたくさん挙げられます。

本トークではこれらの疑問を解消してアプリに音声入力を持ち込むために必要な知識を包括的に提供します。

1. iOSで音声を扱うための基礎知識であるAVFoundationについて
2. 新しいSpeechフレームワークができること
3. 音声入力のWhisperKitとSpeechフレームワークの比較
4. 実例で学ぶSpeechフレームワークを使った音声入力アプリの実装方法

このトークを通じて、音声入力を活用したアプリの実装に挑戦してみましょう！

アプリ開発では、アプリと別のプロセスで動作する App Extension を開発できます。昔からある仕組みですが、近年特にアプリの機能をOSに渡すことでリッチな動きを実現する Widgets や Apple Intelligence (App Intents) で利用する機会が格段に増えています。この仕組みではアプリ本体とは別プロセスで動作するため、データの一貫性や安全な共有が求められます。しかし、 UserDefaults や FileManager、 Core Data、 Keychain など、共有・永続方法は多岐にわたります。また AppExtension は利用できるメモリにも上限があり、正しく設計しなければクラッシュやデータ破損、一貫性を損なうバグの原因にもなりかねません。

本トークでは、 App Extension を利用する際に安全かつ効率的にデータを扱うための指針について紹介します。基本的な設計に加え、実践的なTipsを幅広く紹介します。たとえば、起動処理で必ず行われるセットアップ処理に関する罠や、 App Extension 特有の制約に伴う DB のマイグレーションの扱い、 App と App Extension 間で発生したイベントをどのように通知しあうか、等です。

App Extension の活用が進む中、「データの正しい共有設計」はますます重要になります。 Widgets や Apple Intelligence にこれから対応しようとしている方にも、すでに導入済みで改善のヒントを得たい方にも役立つ内容です。

visionOS 26 で発表された「Apple Projected Media Profile（APMP）」 は、MP4／MOV ファイルに拡張メタデータを付与し、180°・360°映像を標準映像と同じ操作感で扱えるようにする新しい仕組みです。

高価な専用カメラが必要な「Apple Immersive Video」とは異なり、APMP ならGoProやInsta360など、個人でも手軽に入手できるカメラで撮影した映像を、そのまま Vision Pro の没入空間で再生できます。

本講演では、APMP の基本構造から具体的な変換手順までを次のトピックで解説します。

• APMP と Apple Immersive Video の違い
• APMP が扱える映像フォーマットの種類
• QuickTime コンテナ内「vexu」ボックスの仕組み
• Comfort Mitigation（VR 酔い対策）の仕組み
• 標準映像をAPMP対応ファイルへ変換する方法

更に、 APMP映像はSafari／WebKitベースのブラウザでも再生可能です。
Apple Vision ProのSafariではAPMP映像がどのように没入表示へ切り替わるのか、デモ動画を交えて紹介します。

最後に、個人開発している visionOS 2向け 360°動画アプリをAPMP対応へ移行した際に、どのような修正が必要だったのかを、差分ソースコードを示しながら詳しく解説します。

visionOS 26 で発表された「Apple Projected Media Profile（APMP）」 は、MP4／MOV ファイルに拡張メタデータを付与し、180°・360°映像を標準映像と同じ操作感で扱えるようにする新しい仕組みです。

高価な専用カメラが必要な「Apple Immersive Video」とは異なり、APMP ならGoProやInsta360など、個人でも手軽に入手できるカメラで撮影した映像を、そのまま Vision Pro の没入空間で再生できます。

本講演では、APMP の基本的な構造を説明し変換手順までを次のトピックで解説します。

• APMP が扱える映像フォーマットの種類
• QuickTime コンテナ内「vexu」ボックスの仕組み
• 標準映像をAPMP対応ファイルへ変換する方法

最後に、個人開発している visionOS 2向け 360°動画アプリをAPMP対応へ移行した際に、どのような修正が必要だったのかを、差分ソースコードを示しながら詳しく解説します。

オープンデータとは、誰もが自由に使えるよう公開されたデータのことです。
気象、人口、交通、選挙など、行政機関が提供するオープンデータには、社会の課題や動きを読み解くヒントが詰まっています。
しかし、多くはCSVや表形式のまま放置され、活用されずに埋もれています。

このセッションでは、iOS 16以降で使える Swift Charts を活用し、こうしたオープンデータをアプリで「伝わる形」に変える方法を紹介します。

実際に気象データや交通データ、選挙・人口統計などを例に、データの取得、整形、そしてインタラクティブなチャート表示までをデモを交えて解説します。
たとえば、気象データを棒グラフで表示したり、通勤手段の変化をエリアチャートで見せたり、投票率を地図上にヒートマップで可視化したり。

「Swift Chartsを使ってみたくなる」「地域や社会のことをアプリで伝えてみたくなる」

そんな感覚を持ち帰っていただけるセッションです。

iOSアプリ開発においても、AIコーディングツールを活用して開発効率を向上させる事例が増えています。日々の業務でもさまざまな開発タスクでAIを活用していますが、私はその中でも特にFigmaのデザインデータをもとにSwiftUIコードを自動生成する取り組みに挑戦しています。

とはいえ、AIに「コードを生成してほしい」と指示を出すだけでは、期待どおりのコードを得ることは難しいのが実情です。特に独自のDesign Systemライブラリを使用しているような場合、適切なコンポーネントを使った狙いどおりのコードを生成させるにはいくつかの工夫が必要です。

このトークでは、安定的に品質の高いSwiftUIコードを生成するために行なった、以下のような試みについてお話しします。

• MCP Serverを用いてFigmaからデザインデータを正確に取得する
• Claude Code を使って既存のコードからSwiftUIとDesign Systemの関連性を学習し、ナレッジとして蓄積させる
• 生成されたSwiftUIのスナップショット画像とFigmaからエクスポートした画像データを比較し、AI自身に誤りを検知させ、自己修正を行わせる
• 自己修正と開発者からのフィードバックをもとにナレッジを自己更新させる
• AIを使ったコード生成における、学習 → 生成 → 検証 → 改善 のループの重要性
• 現時点における限界、理想と現実

AIコーディングツールの進化は非常に速く、追いかけるのが大変ですが、このトークを通じて、AIを活用した開発のヒントやアイデアを得て、日々の作業に取り入れるきっかけになれば幸いです。

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

やること:

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

やらないこと:

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

こんな方におすすめ

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

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

本業iOSエンジニア、副業で弓削商船高専の教員の私が、iOS開発経験ゼロの高専生5名と共に全国高等専門学校プログラミングコンテストのテーマ「ICTを活用した環境問題の解決」に挑みます。
開発期間は6月から10月までのわずか4ヶ月。
この無謀にも見える挑戦のリアルタイムな奮闘記をお話しします。

本トークでは、以下の3つの視点から、私たちの挑戦の過程を共有します。

1. 社会課題からiOSアプリ構想へ
   紙の大量消費と個人情報漏洩という2つの社会課題を同時に解決するため、どのようなアイデアを経てiOSアプリの構想に至ったのか。
   そして、4ヶ月で開発を完遂するため、いかに機能を最低限の最低限まで絞り込んだのか、その要件定義のプロセスをお見せします。

2. ほぼオフライン環境のデモンストレーションを乗り越える技術設計
   コンテスト本番は運営側が用意しているインターネット環境は不安定、作品のデモンストレーションに使えるスペースも机一個分という縛りあり。
   そんな環境でも安定したデモンストレーションを実現するため、基本的な機能はローカル（サーバ含め）で完結するアプリ設計に舵を切りました。
   通常のアプリ開発とは一味違う、制約の多い環境下での技術選定やアーキテクチャ設計の勘所を解説します。

3. iOS初心者チームの育成とリアル
   iOS開発を知らない学生たちを、いかにして4ヶ月でiOSアプリを開発できるチームへと導くのか。
   技術コーチとして、PMとして若手育成の壁とそれを乗り越えるための工夫を、リアルな経験談としてお伝えします。

セッション当日は、10月のコンテストに向けて学生は最も修羅場の時期。
開発の最前線で"今"起きているたくさんの「つらみ」や学びを、熱量高くお届けする予定です。

※ なお6月末時点、プロダクトコードは1行も用意できてません。

「Write once, run everywhere」 - それはアプリケーション開発において、多くの開発者が追い求めてきた夢です。
モバイルアプリ開発の世界では、Androidの公式言語であるKotlinも例外ではありません。
Compose Multiplatform for iOSがStableとなり、アプリケーションの大部分をKotlinだけで開発する選択肢が現実的な視野に入ってきました。

しかし、過去の歴史が示すように、マルチプラットフォーム技術は常に諸刃の剣です。
技術選定とは、輝かしい未来を選ぶだけの行為ではないのです。チーム体制、事業フェーズ、プロダクトの性質によって、いつかその技術から「撤退」する日が来るかもしれません。
使用されていた技術の影響により部分的撤退が叶わなかったアプリも見受けられます。
本セッションでは、この予期せぬ「撤退戦」までを考慮に入れることの重要性を提起します。

本セッションではKotlin Multiplatformを主軸に、この「撤退戦略」を深掘りします。
まず、なぜKotlin NativeがネイティブAPIを直接呼び出し、ネイティブらしい振る舞いを実現できるのか解説します。そして、この特性が撤退時にどう活きるのかを明らかにします。
最後に、プラットフォームの専門家が変化の時代で自らの強みを最大限に発揮するための技術選定の指針を考察します。

トーク内容

• マルチプラットフォームにおける「共通化」の功罪
• なぜ技術選定で「撤退戦」を考慮すべきなのか？
• Compose MultiplatformとKotlin Multiplatformの現在地
• 撤退シナリオから見る、Kotlin Nativeの真価 Kotlin+UIKitの組み合わせ
• 変化の時代における、プラットフォーム専門家が活きる技術選択の指針

Swift TestingはWWDC2024でアナウンスされたテストフレームワークです。マクロを活用したAPIで、記述量を抑えつつ、parameterized testsやテストの並行実行もサポートされるものです。XCTestからのマイグレーションドキュメントも公式に準備されており、プロジェクトをSwift 6にさえできていれば、デメリット小さく良いテスト体験を享受できます。

一方で、課題になるのは「既存のテストをどう書き換えていくか」ではないでしょうか？プロジェクトによってはXCTestで記載されたもののみでなく、Nimbleのようなライブラリを用いて記載されたテストもあるでしょう。
これらの既存のテスト資産を効率よく、そしてより効果的なテストに変換することを皆さんは意識できていますか？マイグレーションドキュメントはXCTestとの対応表に過ぎず、「どう書き換えるか？」については焦点を当てていません。また、数個の単体テストを書き換えても、テスト実行時間の削減には大きな影響はなく、書き換える事自体のモチベーションが下がり、Swift Testingに置き換える事自体が後回しになっていないでしょうか？

そんな後回しになってしまう課題について、このトークではMCP ServerとこれをコントロールするAI Agentを導入することで、無駄な後戻りを小さくおおよそ自動でテストのマイグレーションを実行したケーススタディを紹介します。既存のswift-testing-revolutionaryやSwiftFormatのpreferSwiftTestingといったツールをそのまま使うのではなく、MCP Serverとして提供することのメリットについても触れ、Swift Testingに移行するモチベーションを上げる具体的なアクションの一つを皆さんと共有できればと思います。

10年前に誕生したUIKitアプリは、さまざまな課題を抱え保守性が悪い状態になっていました。状態管理のenumやフラグを抱えコードの見通しが悪くなったFat ViewController、ロジックを分離したが機能が積み上がるにつれて責務が混在したManager──そんなレガシーなアプリが生み出すバグと格闘する日々が続いていました。

本セッションでは、レガシーアプリを改善するためにアプリに生じるバグの傾向を分析し、「コードの見通しの悪さ」を生む構造的な原因に向き合う中で、SSOT(Single Source of Truth)を実現するための Store、状態管理であることを明確にするための ViewState など、iOSDC2023で紹介された「SVVSアーキテクチャ(Store・ViewState・View)」に辿り着くまでの過程をお話しします。

Fat ViewControllerからの段階的な分離、SwiftUI移行を見据えた土台作り──SVVSをスモールステップで導入するプロセスと、それによって得られた改善効果についてお話しします。

• レガシーUIKit MVC アプリが抱える課題
• アプリで頻出するバグの傾向分析
• 取り組む課題と実現したいことの整理
• Fat ViewController を段階的に改善した作戦
• SVVS になった後の SwiftUI 導入

位置情報を活用したアプリは便利である一方、権限ハンドリングやバッテリー消費といった数多くの課題が存在します。本セッションでは、実際のプロダクト開発で遭遇した問題とその解決策を具体的なコード例とともに紹介します。これにより、参加者が安全かつ効率的に CoreLocation を活用できるスキルを身につけることを目指します。

【話すこと】

• 位置情報のステータスの違いとリクエスト方法
• 位置情報変更時の効果的なデバッグ方法
• 位置情報によるアプリ起動のライフサイクル管理
• 移動経路取得のための実現方法と注意点
• バッテリー消費を抑えるための実践的手段

【対象者】
位置情報機能を実装予定の開発者、既存アプリの改善を考えている方、CoreLocationの課題に直面した経験を持つ開発者

CoreLocationに潜む課題を理解し、安心して位置情報を活用したアプリを開発できるスキルを身につけましょう！

AIエージェントの発展により、プログラミングの敷居は大幅に下がりました。プロンプトを書けばコードが生成され、どんどん実装を進めることができます。しかし、開発速度を上げることだけがAIエージェントの利点でしょうか？

AIエージェントを使えば未知の領域のプログラミングも十分な品質で実装が可能になります。
それまでは諦めていた不慣れな分野のプログラミングもアプリに取り込み、結果としてユーザー体験をよりよいものにできるでしょう。

私は7年間個人開発として風水アプリを開発を続けています。
このトークではその風水アプリにCursorを使って国際標準地球磁場 (IGRF-14)をSwiftへ実装し、MapKitを利用した偏角計算画面により風水アプリのUXを劇的に改善したプロセスを紹介します。
AIエージェントとの対話によって、IGRF-14モデルのPythonコードの理解からSwiftへのリファクタリングまでを一気通貫で実現し、リリースまで漕ぎ着けた一連の取り組みを解説します 。

「目次」
・地磁気モデル（IGRF）とは？
・IGRFモデルによる偏角の計算プログラムをCursorでSwiftへの変換
・生成されたコードの品質担保戦略
・OSSの公開とアプリ設計、Swiftらしいコードへのリファクタリング
・AIエージェント利用時の課題と解決策

AIエージェントの利用を考えている方へ具体的な事例を示し、Vibe codingの先にある、やりたいことをやり切る方法を具体的にお伝えします。

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

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

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

Pull-Requestのレビューを依頼された際、レビューのために手元で作業中の内容を一旦スタッシュし、レビュー対象のブランチをpullして、Xcodeでプロジェクトをビルドするような経験はありませんか？

頻繁にブランチを切り替え、動作確認のためのビルドを行うと、数えきれないほどの時間がレビューのために使われることになります。

この課題解決のために動作確認用のTestflight版アプリを用意することも多いと思いますが、その場合もアプリのArchiveとアップロード、Testflight上で配信可能になるまで時間がかかります。
Testflight側のレートリミットも存在するため、Pull-Requestの内容が更新されるたびにTestflightにバイナリをアップロードするといったワークフローは組みづらいでしょう。

私たちのチームではこの課題に対して、手元でビルドすることなく、Testflightで配布可能になるのを待つことなく、Pull-Request上にコメントされたリンクをクリックするだけで動作確認できるワークフローを用いて大幅に時間と手間を削減しています。

本トークでは、私たちのチームで導入している動作確認を簡単に行えるようになるワークフローを他のチームでも導入できるように、以下の内容について紹介します。

• iOSにおけるビルド成果物の種類について
• 動作確認用のテストアプリの準備方法について
• Shopify製のツール「Tophat」を用いて、App Bundleを用いたシミュレーター上での動作確認方法について
• 検証したい対象と、それに応じたテスト版配布方法のプラクティスについて

このセッションを通して、Pull-Requestのレビュー体験を改善し、チーム全体の開発効率を飛躍的に向上させるヒントを得ていただければ幸いです。

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 」で新しいユーザー体験を作りたい方に、具体的なヒントを持ち帰っていただける内容です！

現代の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にもアクセシビリティ許可をしているアプリがあるはずです。

ぜひご覧ください！