トーク

​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 呼び出しを伴う画面まで

世の中にはBuy Me a Coffeeのように、クリエイターが寄付・投げ銭を受け取るためのサービスがあります。
しかし、そうしたサービスはユーザーを決済可能なWebページに誘導することになるため、iOSアプリにそれらのリンクを掲載することはAppleの規約により禁止されています。

それを踏まえると、「広告を載せるのはアプリの世界観に影響を与えるから避けたい。でも収益源が無いからせめて寄付や投げ銭を受け取りたい」と考える開発者は、アプリ内課金で似た仕組みを作る必要があります。

本トークでは、個人開発アプリに実際にユーザーから寄付・投げ銭を受け取るためのアプリ内課金を実装し、今年約50のユーザーに課金していただいた私が、その実装と実績を振り返ります。
具体的には特に工夫した三点（金額設定UI、ライティング、課金に対するフィードバック）について、その意図と実装、および実際に運用して感じた良かった点と改善点を共有します。

それぞれの詳細は以下の通りです。
・課金額の設定UIについて：ユーザーがどのように課金額を決定できればスムーズかを考える
・ライティングについて：ターゲットとするユーザー層によっては「コーヒーをn杯贈る」というよくある表現が、その分の投げ銭を意味するということが伝わらないのでは？という疑問から考える
・課金直後にユーザーに返すフィードバックの必要性について：消耗型課金だが、何かアイテム数のようなものが変化するわけでもない課金のフィードバックはどうあるべきか、Buy Me a CoffeeやYouTubeのSuper Chatの体験から考える

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

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

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

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

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

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

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

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

本セッションでは、位置情報アプリを開発しているアプリエンジニア、または位置情報技術に興味を持つ方を対象とし、位置情報の「精度」や「時刻の取り扱い」について解説します。
スマートフォンで取得できる位置情報は、地図アプリ、交通サービス、IoT、防災など、日常生活を支える多くのアプリで活用されています。しかし、その位置情報がどのような仕組みで得られているのか、特に時刻情報がどのように関わっているのかについては、普段意識することが少ないかもしれません。

本セッションではまず、古代より人類がどのように時刻を求めてきたかを述べ、位置と時刻を求める人類の挑戦として、18世紀イギリスで制定された「経度法」と、それにより始まった経度問題の解決に向けた競争、そしてジョン・ハリソンによる海洋クロノメーターの開発を振り返ります。次に、電波を使った測位方法の歴史と、GPSをはじめとするGNSS（全地球測位システム）の基本原理を解説し、衛星信号を用いて端末の位置を特定する仕組みを解説します。

さらに、GNSSの生データを取得・解析するための専用ツール「GNSS Logger」と「GNSS Analysis」を活用し、端末が捕捉している衛星の数や種類、方向、信号強度といったデータを可視化します。これにより、都市環境でのマルチパス反射、大気遅延（電離層・対流圏）、衛星の配置や補足数不足といった精度劣化要因が、どのようにデータに現れるのかを具体的に解説します。

最後に、センチメートル級の高精度測位の仕組みと、それがもたらす未来の可能性についての展望を語ります。
聴講後には、位置情報と時刻情報の本質的な関係を理解し、位置特定にまつわる歴史と技術の知識が身につきます。

多言語対応をしていると、いつかはRTL（Right To Left）言語、つまり右から左に書く言語への対応が必要になる場面に出会います。私が担当しているiOSアプリでもその対応が求められました。

ではRTL言語対応って具体的に何をすべきかご存知でしょうか？iOSでは、OSやフレームワークによってある程度「自動対応」がされます。しかし、UIの崩れ、画像の反転、レイアウトの意図しない挙動など、エンジニアが「手動対応」しなければいけない場面も存在します。

このトークでは次のような観点から、私が調査、実装をしたRTL言語対応の知見を共有します。

• そもそもRTL言語対応とはどんなものか
• RTL言語対応に関するAppleの公式情報をおさらいしてみる
• OS、フレームワーク側が「自動で」してくれるRTL言語対応
• エンジニアが「手動で」頑張るRTL言語対応
  • レイアウト修正
  • 画像修正
  • その他思わぬ落とし穴
• 対応状況をどのように確認するか

このトークを聞けば、初めてRTL言語対応に取り組む方でも迷わず対応できるでしょう。逆向きUIの世界、覗いてみませんか？

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を迎え入れる準備を始めたくなるはずです。

再帰って便利ですよね。関数の最後に再帰呼び出しを置く「末尾再帰」なら、スタックも節約されて、ループと同じくらい効率的に動く。

そんなふうに信じていた時期が、私にもありました。

「末尾再帰なら安心！」と信じて書いたSwiftのコード。動作確認もOK、見た目もスッキリ、ところがある日、ちょっと大きな値を渡しただけでStack Overflowで爆死！
何が起きたのか? 調べてみると、Swiftは末尾再帰の最適化（TCO）を保証していないらしいです！
しかも、見た目的には末尾再帰に見えるのに、ちょっとした演算の影響で最適化されないことも。

このLTでは、そんな「Swiftの末尾再帰、信じすぎ注意！」という話を、実際に書いて動かして試してみた結果とあわせて紹介します。

なぜStack Overflowが起きたのか?
末尾再帰が最適化される場合とされない場合の差は?
今は大丈夫なコードでも、未来永劫ずっと安全?

楽しく聞いて、明日から「ちょっと再帰が心配になる」。
そんな5分をお届けします。