トーク

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-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 アプリと 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を付加できる条件
• 実際に開発・運用する/しないを決める時の意思決定について

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

魅力的な体験や没入感のあるアプリを作るためには、写真や動画などのメディアコンテンツを効果的に表示することが欠かせません。
iOS標準のPhotoアプリでは、優れたレイアウトとジェスチャーに対応したインタラクションで写真・動画のコンテンツを心地よく閲覧できます。

Rettyでは、ユーザーさんが投稿した写真を「iOSのPhotoアプリのような体験で振り返られる」というコンセプトで「メモリーズ」という機能を開発しました。
その際、UICollectionViewのCompositionalLayoutやTransitionLayoutを総動員して、モザイクレイアウトやレイアウトの切り替えなど、写真を振り返るリッチな体験を実装しました。

このトークでは、UICollectionViewLayoutに実装されているAPIで、シンプルなタイル表示を拡張する方法をお話しします。

トーク内容

• iOSのPhotoアプリにおける注目すべき体験と、それらを再現する方針
• UICollectionViewで複雑なモザイクレイアウトを構築
• 複数のLayoutを、 UICollectionViewTransitionLayout を用いてインタラクティブに切り替える方法
  • タイル表示の切り替えのアニメーション実装
  • デフォルトのアニメーションとカスタム実装の解説
• UICollectionViewLayoutAttributes を操作してスクロールに応じた挙動を作成する
  • Cell / SupplementaryViewの LayoutAttributesを画面内の位置に応じて変更するなど

参考:
メモリーズ機能: https://corp.retty.me/news/article/?id=8ahxxd_ukqf

本セッションでは、「Verify With Wallet API」を使って実装した本人確認機能についてご紹介します。メルペイではこれまでeKYCを活用した本人確認機能を提供し、特にマイナンバーカード読み取りを用いたリアルタイム認証では最短1分で完了する仕組みを実現してきました。しかし、署名用電子証明書のパスワードを忘れるなどの課題により、認証プロセスを完了できないお客さまも少なくありませんでした。2025年6月にAppleとデジタル庁が連携し、iPhoneのApple Walletにマイナンバーカードを登録できるようになったことで、Face IDを使った生体認証によりパスワード入力なしで本人確認が可能となり、さらに簡潔でスムーズな体験を実現しました。
本機能の開発は、日本国内ではもちろん、アメリカ以外の国として初めての事例であり、Appleとデジタル庁が2025年6月24日にリリースした最新機能を活用しています。

主なセッション内容:

• Apple Walletへのマイナンバーカード対応がもたらす本人確認の簡略化とその仕組みや実装
• 開発において直面したAppleの未公開APIの活用方法
• Appleおよびデジタル庁の要求に応じた厳格な開発プロセスと対応策

今年初めに、私はカメラアプリ 「SLIT_STUDIO」 を開発し、リリースしました。このアプリは、スリット・スキャンという旧来の VFX 技術を再現したものです。スリット・スキャンを簡単に解釈するとスリット（線）で風景を撮影し、それによって得られた画像を重ね合わせて二次元の画像を生成する VFX 技術です。

アプリを初めてインストールするユーザーにスリット・スキャンの原理を理解してもらうために、オンボーディング画面を用意しました。その最初に、インタラクティブな起動画面を設置しました。この起動画面では、ユーザーが直感的にスリット・スキャンの原理を体験できるようにしています。

オンボーディング全体はこちらの動画をご覧ください：https://drive.google.com/file/d/1i8GSxg5EYyz07-iMH-tz7KtSd0tPpZZv/view?usp=sharing

最初の起動画面では、画面を長押しすると、スキャンラインが下から上に移動して、指を離すと元に戻ります。スキャンラインの下には、この起動画面をスリット・スキャンに通した結果を表示します。SwiftUI と Metal Shader を使用して作成しました。

SwiftUI には、Color Effect, Distortion Effect, Layer Effect の3つの Shader API があります。 この画面で3つすべてを使用しました。
このトークでは、画面のデザインからAPIの選択、実装に至るまで、この起動画面を制作した流れを詳しく話します。アプリでの Shader の応用に関する参考になる情報を提供できれば幸いです。

重要ポイント：

• 3つの Shader API の使いわけ
• SwiftUI だけでできないこと
• 性能を良くするために頑張ったこと

Swiftファイルがコンパイルされるのと同じように、プロジェクト内のアセットカタログ（.xcassets）もビルド時にコンパイルされます。Swiftのコード量が増えるとコンパイル時間が伸びるのと同じように、アセット数が増えるとコンパイル時間も無視できなくなります。

例えば、数百のアセットを持つプロジェクトでは、クリーンビルド時のアセットコンパイルだけで数分以上かることがあります。

このコンパイルを担当するのが、Xcodeに同梱されている actool というツールです。ビルドフェーズでactoolが実行され、Assets.carを生成しています。

本トークでは、actoolを活用して事前にアセットをまとめてコンパイルし、生成したAssets.carをプロジェクトに組み込むことで、Xcodeビルド時のアセットコンパイルを実質的にゼロ秒にする方法を紹介します。

【話すこと】

• actoolとは何か、どこにあるか
• アセットコンパイルの仕組み
• 事前コンパイル済みAssets.carを生成してプロジェクトに組み込む手順
• アセット名のハードコーディング回避策
• XCFrameworkとの比較と使い分け

どこからでも触れられるシングルトンは、スレッド安全性を保証しないまま肥大化しがちです。結果として実行時のクラッシュや不具合の温床になり、保守コストを引き上げます。Swift6では strict concurrency checkingがデフォルトで有効化され、Sendable 準拠や @MainActor／actor の宣言によって静的にデータ競合を防げます。シングルトンもここに乗せれば「安全な共有状態」へ生まれ変われます。

しかしながら、シングルトンはその特性上、通常のクラスよりも修正による影響範囲が広くなってしまうので、Sendable / actor / @MainActor の方針選択が一筋縄ではいきません。さらに UI 層・ネットワーク層の処理・状態管理など巨大な責務を一身に抱えたいわゆる"神シングルトン"が存在している場合、MainActor と非 MainActor のコードが混在する等、方針選択をより複雑化します。問題の簡単化のため、リファクタリングでシングルトンを適切な単位に分解することは一つの手ですが、重要機能を担っている場合や改修コストをかけれない場合、現実的な選択肢として選びづらいことも多いかと思います。

本トークでは、シングルトンを実際に Swift 6 へ対応させた経験をもとに、シングルトンをシングルトンのまま安全にSwift6に対応させる上での工夫、知見を共有します。具体的には以下をお話しします
・シングルトンをSwift6対応させるための基本的な方針
・神シングルトンにありがちな状況と対応方針

皆さんのプロジェクトに眠るシングルトン達をSwift6の世界に安全にお連れするためのご参考になれば嬉しいです。

みなさん、ユニットテストを書いていますか？
今回は、私たちの会社でどのようにしてユニットテスト文化を社内に根付かせたか、そのプロセスと成果についてお話しします。

まず初めに、ユニットテストの重要性について簡単に触れ、なぜ私たちがこの取り組みを始めたのかを説明します。次に、具体的なステップとして、教育プログラムの実施や、社内でのベストプラクティスの共有方法について紹介します。また、チームメンバーの意識改革を促すための工夫や、実際に直面した課題とその解決策についてもお話しする予定です。

最後に、この取り組みの結果として得られた社内の変化や、プロジェクトの品質向上にどのように寄与したかについて詳しく説明します。皆さんの組織でもユニットテスト文化を根付かせるためのヒントを得られるセッションにしたいと考えています。

ぜひ、私たちの経験を通じて、ユニットテストの重要性とその効果について理解を深めていただければ幸いです。

Swift Macrosを日常の開発で活用できていますか？

Swift 5.9から導入されたマクロ機能は、Swiftコードをコンパイル時に生成できる仕組みで、定型的なコードの生成や、静的解析によるバリデーションが可能になります。
最近では、Swift公式からSwift Syntaxのビルド済みバイナリが提供されるようになり、これまで導入のハードルとなっていたビルド時間の問題も軽減され、より気軽にマクロを活用できる環境が整ってきました。

Apple自身も #Preview や @Observable、#expect（swift-testing）など、マクロを積極的に活用しており、実際のプロジェクトでも目にする機会が増えてきています。
また、サードパーティ製のOSSにおいても、Swift Macrosを活用したライブラリが次々と登場しています。例えば、イニシャライザの生成、プロトコル準拠の生成、文字列リテラルの静的検証など、ユースケースは多岐にわたります。

本トークでは、こうしたOSSにおける実際の利用事例をもとに、Swift Macrosがどのような課題を解決しているのかを分析し、活用パターンを体系的に分類します。そして、「自分のプロジェクトでどんなMacroを使えばよいか」「どう活用すれば開発効率を上げられるか」といった観点で、実践的な知見を共有します。

本トークを通して、皆さんがプロジェクトに最適なマクロを選択・活用できるようになることを目指します。

本セッションでは、Flutterで開発されている出前館アプリにおいて、継続的かつ安定的なリリースを実現するために導入した「リリーストレイン」の運用設計と、運用初期に直面した課題・工夫について実践的な知見をお届けします。
さらに、App Store / Google Play への申請時に発生したイレギュラーケース（審査の長期停止、日本国外からのアクセス制限によるリジェクト、プライバシーポリシー指摘など）にどのように対応したのか、その事例を共有します。

開発現場でリリース業務に携わるなか、多くの関係者が関わるアプリのリリースや、ストア審査の不確実性に対して、再現性のあるプロセスを設計・維持することの難しさを日々感じています。
現場での実践を通じて得た知見を共有することで、同じ課題を持つアプリ開発チームに役立てていただけたら幸いです。

1. 出前館アプリの開発体制とリリースの課題

   • Flutter製の大規模アプリとしての特徴
   • リリースの不安定さ・調整コスト

2. リリーストレイン導入の経緯と設計

   • なぜリリーストレインを選んだのか
   • 月2回のリリーススケジュールと周辺業務の整備

3. リリーストレイン運用の工夫と課題

   • 開発チーム・QA間の連携改善
   • 運用安定化までに乗り越えた壁とその対応

4. ストア申請時のイレギュラーケースとその対応

   • App Storeの審査が長時間止まった事例
   • 国内限定サービスが審査に与えた影響
   • Google Playでのライブラリ由来のプライバシーポリシー指摘対応

想定する対象者

• モバイルアプリのリリースを担当しているFlutter/iOS/Androidエンジニア
• 複数の関係者と連携しながら、継続的なアプリ運用を行っているPM・EM・技術リーダー

​Swiftは安全性と効率性を両立する言語ですが、従来の画像処理APIであるvImage_BufferはObjective-C時代から存在しており、ポインタ操作やメモリ管理の難しさ、型の安全性に課題がありました。これらの問題を解消するために登場したのがvImage.PixelBufferです。

​本セッションでは、vImage_BufferからvImage.PixelBufferへ移行した実体験をもとに、以下の観点から、Swift時代のモダンな画像処理の設計と実践を解説します：

・ vImage.PixelBufferとvImage_Bufferの使用感とAPI設計の違い
・ 型安全性・自動メモリ管理による利点と、移行時に直面したギャップ
・ 安全性とパフォーマンスのバランス：PixelBufferを活用した効率的な画像処理パイプラインの構築
​・ vImage.PixelBuffer導入・リファクタリングの実践Tipsと注意点

​対象は、Swiftで画像処理を行っているiOSアプリ開発者や、vImage.PixelBufferの導入を検討しているエンジニアです。Cの壁を越えて、Swiftらしい表現で画像処理をより安全に、より簡潔に扱うための道筋を共有します。

私が現在開発に携わっている iOS アプリでは、 iOS Deployment Target が 15 に上がったことを機に、今年から本格的に SwiftUI の導入を開始しました。

現状、機能・UI 共にシンプルな画面への対応が中心ということもあり、 MVVM パターンに近い設計方針で実装が進められています。しかし、複雑な画面でも設計が適用可能かどうかなど、今後へ向けた課題も抱えています。

また、 SwiftUI はバージョンが上がるごとに機能追加が行われていますが、一方で iOS Deployment Target によって使用可能な機能に制限が生じることから、プロダクトのサポート方針を考慮し、長期的なメンテナンス性維持の観点から SwiftUI の導入を進める必要があります。

本トークでは、 画面の複雑度 と iOS Deployment Target (本トークは 15 以上を対象とします) という 2 つの変数を元に、ケーススタディや実際のアプリの事例を交えて最適な設計方針について検討した結果をご紹介します。

アジェンダ

• iOS Deployment Target から見た SwiftUI
• 画面の複雑度から見た SwiftUI
• 画面実装ケーススタディ 〜 iOS Deployment Target 15 から 18 まで
• 画面実装ケーススタディ 〜 単機能な画面から複数の API 呼び出しを伴う画面まで

本セッションは、位置情報アプリを開発しているエンジニア、あるいは位置情報データの効率的な扱いに関心のあるエンジニアを対象とし、アプリ開発の現場で直面する課題をもとに、位置情報の取り扱いに必要なデータ構造やアルゴリズムの実践知識を紹介します。

位置情報アプリでは、ユーザーの位置をもとに地図上に線や領域を描画したり、特定の場所が移動禁止エリア内にあるかを判定する機能が求められます。しかし、これらの処理は地図データの量が膨大であること、位置情報が連続的かつリアルタイムで変化することから、パフォーマンスやデータ効率の観点で多くの課題に直面します。

本セッションでは、こうした課題を解決するための具体的な技術として、以下の内容を解説します。
• Google Mapsで使われている「Encoded Polyline algorithm」：ポリラインやポリゴンを効率的に表現し、データ転送量を削減する方法
• Point in Polygonアルゴリズム：特定の位置がポリゴン内に含まれるかどうかを判定する仕組み
• 位置をポリゴン外に押し出すための最短距離計算アルゴリズム：ポリゴンの外にある「最近傍点」を求めるための幾何計算手法
• 凸包アルゴリズム：簡易的に複数のポリゴンを合成する手法

これらの技術は、単なる理論ではなく、アプリ開発の現場で実際に役立つ知識として紹介します。ポリゴン内判定の最適化や地図上でのオーバーレイ描画の工夫など、具体的な課題解決の実例を交えながら、技術の必要性と効果をわかりやすく伝えます。

聴講後には、位置情報アプリのデータ構造・アルゴリズムの実践的な知識が身につきます。