トーク

WWDC25 で公開された Foundation Models framework により、ついに iOS 公式のオンデバイス LLM へ直接アクセスできる時代が到来しました 。
本セッションでは Apple​純正モデル（Apple Intelligence 3B）と、MLX-Swift／MLC-LLM／llama.cpp など OSS ベースの手段を横並びで比較し、iPhone 16 Pro 相当の端末で “どこまで動くか・どう組み込むか” を具体的に解説します。

「オフライン AI チャット」「リアルタイム文章要約」「リアルタイム文章校正」 を ひとつの SwiftUI アプリに統合しながら、３つのオンデバイス LLM を 同じプロンプト・同じ iPhone でベンチマークします。

比較軸は下記 5 点です。

1. 導入工数とビルド手順（Swift Package／Core ML 変換／モデル配布方法）
2. モデルサイズ／RAM 使用量
3. 推論レイテンシ
4. バッテリー消費
5. ライセンスと運用

Apple Intelligence 3B がもたらす省電力性と高レベル API の手軽さ、
llama.cpp-Swift の自由度と暗黙の落とし穴、
MLC-LLM の柔軟性と量子化チューニングの難しさ――
それぞれを可視化し、実装方法も併せて紹介します。

オフラインでも瞬時に動き、個人情報をクラウドへ送らず、運用コストを抑えられる オンデバイス LLM は iOS アプリの新たな武器になりつつあります。

本セッションを通じて、より実用的なオンデバイス LLM を活用した iOS アプリ開発 のイメージを掴めます。具体的なユースケースと実装手順を知ることで、新規アプリの着想や既存アプリ進化のきっかけとなることを目指します。

我が家には2歳の猫がいます。とても可愛く、ときに予測不能で愛くるしい動きをします。そんな一瞬を撮影するのは至難の業ですが、DockKitがこれを可能にします。

DockKitは、iPhoneカメラとDockKit対応デバイスを連携させて被写体を自動追尾するAppleのフレームワークです。WWDC 2023で発表され、昨年対応デバイスが発売されました。iPhone標準搭載のカメラアプリもDockKitに対応しており、DockKit対応デバイスとiPhoneを連携することで人物を自動で検出しトラッキングすることが可能ですが、標準では人物のみに限定されます。

しかし、DockKitには豊富なAPIがあり、Vision frameworkとの相性も抜群です。VNRecognizeAnimalsRequestで猫を識別し、Core MLと連携することで、人物以外の高精度なトラッキングが実現できます！

本セッションでは、Vision frameworkで猫の特徴を捉え、DockKitと連携させる具体的な実装方法と、DockKitをより高度に使いこなすテクニックについて解説します。デモでは我が家の猫が出演する動作映像をお見せし、iOSDC史上最高の癒しも提供予定です。

本セッションを通じて、これらのフレームワークをみなさんのアプリ開発や身近な課題の解決にも活かせるようになるかもしれません。

近年のSwift言語やXcodeの進化に伴い、従来のXCTestに代わるモダンなテストフレームワーク「Swift Testing」が注目されています。本セッションでは、ココナラiOSチームが実際にXCTestからSwift Testingへ移行した事例をもとに、導入の背景や具体的な手法をご紹介します。

まず、なぜ移行を決断したのか。急速に機能が増える中で、XCTestでは「テストが仕様書として機能しない」「分岐の多いテストはボイラープレートが増える」「テストケースに依存したセットアップが煩雑化」などの課題が浮き彫りにしたいと思います。

特にViewModelのテストにおいては、BDD（Given‑When‑Then）スタイルで記述できる点が大きな魅力です。

続いて、Swift Testingの特徴とメリットについて。マクロベースで直感的な構文や、型安全かつ並列実行対応、パラメタライズテストやtrait機能（OSや時間帯によってテストを制御）など、XCTestよりも柔軟で表現力豊かなテストが可能になります

ココナラでの具体的な移行ポイントは以下の4つ
setUp()に頼らず、各テスト内でViewModelやMockを初期化
@Suiteを使って条件ごとにネスト構造を整理
@Testやメソッド名を日本語で書き、仕様の可読性を重視
複数分岐のテストは@Suite内の独立した@Testで構造化

そして、パラメタライズテストにも対応可能ですが、ViewModelのようにロジックが複雑なケースでは適切でない場合もあるため、要件に応じて使い分けています。

最後に、実際のコード例（XCTest→Swift Testing両対応）や、BDDコードが「仕様書としても読める」利点をお見せしつつ、フレームワーク選定・チーム規約への組み込みなど実務ベースでの導入ノウハウを共有します

エッジAIとは、iPhoneなどの端末上で直接動作するAI技術のことで、プライバシー保護やネットワーク帯域の節約など、さまざまな観点から注目を集めています。近年ではエッジデバイスの高性能化により、その存在感がますます高まっています。

しかし、実際にアプリにAIを組み込もうと思うと、さまざまな「迷いポイント」に直面します。
私自身、個人開発アプリにAIを導入する際に、

• 本当にエッジAIを使うべき？
• Apple純正からサードパーティ製まで多くのAPI・ツールの中で、どれを選べばいい？
• モデルやデータセットのライセンスは大丈夫？

といった疑問に悩み、何度も手が止まりました。

このLTでは、そんな試行錯誤の中で得た「迷いポイントの全体像」をベースに、iOSエッジAI導入の判断プロセスをフローチャート形式でサクサク整理していきます。
iOSアプリにAIを組み込みたいが、何から始めればいいか分からない──そんな開発者に向け、Apple公式資料だけではカバーされない導入判断フェーズの実践知を凝縮し、5分間でスッキリ理解できる判断軸をお届けします。

Swift 6.1から、引数の末尾に , （カンマ）を付けられるようになりました。

func foo(
    a: String,
    b: String, // !!!: カンマを付けてもビルドが通る
) {
}

みなさんはこちらの新機能をご存知でしたか？

このようにSwift 6.1と6.2の主な新機能を5分でサクッと紹介します。

サクッと理解したあとは、公式ドキュメントを読んで正しく理解を深めてくれよな！

本セッションでは、Swift-DocCとAI agentの活用によって、ドキュメントを設計・実装・運用の全プロセスの中心に据え、より柔軟で再現性の高い開発体験を実現する“ドキュメント駆動開発”のアプローチを共有します。

これまでドキュメントは、実装の後に作成される補足資料や説明書として捉えられることが多く、設計意図や仕様の認識ズレ、保守コストの増加など、さまざまな課題がありました。しかし、Swift-DocCの普及により、ソースコードと設計情報が密接に結びつき、チーム全体で設計や仕様を共通言語として扱える基盤が生まれています。さらにAI agentの登場によって、DocCを起点とした情報が実装・テスト・レビュー・運用まで幅広く自動化・補完される時代が始まっています。

このセッションでは、

• DocCによる設計・仕様の明文化
• 仕様整理・設計段階でDocCを作成（ドライバー部分は人間、実装はAI）
• AI agentによるコードやテスト、ドキュメント自動生成・補完
• CI/CDやプレビュー環境による継続的な品質維持と自動チェック

という“ドキュメント中心”のワークフローが、どのように現場を変えるかを解説します。

ドキュメントは従来、「保守やリリース直前になってようやく整備される存在」となってしまうことが少なくありませんでした。

これからは、ドキュメントを「設計・実装・運用すべてをつなぐ開発の核」として活用するための実践的な視点を、iOSエンジニアの皆さんと共有したいと考えています。

Webブラウザ操作の自動化ツール代表的なものの一つとしてSeleniumが挙げられます。
SeleniumはJava、JavaScript、Python、Ruby、.NET、Rustといった言語をサポートしており、高い汎用性を誇ります。
しかし、何かが足りません。そう、Swiftです。

本トークではSeleniumとそれが動かすWebDriverの仕組みについて解説し、SwiftでWebDriverを動かしてブラウザ操作を実現することを目指します。

Swiftでもブラウザ自動化の可能性を切り拓いていきましょう。

iOSは言語やフレームワークの進化が早く、技術的負債が溜まりやすい領域です。私が携わっている大規模サービスは約10年にわたり運用が続いており、その中で技術の進化に合わせて複数のアーキテクチャが共存しています。各アーキテクチャに適したライブラリやツールが導入されてきたことで、プロジェクト全体の構成が複雑化し、技術の全体像を把握するのが難しくなっていました。

こうした状況では、新しい技術の導入判断が難しく、技術選定が特定のメンバーの知見に依存してしまうことや、オンボーディング時の使用技術のキャッチアップに時間がかかるなど、複数の課題が浮き彫りになります。これらを解決するため、チームではThoughtWorksが提唱する「Technology Radar」を導入しています。

Technology Radarは、技術の採用や評価を4段階（Adopt / Trial / Assess / Hold）に分類し、意思決定を支援するフレームワークです。私たちはこのモデルをiOS開発に合わせてカスタマイズし、チームメンバー間でディスカッションを行い、現在プロジェクトに導入されている技術を網羅的に分類し可視化しています。

この取り組みにより、技術選定に一貫性が生まれ、レビューや設計の議論でも各技術の扱いが明確な前提のもとで議論できるようになりました。チーム内で“技術の地図”の共通認識があることで、意思決定のスピードと納得感が大きく向上したと感じています。

このトークでは、Technology Radarの基本的な概念から、iOS開発に合わせてカスタマイズしたフレームワーク、そしてチーム内での運用方法を紹介します。

Swiftの勉強を始めたばかりの頃は、自分のアイデアをアプリとして形にすること自体がとても楽しく感じられました。 しかし、学習や開発を重ねるうちに、エンジニアにとって重要なのは単なる実装に留まらず、いかに効率的かつ安全に実装できるかであるという考えを持つようになりました。

その中で「クラスと構造体を使い分ける際、メモリの観点ではどのような違いがあるのだろう？」という疑問が生まれ、やがてそれはより根本的なメモリ構造、つまりハードウェアレベルでのメモリの仕組みへの関心へと広がっていきました。 メモリにはコード領域・データ領域・ヒープ領域・スタック領域があり、それぞれの役割について図解しながら調べて学習を進めました。

この学習を通して、COW（Copy-On-Write）構造、クラスと構造体の選定基準、ARCやクロージャのキャプチャの仕組みなど、これまで何となく知っていたけれどうまく説明できなかった概念を、より明確に理解し、自分の言葉で説明できるようになりました。 今回のルーキーセッションでは、こうした学びと気づきを皆さんに共有したいと思います。

トーク内容

• コード・データ・ヒープ・スタックに関する概念の解説と図解
• クラス vs 構造体、値型 vs 参照型 ― 実際のメモリ使用の違いと選定基準
• Swiftにおける自動メモリ管理（ARC）とメモリリーク、クロージャのキャプチャ問題

サブスクリプションの価格変更は一大イベントですが、頻繁に実施するものでもないためその手順についての情報は多くありません。
本LTでは実際に価格変更を実施した経験に基づき、見落としがちな罠や、Tipsについてご紹介します。

・ 申請手順と必要な確認事項
・ 新規 / 継続ユーザーへの価格変更の反映タイムライン
・ サマータイムの罠
・ 価格の変更時刻を厳密にコントロールするTips

価格変更の際にはこれを思い出せば大丈夫！という内容をお届けします。

我々が作る iOS アプリと OS や他アプリの連携を実現するために App extensions という仕組みが Apple から提供されています
ですが多くのサービスでは iOS アプリと同時に Android アプリを提供しているケースが多く、アプリ内の UI 一つとっても「これはAndroid はどうやったら提供できるだろう？」という疑問を持つことも多いでしょう
App extensions を使った機能を提供する際も Android で似た機能はないのか、サービスとして OS が違ったとしても統一性のある UX を提供出来るかどうかを考えることになるでしょう
勿論似た機能が提供されていることも多く、例えば Siri との連携を提供する Intents に対し Android には Google アシスタント連携を提供する App Actions が存在します

そこで今回は iOS で提供できる AppExtension を振り返りつつ、 併せて Android においてそれと近しい機能がないか、どのような違いがあるのかについて話そうと思います
中でも特に Intents など AI アシスタント絡みで直近の注目度が高そうなもの、 Widget など iOS では比較的新し目だが Android では昔からあったものに着目して行こうと思います
Widget の更新思想一つとっても、明確に時間間隔が指定可能な Android と、バジェットで管理されるため厳密には指定不可能な iOS という違いがあり、出来る出来ないの差分がありえます
この「差分」を理解することこそが、両プラットフォームで一貫したUXを提供するための鍵となります

このトークを通じて、単なる機能比較に留まらないサービス全体の価値を最大化するための OS 横断的な設計についてお話できればと思います

▼ 概要
私たちは「あたらしい旅行を、デザインする。」をミッションに旅行アプリ「NEWT」を日々開発しています。
NEWTはリリースから3年が経ちました。今回は海外旅行に必ず必要な「航空券」に着目してみます。
国内外問わず移動手段として考えられる飛行機移動ですが、チケット忘れやデジタルチケットを当日にサイトにアクセスして焦ったりしたご経験はないでしょうか？
そんな中で航空券データをPassKitを用いてWalletに追加することでより一層トラブル回避の手段とできるのではないかと考えました。
また、航空券だけでなくPassKitをうまく利用することでさまざまな種別のカードやチケットをWalletに追加することができるので他の種別についても併せてご紹介します。

▼ 内容

• PassKitってなに？どんな種類があるの？
• 航空券を扱う場合に実装する内容
  • 証明書設定からpass.jsonの設定について
  • 実際に動かしてみた内容について
  • NFCを付加できる条件
• 実際に開発・運用する/しないを決める時の意思決定について

スマートフォンの性能向上により、AIをクラウドではなく端末上で実行するエッジAIの重要性が高まっています。iOSでは、Core MLを中心にオンデバイス機械学習のための強力なエコシステムが整備されていますが、実際に導入しようとすると、思わぬ壁や選択の難しさに直面することも少なくありません。

私自身、自作アプリにAIを導入しようとしたときにも、

• 既存のAPIや提供モデルによる目的達成の可否の見極め
• Python製モデルの変換や最適化における、サードパーティ製含むツール選定と運用の難しさ
• ライセンスや配布制限のような非技術的制約

といった多くの課題にぶつかり、Apple公式資料だけではカバーしきれない範囲の大きさを実感しました。

本セッションでは、このような試行錯誤や失敗経験を交えながら、以下のトピックについて実践的に解説します：

• AIおよびエッジAIの基本概念と進化の歴史
• iOSにおけるAI基盤技術・Core MLの役割と仕組み
• VisionやNatural LanguageなどのApple純正フレームワーク
• Create MLやcoremltoolsなど、Core MLを支える周辺ツール
• ExecuTorchやLiteRTといったサードパーティ製推論ツール
• ライセンスや配布制限など、非技術的な落とし穴

WWDC25では、Apple Intelligenceの強化や新しいFoundation Modelsフレームワークが発表され、iOS上でのエッジAI活用は新たなフェーズに突入しました。このセッションを通じて、エッジAI技術への理解を深めるとともに、「AIを使う側」から「AIを統合する側」へと進むための実践的な知識と視点をお届けします。

音声配信アプリのE2E自動テストでは、UIだけでは判断しづらい“聴く体験”をどう守るかという、他のアプリとは一味違った難しさがあります。
・音声が再生されていることを確認する方法
・今月の放送を指定する方法

音声配信アプリにおいて、リスナーに「聴く体験」を提供し続けるためには、どのようにテストを行うべきでしょうか？

本セッションでは、ノーコードでE2Eテストを実装できるMagicPodを用いて、音声再生の検証や動的なコンテンツ選択に取り組んだ事例をご紹介します。

再生ボタンの状態変化から“音が出たこと”を間接的に確認する方法や、「今月の放送」のように固定文言やIDに頼れない場面での要素特定の工夫など、音声配信アプリならではの課題とその突破法をお話しします。

このセッションを通して、以下のことを学ぶことができます。
・音声配信アプリにおけるE2E自動テストの特有の課題
・MagicPodの強みとその実践的な利用法
・MagicPodの限界とそれを補完する方法

チームで最も多くのバグを発見する私が、日常的に実践しているテストの観点を共有します。実装の隙を突くイレギュラーなテストでいかにしてアプリの品質を守るのか。その具体的な手法と、明日から実践できるマインドセットをお話します。

WebからiOS開発に転身した私が最初に直面したのは、「ドキュメントが抽象的で、読んでも実装のイメージが湧かない」という大きな壁でした。しばし実際に動作確認してみないと理解できないものが多々あり、スピードが求められる開発現場ではこの「試行錯誤の多さ」はボトルネックとなりました。なぜ、これほどまでに分かりにくさを感じるのか？ 本発表では、その原因をWeb開発者にはお馴染みのドキュメントMDN Web Docsとの「文化の違い」から考察し、筆者を救った「ドキュメント」についてお話します。

Swift Concurrencyにおいても、非同期処理を同期制御したいケースがあります。たとえば非同期に複数のリクエストが同時に走るが、実行すべき処理は一度きりでよいという状況です。しかし、Swift ConcurrencyにはDispatchSemaphoreに相当する同期制御機能が用意されておらず、このような要件を満たすにはちょっとした工夫が求められます。

このトークではアクセストークンの更新処理をユースケースに取り上げて、複数の非同期リクエストが同時に更新を要求しても初回の更新処理だけAPIを呼び出し、またそのレスポンスを後続の処理に再利用して使い回す方法を解説します。具体的にはwithCheckedContinuationを用いて非同期処理を同期制御する手法と、Actorを活用して取得したレスポンスを安全に共有・管理する手法を組み合わせることで、無駄なAPI呼び出しの抑制や共有データの競合を回避の実現が可能です。

このトークを通じて、実務でそのまま応用できるSwift Concurrencyの効果的な使い方を習得しましょう。

リリース前のE2Eテストを、実サービスに適用可能なレベルで運用するには、ツールを導入するだけでは不十分です。
SwiftUI・UIKit・WebView が混在するiOSアプリにAppiumを用いたE2Eテストを導入・維持する中で直面したさまざまな課題と、それをどう解決してきたかを本セッションでご紹介します。

まず、accessibilityIdentifierの管理が煩雑になった問題です。
画面ごとにidentifierの付け方がバラバラで、統一された基準がないためにテスト実装時に混乱が生じていました。
この問題をプロジェクト内でどのように整理し、テストしやすい構造に落とし込んでいったのかをお話しします。

最後に、複雑なUIフローに起因するflakyテストの問題です。
日付選択 → オプション選択 → 決済画面への遷移 → WebViewでのメッセージ受信など、状態変化が多いフローにおいて、テストの安定性を確保するために取った構造的アプローチを紹介します。

3つ目は、E2Eテストをリリースフローに安定して組み込むための課題です
テスト実装 → 実行 → 結果確認 → QA → リリース、という一連のプロセスをどのように定着させたのか、実際のチーム運用をもとに共有します。

テスト自動化ツールを導入したものの、信頼性のあるテスト体制を作れずに悩んでいる方や、複雑なUI構成の中でテスト運用に課題を感じている方にとって、少しでもヒントとなれば幸いです。

WebPは、画像に対する高品質な可逆圧縮と非可逆圧縮を実現する、モダンな画像形式です。
WebP画像形式は同品質のPNG画像より約23〜26%小さく、非可逆圧縮の場合はJPEG画像より25〜34%小さくできるため人気の画像形式です。

iOS 14から標準でWebP画像の読み込みがサポートされ、UIImageで直接WebP画像を扱えるようになりました。

では、今から新しくWebP画像を扱うライブラリを作るということは無意味でしょうか？いいえ、そんなことはありません。自分で作るという行為は動作の原理や仕組みを学ぶことに非常に優れた手法です。

学習だけでなく実用の面でも、自作の場合は特定のユースケースに処理を最適化してパフォーマンスを発揮したり、標準のライブラリで発生する問題を回避できます。特にiOS 18では標準の方法では特定のケースでパフォーマンスが大きく悪化する問題があることがわかっています。

この講演ではWebPファイルフォーマットの基本仕様と構造、Swiftで構造を解析する方法、画像を圧縮する技術の原理と仕組みをステップバイステップで実際のコードを用いて解説します。

WebPのコーデックを実装することは「画像圧縮の理論」「ビット操作の職人技」「高速化・安全化の実務」を一気に学べる実践的な場です。特にSwiftで実装する場合は安全なメモリ管理と低レベルの最適化の両立というノウハウまで得られます。

普段のプログラミングとは一味違う、低レイヤーの実装を楽しんでみませんか？

Xcodeは好都合に未完成
だから美しいんだ
---「珍獣 / ウホイクション」の歌詞より抜粋

Xcodeは、最低というには魅力的過ぎる。
---ウレンタの言葉

私たちがiOSアプリを開発するときに必要不可欠なツール、Xcode。

「SwiftUIのプレビューが動かない」「リネームに失敗する」「嘘の警告やエラーを表示する」などの挙動により、何かと批判されがちです。

しかしApple公式が提供しているIDEです。当然素晴らしいに決まっています。

本トークでは、Xcodeの問題に目を瞑り、便利なtipsを紹介します。

●話すこと
・Xcodeで便利な機能やショートカットキーの紹介

●話さないこと
・Xcodeの問題点
・基本的な機能の紹介

俺は今、完成されたXcodeが見たいってことです。