トーク

​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らしい表現で画像処理をより安全に、より簡潔に扱うための道筋を共有します。

エッジ AI とは、スマートフォンなどのエッジデバイス上で行う AI 関連処理のことです。

近年のハードウェア (特に GPU や Neural Engine) の進化により、アプリでより高性能なエッジ AI を実現できるようになりました。

iOS をはじめとする Apple プラットフォームも例外ではなく、 Core ML というエッジデバイスに最適化された AI フレームワークを提供してきました。近年では、 Apple Intelligence や WWDC 2025 で発表されたばかりの Foundation Models により、学習済みモデルを用意せずともアプリにエッジ AI 機能を搭載できるようになる未来も見えてきました。

また、 Apple だけでなく PyTorch といった有名な AI フレームワークも、エッジ AI 関連のサポートを強化しており、著名な学習済みモデルのアプリへの組み込みについても可能性が広がってきました。

AI 関連技術が世界的に注目を浴びる中、本トークではエッジ AI をキーワードにスマホアプリとエッジ AI の可能性について、実機での動作検証結果を交えてご紹介します。

アジェンダ

• エッジ AI とは 〜 エッジ AI とクラウド AI
• エッジ AI の活用事例 〜 自動運転やスマホアプリでの活用
• CoreML 〜 エッジ AI に最適化された機械学習フレームワーク
• サードパーティ製ライブラリのエッジ AI 用フレームワーク 〜 PyTorch と ExecuTorch
• Apple プラットフォームにおけるエッジ AI の今後 〜 アプリでの Apple Intelligence と Foundation Models の活用

Swiftで非同期処理といえば、かつてはClosure一択。ですが、複雑なネストや可読性の低さに悩んだ経験はありませんか？
本LTでは、若手エンジニアである私が「Closure地獄」から抜け出すきっかけとなった個人開発でのasync/await体験をもとに、チーム内での技術導入に挑戦した実話をお話しします。
私は学習の一環でFirebaseとSwiftUIを使ったチャットアプリを開発していました。そこではじめてSwiftのasync/awaitを本格的に使い、kotlinライクなtry-catch構文処理の見通しやすさ、エラーハンドリングの明快さに衝撃を受けました。
「これ、業務でも絶対に使える」
そう確信し、上司やチームの理解を得るために比較資料を作成し、サンプルコードを用意して小さなPull Requestから導入を開始しました。反対意見や不安の声もありましたが、自分で課題を見つけ、自分で提案し、自分でコードを書いて示すことで、徐々に受け入れられていきました。
今では、チームの新しいコードには自然にasync/awaitが使われるようになり、非同期処理の可読性が大きく改善されました。
この経験を通じて実感したのは、「仕事は与えられるものだけじゃない。自分で作ることもできる」ということです。
若手でも、技術の力でチームを変えられる。その一歩を踏み出す勇気を、このLTで少しでもお伝えできたら嬉しいです。

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

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

私が現在開発に携わっている 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アルゴリズム：特定の位置がポリゴン内に含まれるかどうかを判定する仕組み
• 位置をポリゴン外に押し出すための最短距離計算アルゴリズム：ポリゴンの外にある「最近傍点」を求めるための幾何計算手法
• 凸包アルゴリズム：簡易的に複数のポリゴンを合成する手法

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

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

SwiftUIでテキストに意味や見た目の属性を与える「修飾」には、
Modifierを重ねる従来の手法、
iOS15以降のAttributedStringでの部分的なスタイル指定、
さらにiOS17以降のMarkdown記法の活用と、さまざまな選択肢が増えています。

しかし実際には、

• 差分更新の仕組み
• アニメーションとの相性
• Unicode結合文字や多言語での動作
• 複雑なハイライトや部分スタイルの表現力

など、見た目だけでは分からないハマりどころが多く、
どの方法を選ぶべきか迷うことも少なくありません。

このトークでは、SwiftUIのレンダリング仕様（Viewツリーの構造や再評価のタイミング）や、
状態管理との連携（State/Bindingと修飾の適用順序の関係）といった基礎を踏まえながら、
Modifier・AttributedString・Markdownという3つの修飾手段を深く比較し、
それぞれの得意・不得意を整理していきます。

さらに「一文中の一部だけ色を変える」「異なるフォントの混在」「多言語テキストの表示」など
実践的なユースケースをデモで比較し、
保守性やパフォーマンスの違いを体感していただきます。

SwiftUIのText修飾を極め、効率的で実用的なUI構築の知見をお持ち帰りください。

内容：

• SwiftUIにおけるText修飾の基礎と進化
• Modifier・AttributedString・Markdownの仕様と特徴
• Unicode結合文字・多言語・複雑ハイライトの落とし穴
• 「部分装飾」「複数フォント」「Markdown混在」の比較デモ
• 差分更新・保守性・パフォーマンスの観点での比較
• 最適な選択をするための判断基準とTips

.bold() や .foregroundColor() などの一般的なModifierと、
iOS15以降に導入されたAttributedStringを用いた柔軟で強力な部分装飾。

SwiftUIでテキストを装飾するこの2つのアプローチは、
見た目こそ似ているものの、その仕組みや設計思想は大きく異なります。

• 差分更新のメカニズム
• アニメーションの動作特性
• パフォーマンスの特性
• 複雑なハイライトを含む表現力

など、見た目だけでは気づけない現場でハマりがちな落とし穴を徹底的にひも解きます。

このトークでは、SwiftUIのレンダリング仕様をもとに、
ModifierとAttributedStringの得意・不得意を余すことなく比較し、
実装サンプルやデモを交えてわかりやすく紹介します。

「同じUIを作るならどちらが最適か？」を迷わず選べる軸をお持ち帰りください。
普段なんとなく選んでいる人こそ、きっと新しい発見があるはずです。
初心者から中級者まで楽しめる、SwiftUIテキスト表現の探究にお付き合いください！

内容：

• SwiftUIにおける文字列装飾の基礎
• Text Modifierの仕様と強み・弱み
• AttributedStringの仕様と強み・弱み
• 同じ見た目を2通りで構築する比較デモ
• 差分更新・パフォーマンス・アニメーションの挙動の比較
• 適切な選択をするための判断基準

ある日、ユーザーから「画面をスワイプしてもカルーセルビューが動かない」との報告が届きました。

調査の結果、Xcode 16への開発環境とiOS 18への端末のアップデートを契機に、SwiftUIのジェスチャー優先順位に仕様変更があり、親ビューであるScrollViewとその子ビューであるカルーセルビューのジェスチャーが競合し、結果としてカルーセルビュー側のDragGestureが正しく検知されなくなっていたことが判明しました。

本セッションでは、ユーザー体験に大きな影響を与えうる、SwiftUIフレームワークのジェスチャーの仕様変更によって、どのようなViewの構成で問題が発生したのかを再現しつつ、発見から解決までの過程を丁寧に解説します。さらに、今後も仕様変更に耐えられるUI設計のヒントを共有します。

• iOS 18からSwiftUIのジェスチャー優先順位にどんな変更が加えられたのか？
• ジェスチャー競合によって引き起こされた問題とその解決の道のり
  • ScrollView vs .highPriorityGesture() の相互作用
  • DragGesture(minimumDistance:) による競合の回避とその副作用
  • UIGestureRecognizerRepresentableによる本質的な競合解消
• まとめ：再発を防ぐ設計と、変化に強いUIをどう作るか

Model Context Protocol（MCP）は、自然言語によるユーザーのプロンプトから、AIがツールを呼び出す際のリクエストを構造化し、外部サービスやアプリと連携できるようにするためのプロトコルです。

最近では、さまざまなアプリや開発ツールでもこの仕組みが使われるようになりつつあり、Swiftエンジニアにとっても無視できない存在になってきました。

本トークでは、
「MCPって聞いたことはあるけどよく分からない…」
「MCP Serverって何ができるんだろう…」
そのような方でも、SwiftでMCP Serverを構築する第一歩を踏み出せるように、わかりやすく、実践的にご紹介します。

具体的には以下のような内容を扱います：

1. MCP Serverとは
   • MCPとはどのような役割を持つプロトコルなのか、どのように利用されているのかわかりやすく説明します。
2. Swiftを用いてMCP Serverを構築する
   • MCP公式SDKを使用したMCP Serverの構築、IoTデバイスの操作、AIとの連携について解説します。
3. Swiftで構築したMCP Serverから実際にデバイスを操作してみる
   • 入力したプロンプトがどのようにMCP Serverを通じて処理され、デバイスが動作するのかを実演します。
4. 実際に構築して明らかになったこと
   • MCP Serverを実際に構築してみてわかった課題と今後の展望について共有します。

「AIと連携できる仕組み」をSwiftで体験しながら、MCPの世界に楽しく入門してみませんか？

visionOSやAndroid XRなど、私たち開発者にも「空間をどう見せるか」が問われる時代がやってきました。
このセッションでは、オープンソースの3D編集ツール「Blender」を使って、開発者が知っておくと便利な次の5つを紹介します。

• 3Dオブジェクトの作成
• アニメーション
• ノーマルマップとマテリアル
• プラットフォーム毎の書き出しと互換性
• バージョン管理

特に、ノーマルマップやマテリアル設定による軽量かつリッチな表現手法、glTF/USDZ形式での出力ポイント、そしてBlender Git Addonを用いたバージョン管理術など、「触ってみたいけどとっつきにくい…」と感じている方にこそ届けたい実践的な知見をお届けします。

visionOSやAndroid XRの登場により、私たちアプリ開発者にも「空間をデザインする力」が求められる時代になりました。
そこで注目したいのが、オープンソースの3D編集ツール「Blender」です。

このLTでは、開発者が知っておきたいBlender活用術を紹介します。

• モデルの質感を軽量にリアル化するノーマルマップ
• glTF/USDZ形式での書き出しを見据えたマテリアル設定
• バージョン管理

「ちょっと触ってみようかな」と思えるきっかけを5分でお届けします！

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

Swiftでは、Arrayに対してfilterやmapをつなげた宣言的な記述をよく使いますが、「この書き方で実行速度は大丈夫？」と感じたことはないでしょうか？

このLTでは、users.filter { $0.isActive }.map { $0.name } のような典型的な記述を対象に、filterやmapをつなげた場合の処理速度を、書き方の違いによって比較検証した結果を交えて紹介します。

ちょっとした記述の違いやlazyの有無によって意外な差が生まれ、期待通りに高速化されないケースもありました。
実際のコード例や計測結果を交えながら、宣言的コードとパフォーマンスのバランスをどう考えるかについてお話しします。

「lazyは速いと思ってたのに…」そんな小さな驚きと発見をお届けします。

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

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

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

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

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

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

SwiftUIが主流の昨今ですが、UIKitベースのレガシーコードと向き合っている方もまだまだいるのではないでしょうか。長い歴史を持つコードベースでは、複雑に絡み合った責務、肥大化したメソッド、長大なViewControllerなど様々な問題のあるコードに直面することがあります。このようなコードに出会った時、アーキテクチャの刷新や技術スタックの移行も重要ですが、まずは「読めるコード」にすることから始めるアプローチがあります。

「読めるコード」にするためには、ファイルの行数を減らし、関連する処理をまとめ、重複や不要なコードを削除するといった地道な改善が必要です。
このトークでは、実際のプロダクトコードで行った2つのViewControllerのリファクタリング事例を通じて、このような地道な改善を、比較的安全に段階的に実施していく方法を共有します。

また、「読めるコード」への改善は、AIを利用した開発においても重要な意味を持ちます。人間にとって読みやすいコードであることにより、AIもまたコードを理解し、適切な提案をすることができます。コンテキストウインドウの浪費も抑える事ができます。AIの恩恵を最大限に活かすためのリファクタリングについても考察します。

話すこと

• 「読めるコード」への段階的な改善手法
• 実際のプロダクトコードでの事例紹介
• コードの可読性がもたらすAIを利用した開発への効果

話さないこと

• 特定のアーキテクチャパターンへの移行
• UIKitからSwiftUIへの移行手法
• 理想論や銀の弾丸的な解決策

とある開発期間1年・iOSメンバー5人の長期アプリ開発プロジェクトにおいて、QAでの不具合発生率を普段の半分以下の2%に抑えることに成功しました。
この要因の1つはメンバー全員が「小さなPull Request」を作り続けてきた事です。
「小さなPR」は品質向上と開発効率に大きく貢献するのです。
「PRは小さければ小さいほどレビュワーに優しく、早くマージされ、バグ発見率も向上する」という原則を深掘りします。

多くの開発者が「差分行数」でPRの粒度を判断しがちですが、本当に重要なのは「関心事の少なさ」です。
ユニットテストやXibの差分でPRが膨らんでもレビューが苦にならないのは、関心事が少ないためです。

本セッションでは、具体的な画面実装の例を挙げ、API層、UIコンポーネント、通信処理など、関心事ごとにPRを分割する具体的な戦略を詳細に解説します。
このセッションを通じて、チーム全体の生産性とプロダクト品質を向上させるヒントを持ち帰っていただければ幸いです。

とある開発期間1年・iOSメンバー5人の長期アプリ開発プロジェクトにおいて、QAでの不具合発生率を普段の半分以下の2%に抑えることに成功しました。
この要因の1つはメンバー全員が「小さなPull Request」を作り続けてきた事です。
「小さなPR」は品質向上と開発効率に大きく貢献するのです。
「PRは小さければ小さいほどレビュワーに優しく、早くマージされ、バグ発見率も向上する」という原則を深掘りします。

多くの開発者が「差分行数」でPRの粒度を判断しがちですが、本当に重要なのは「関心事の少なさ」です。
ユニットテストやXibの差分でPRが膨らんでもレビューが苦にならないのは、関心事が少ないためです。

本セッションでは、具体的な画面実装の例を挙げ、API層、UIコンポーネント、通信処理など、関心事ごとにPRを分割する具体的な戦略を詳細に解説します。
また、「小さなPR」を実践すると先行PR・後続PRが連なっていきます。それぞれのPR同士の文脈を繋げる実践的なTipsも紹介します。

このセッションを通じて、チーム全体の生産性とプロダクト品質を向上させるヒントを持ち帰っていただければ幸いです。

AIコーディングがiOS開発でも注目される中、visionOSの空間アプリ開発にもClaude Codeを使って挑戦してみました。

SwiftUI × RealityKitでの開発は一筋縄ではいかず、空間体験の構築には想像以上の試行錯誤が必要でした。

コーディングだけでなく、3Dモデルは生成AIやBlender MCP、Skyboxは画像生成AI、効果音は音声生成AIに任せ、アセット面でもAIをフル活用。

さまざまな壁にぶつかりながらも、AIと二人三脚で空間アプリを形にしていく中で得た知見をお伝えします。

MVVM、それはSwiftの誕生前から、人気のアーキテクチャの一つ。そしてSwiftUIが登場して6年経った今もなお、その人気っぷりがなかなか衰えを見せません。

ところが、あなたは本当にMVVM、もっと言えばViewModelのことを分かった上で使っていますか？
「みんなが使っているから、私も使おう」
「画面のテストが書けるから、私もViewModel入れよう」
「プレゼン層とドメイン層を繋げるために、ViewModelが必要」
そんな単純な思いで、MVVM使っていませんか？

はっきり言いましょう、そんなあなたは、別にViewModel、もっと言えばMVVMなんて本当は必要としていないです。むしろある意味、SwiftUIとMVVMは、相性が非常に悪い組み合わせだと断言します。

このトークは、ある程度SwiftUIでの開発が慣れているエンジニアをターゲットとし、以下の内容を含める予定です：

• なぜあなたが必要なのはViewModelではないと私が言うのか
• なぜSwiftUIはMVVMと相性が悪いのか
• ViewModelを無くしたら、どのようにしてViewの処理を保証すればいいのか
• MVVM使わないなら、どんなアーキテクチャがいいのか

このトークを聞いて、ぜひ一度SwiftUIの原点に立ち戻って、SwiftUIに適したアーキテクチャを再考してみませんか？