トーク

jpg、 png、gifにwebp

画像の拡張子ってたくさんあるけど、どうしてたくさんあるんだろう？？
そんな疑問を感じたことはありませんか？

大学院で画像処理を専攻した私が、なんとか20分足らずでその疑問を解消した気になれるよう解説いたします！！
最後に次世代フォーマットであるavifをiOSで表示させる実験をお見せします

WWDC2022でApple Virtualization Framework(以下AVF)が登場するまで、macOSのVMの立ち上げはとても大変でした。Hypervisor Frameworkという低レベルAPIを使い非常に頑張って自作するか、Mac1台あたり毎年数十万円のライセンス料を支払い、VMソフトウェアを買うしかありませんでした。

しかし、いまはAVFがあります。誰でも簡単にmacOS VMを立ち上げられます。パフォーマンスも最高です。しかも無料で、毎年WWDCでアップデートがあります。

今回のトークでは、AVFとは何者で、その仕組み、APIの使い方、便利な3rd party CLIツール、Rust/Goのbindings、ユースケース、AVFを使ったツールをご紹介します。もちろんWWDC2025の内容も！例えば、AVFを使えば、GitHub Self Hosted Runnerで毎回クリーンなビルド環境を用意することができます。

「Virtualization Framework気になっていたけど、なんなんだ」という方にぴったりなトークです！

我が家はかわいい猫と暮らしています。不在時にも猫の様子を把握するためにネットワークカメラを検討した結果、Google Nest Camの導入を決めました。決め手のひとつは、公式アプリだけでなくSmart Device Management APIを経由してWebRTCでカメラ映像にアクセスできる点です。APIの提供により、macOSやvisionOSなどAppleプラットフォームで動作する独自のクライアントを開発できます。例えば、Vision.frameworkで猫自体を検出したり、そのポーズを可視化したりと、映像再生に留まらない機能拡張も自由自在です。

本トークでは、このアプリ開発の知見をベースに、WebRTCとVision.frameworkの連携についてお話します。

1. API準備と認証: Smart Device Management APIを使うための準備とGoogle Cloud OAuth 2.0
2. WebRTCでの映像再生: 映像ストリーミングを確立する過程と、取得した映像のCVPixelBuffer変換
3. Vision.frameworkでの解析: VNRecognizeAnimalsRequest（動物検出）とVNDetectAnimalBodyPoseRequest（姿勢検出）を用いたリアルタイム解析

Google Nest Cam以外のカメラをお使いの方にも、お持ちのデバイスとAppleプラットフォームを接続するヒントとなるはずです。ネットワークカメラというハードウェアをAppleフレームワークを組み合わせて、猫との暮らしをハックする。そんな日常を拡張するアプリ開発の楽しさをお届けします。
実際にどのように検出されるかは、我が家の飼い猫「ビビ」の気まぐれ次第です。

空間ビデオや空間写真、Apple Immersive Video などの空間メディアの特徴の一つに「実物大」の再現があります。これによって視聴者はあたかも撮影場所にいるかのような臨場感を味わうことができます。「実物大」を再現するには撮影した映像そのものに加えて投影方法や撮影時のレンズの特性などのメタデータが必要になるのですが、WWDC25でこのメタデータの仕様や運用方針がアップデートされ、いよいよ情報のパーツが揃ってきました。

本トークでは Apple Projected Media Profile を詳しく読み解きつつ、AVPlayer がどのような描画を行っているのかを探っていきます。第一のゴールは撮影した映像にどんな値を設定すれば良い感じになるのか？が分かることですが、visionOS の AVPlayer の振る舞いを知ることは空間メディアを視聴できるデバイスを考える上でもヒントになるはずです。

皆さんは空間メディアについてこう思ったことはありませんか？

Vision Pro は持っていないけれど iPhone で撮った空間写真を楽しみたい
180°や360°の動画をライブ配信し、そのままの体験を大勢に届けたい
イマーシブな体験ができるハイクオリティな映像コンテンツを多くの人に見て欲しい

Vision Pro のクオリティは素晴らしいですが、もし手軽に空間メディアを視聴できるデバイスがあって、それが普及していたら、と思わずにはいられません。この探究はこうしたデバイスの作成を考える上での足がかりになれるのではと考えています。

ショッピングアプリやSNSなど、さまざまなモバイルアプリで活躍するカード型UI。

画像・タイトル・説明文・価格・割引率・タグなど
多様な要素を自在に組み合わせられる一方で、
特に STORES ブランドアプリ のように、複数のアプリをブランドごとに異なるレイアウトで提供する場合、
アプリごとのデザイン変更に柔軟に対応する必要があります。
そのたびにアプリを更新してパターンを仕込むのは大きな負担となり、運用面で課題が残ります。

この課題を解決するために挑戦したのが、
Server-Driven UI × HTML × SwiftUI という構成です。

サーバーからHTMLのbodyをAPIで配信し、
SwiftUIでパースして動的に描画することで、
カードの構造・表示条件・順序の差し替えを
サーバー側でリアルタイムに制御し、
柔軟かつ安全にUI変更を可能にしました。

具体的には

• HTMLパースの仕組み
• SwiftUI上での動的View生成のコツ

といった技術的チャレンジにも触れます。

特に Server-Driven UI での役割分担に悩んでいる方には参考になる事例です。
Server-Driven UIの可能性を一緒に探求し、新しい解決策を見つけてみませんか？

日々のiOSアプリ開発において、開発効率の向上は常に重要な課題です。本トークでは、「Cursor」「Claude-Code」を活用し、特にiOS開発に特化した「Mobile-MCP (Model Context Protocol)」を含む多様なMCP連携を徹底解説することで、開発ワークフローを劇的に改善する手法をご紹介します。

Cursor IDEは、AIによるコード補完、チャット形式での質問応答、プロジェクト全体のコンテキスト理解など、開発者の生産性を高めるための強力な機能を提供します。その核となるのがMCPサーバー連携です。Mobile-MCPは、iOSシミュレータや実機との連携を通じて、UI要素の認識、操作、デバッグ情報の取得などをAIに可能にさせます。これにより、例えばAIがアプリのUIを理解し、テストコードの自動生成を支援したり、これまで手動で行っていた多くの作業を自動化・効率化することが期待できます。

トークでは、まずMCPとは何か、そしてCursor IDEやClaude-Codeにおけるmcp.jsonの設定方法から始めます。Node.jsおよびnpm（nodebrewを活用したインストール方法を含む）の導入から、各MCPサーバー（Notion, Browser Tools, GitHub, Figma, Slack, Mobile-MCP）の具体的なセットアップ手順を、実際のコードスニペットや設定例を交えながら詳細に解説します。

本トークを通じて、聴講者の皆様には、AIを最大限に活用した次世代のiOSアプリ開発の姿を具体的にイメージしていただき、自身の開発ワークフローを革新するための具体的な知識とノウハウを持ち帰っていただくことを目指します。手動による煩雑な作業から解放され、より本質的な開発に時間を費やすための第一歩を踏み出しましょう。

本文:
このセッションでは、Swiftを用いてGitを一から実装することで、バージョン管理システムの内部動作を深く理解することを目指します。Gitは多くの人にとって便利なツールですが、その内部構造や設計思想をしっかり理解している人は少ないかもしれません。他のバージョン管理システムと比較して、Gitがどのようにユニークであるか、どのような設計思想に基づいているかを学ぶことは、想定外の挙動に直面した際にも落ち着いて対処できる力を養います。

内容:

Gitの基本設計思想: オブジェクトストレージ、SHA-1ハッシュ、参照システムの基本的な仕組みを解説します。
コア機能の実装: init、add、commit、logといったコマンドをSwiftで構築し、実際の動作を確認します。
データ構造の理解: blob、tree、commitオブジェクトの構造と相互関係について学びます。
ファイルシステム操作: .gitディレクトリの管理やインデックスファイルの読み書き方法を探ります。
暗号化ハッシュ: SHA-1を用いたコンテンツアドレッシングの実装過程を解説します。
このセッションに参加することで、「なぜGitはSHA-1を使うのか」「コミットオブジェクトの中身とは何か」「ステージングエリアの実体とは」「2wayではなく3wayマージを使う理由は」といった疑問に答えられるようになります。また、ハッシュ関数やファイルシステム操作、データの永続化といった基礎的なコンピュータサイエンスの概念も深く理解していただけます。

Apple Vision Pro上で180°立体動画を体験できるViewerをSwiftネイティブで実装し、100名以上に実地体験していただきました。
その中で得た知見のうち、今回は特に「操作ミスや混乱を防ぐための空間UI設計」にフォーカスして話します。

初めてVision Proを使う人でも迷わず使えるように、カルーセル形式による直感的な映像選択UIや、空間上で押しやすくしたカスタムボタン設計など、UXの洗練に注力しました。
本セッションでは、これらのUI構成の設計思想、具体的なSwiftコード、空間UIでの失敗例と改善アプローチを、デモを交えてご紹介します。

Vision Proアプリ開発や空間UI設計に関心がある方に向けて、限られた時間でもすぐに活かせる工夫を凝縮してお届けします。

植物の育成は楽しく癒しにもなりますが、水やりのタイミングを逃すと枯れてしまうこともあり、育成記録を続けるのも難しいという悩みが多くあります。
本セッションでは、iPhoneのCoreNFC機能を活用し、鉢に貼ったNFCタグにかざすだけで植物の育成ログを簡単に確認・記録できるスマートガーデン体験のプロトタイプを紹介します。

特に以下のポイントを中心に解説します。

CoreNFCの実装と技術的チャレンジ
・NDEFフォーマットタグの読み取り方法やiOSのユーザー操作必須などの制約への対応
・バックグラウンド制御やエラー処理などの実装上の工夫

植物情報とNFCタグのマッピング設計
・タグIDと植物データの紐付け方法
・育成情報の管理と同期の工夫

具体的なユーザー体験の工夫
・直感的な育成ログUIの設計例
・水やりや施肥のタイミングを知らせるリマインダー機能のシナリオ紹介

今後の展望とスマートホーム連携
・IoTセンサーやHomeKitとの連携による自動化可能性
・将来的なスマートガーデンの拡張イメージ

本セッションは、CoreNFCを活用したiOS開発に関心のあるエンジニアだけでなく、スマートガーデニングや生活に寄り添うテクノロジーに興味がある方にも有益な内容となります。
具体的な技術解説とユーザー体験の両面から、スマートガーデンの可能性を分かりやすくお伝えします。

Apple CryptoKit は、 Swift で利用可能な暗号化処理のフレームワークです。

Xcode 上ではインストール不要で利用できることや Swift 言語の特徴を活かしたインターフェース設計となっていることから、実用性だけでなく手を動かしながら暗号技術を学ぶのにも向いているのではないでしょうか。

ただ、暗号技術はデータの秘匿だけでなく、デジタル署名やメッセージ認証コードなど幅広い分野で利用されていることから、まずは特定の分野に絞って学習を始めるのがおすすめです。

本トークでは、 Apple CryptoKit の概要や特徴を紹介します。その上で、数ある暗号技術の中から署名付き AWS API リクエスト の生成処理を題材にメッセージ認証コードについて紹介します。

Apple CryptoKit の概要を知るだけでなく、暗号技術についてより身近に感じてもらえるようなトークを目指します。

アジェンダ

• Apple CryptoKit の特徴 〜 Swift らしい書き心地と信頼性
• Apple CryptoKit がサポートする暗号技術 〜 暗号化、ハッシュ化、メッセージ認証
• AWS API リクエスト 生成処理を Apple CryptoKit を使って実装してみる

Apple Vision Proの空間環境に、動きのあるMotion Graphicsを表示する表現手法をSwiftとRealityKitで探究し、視線誘導・雰囲気演出・情報提示を目的としたインタラクティブな空間グラフィックシステムを構築しました。

本セッションでは、RealityKitベースで以下のような実装を実演とともに解説します。

• 3D空間内に モーショングラフィックス（波紋、軌跡など）を表示する設計
• タイミング制御にDisplayLinkのフレーム同期を用いたアニメーションの滑らかな再生
• ユーザーの視線方向やヘッドポジションに応じて動的に変化する演出
• ShaderGrapghMaterial／LowLevelMesh／パーティクル風表現など、Swiftで構築可能な動的効果の組み合わせ技法

さらに、Apple Vision Pro実機上での動作デモを交えながら 「通常の2D UIやタイムラインベースでは伝えられない情報を、空間でどう魅せるか」という観点で、デザインと空間的体験の融合プロセスを紹介します。

空間演出や映像表現に携わる方、またVision Proの先端的なUXを模索している開発者にとって、技術と表現の両面から学びのヒントを持ち帰れるセッションです。

「そのXCFramework、Swift Package Managerから使えるようにしてもらえませんか？」──その一言で始まった移行作業は、14回のやり直しとXcodeアップデートへの追従を伴う長い旅でした。

ChatGPTで手順を検索すれば"答え"は瞬時に見つかる時代ですが、SwiftPMの仕様上の制約やツールチェーンの細部は、実際にプロジェクトを回してこそ分かることも多いです。本セッションでは、あえて試行錯誤の過程そのものを共有し、「遠回りから得た経験値」をそっくり持ち帰っていただくことを狙います。

主な試行錯誤の流れは――

• SwiftPMではbinaryTarget の依存関係を宣言できず設計で立ち往生
• Dynamic Framework化を図るも、Debug/Releaseビルドでシンボル名変化によりリンク失敗
• Library Evolutionで対処しようにも、サードパーティ側には適用不可能
• Prebuilt XCFramework配布を試すも、クライアントの別依存とモジュール名衝突
• Static Linkingによる依存関係埋め込みに転換するも、SwiftPMではリソースバンドルが自動コピーされない
• 別依存とのモジュール名衝突はModule Aliasで解決したかに見えたが、Xcode更新で突然動作不能に
• 最終的にサードパーティライブラリをforkしてリネーム埋め込み

各段階での「なぜその判断をしたか」「なぜダメだったか」の思考プロセスを追い、SwiftPMやXcodeの仕様には載っていない現実的な制約とその回避策を共有します。理想的な解決策ではありませんが、実際に動くものを作った一つの事例として、同じ轍を踏まずに済む知見をお伝えする時間にできれば幸いです。  

The Composable Architecture (TCA) は、SwiftUIとの親和性の高さやテストの容易さが魅力のアーキテクチャです。しかし、アプリケーションの規模が拡大し、親子関係にあるReducerが増えるにつれて、予期せぬパフォーマンスの低下に直面することがあります。

その主な原因の一つが、Actionの伝播に伴うReducerの再実行コストです。特に、状態（State）を変更する必要のない、単なるUIイベントの通知ですら、親子Reducer間を伝播することで、アプリケーション全体に無視できない負荷をかけてしまうケースが存在します。

本セッションでは、まずTCAにおけるAction呼び出しの仕組みと、それがなぜパフォーマンスボトルネックになり得るのかを、他のアーキテクチャ（Redux/Flux）との比較を交えながら解説します。

その上で、 TCAのAction呼び出し方式の変更により、パフォーマンスをどの程度改善できるかを、具体的なコードと実行時間の計測結果をもとに詳説します。

また、検証内容を元に、Swiftプログラミング全般に対して考えられるパフォーマンス改善の知見を共有します。

CoreDataは、iOSアプリ内でのデータ永続化とCRUD操作を手軽に実装できる強力な標準フレームワークです。

少量のデータの読み書きを行うだけであれば、難しい考慮点なく利用することができます。
ですが、大量のデータを読み込んで表示する場合や、大量のデータの書き込みを行う場合は、
UI処理のブロックを防ぐ、大量データを高速に取り込める処理方法にするなどの考慮が必要となります。

具体的には以下のような工夫が必要となります。
・UI処理がブロックされないようバックグラウンドでデータ取得を行う。
・データ書き込みを数十〜数百件まとめて実施することにより高速化する。

このトークでは、これまでにCoreDataを用いて「1万件以上のデータの地図上への表示」や「100万件以上のデータのインポート処理」を実装してきた経験を基に、実用的な速度と利用感を実現するための具体的な手法をお話しします。

みなさん、サービス影響の大きなシステム改修の経験はありますか？

アンチパターンでアプリのデータ保存部分を実装してしまい数年…この実装を引き金に一部のユーザーでデータに関わる不具合が発生してしまいました。
この不具合を改善するためには、アンチパターンを解消しつつ既存のデータを安全な状態に移行しなければなりません。サービスの継続のためには失敗は許されないミッションです。
さて、どのように対処すべきでしょうか？

本トークではアンチパターンから適切な実装に移行を成功させるにあたって考え、実践したことについて下記の内容で発表します。

• アンチパターン脱却の作戦を立てる
• 失敗シナリオは？シナリオの格付けをする
• 成功シナリオは？何をもって成功と言えるのか？
• シナリオの実現性について検証方法の紹介
• 検証結果からシナリオを再考する
• 失敗シナリオを潰して成功シナリオを成立させる

本トークを通じてサービス影響の大きな修正を可能な限り安全に行うためのノウハウや思考方法のヒントを持ち帰っていただければ幸いです。

【このトークが解決する課題】
Apple Walletに関する議論は、キャッシュレス決済やマイナンバーカード搭載といった、大規模で注目度の高いテーマに集中しがちです。
その結果、多くの開発者や企画者にとって、もっと身近で実装のハードルが低いにも関わらず、ユーザー体験を劇的に向上させる可能性を秘めた活用法が見過ごされています。物理的な会員証、ポイントカード、各種の鍵、チケット…。

私たちの身の回りには、未だユーザーに「不便」を強いているアナログな接点が数多く存在し、それらをどうデジタル体験に昇華させるかという具体的なアイデアの発想方法が共有されていません。
というか使ってるサービスが少なくない？！

【トークの概要と目的】
本トークでは、あえて「決済・航空券・公的ID」という巨大テーマを外し、Apple Walletが持つ真の力を「できること」ベースで一緒に考え直してみましょう。
目的は、世の中によりWalletを取り入れた「面白いプロダクト」の創造です！

具体的には以下の内容を話します

• どのような流れで実装されているのか (5分)
• どのような機能や形式が提供されているのか、HIGを交えて考える (8分)
• 海外ではどのような形のサービスにどういうアプローチでWalletが組み込まれているのか？ (7分)

*セッションの内容ではNDAを遵守します

【このセッションから持ち帰ってもらいたい項目】

• マイナンバーや航空券、クレジットカードといった注目度の高い分野ではないプロダクトで Walletという可能性を視野に入れられる思考
• もっと面白いものが作れそう！という希望

面白いプロダクトを作る一助になれば幸いです！！

現在、Claude CodeやCursor、Cline、WWDC2025で発表されたXcode 26などのツールが登場していますが、これらを用いたiOSアプリ開発におけるバイブコーディング環境はまだ十分に整っていない状況です。

自身も、Xcode以外のツールを使ってAI駆動開発を行うことに対して懐疑的でした。しかし、自社ではAI駆動開発が急速に進んでおり、特にWeb開発においてはAIを活用した事例が増加しています。この流れに乗り遅れないよう、モバイルアプリ開発でも今のうちに始める必要があると感じました。

そこで、VSCodeとClineを用いてiOSアプリのバイブコーディングを試みた結果、いくつかの不便さはあるものの、開発効率が大幅に向上する可能性を実感しました。本セッションでは、この試みの具体的な事例を紹介し、バイブコーディングの利点や課題について共有したいと考えています。

現在の多くの記事では、モックや新規アプリでの利用が主に取り上げられていますが、複雑な既存アプリにも十分活用できることを事例を交えてお話しします。具体的には、良かった点、課題、今後の期待について詳しく説明します。

また、もともと自チームでユースケース駆動設計を採用しており、これがバイブコーディングにおいて効果的であると感じています。この取り組みについても時間が許せば触れたいと思います。さらに、自社でのAI駆動開発の取り組みについても、許可が得られれば少し紹介したいと考えています。

Claude CodeやCursor、そしてXcode 26 ― iOS開発におけるAIアシストの選択肢は多くありますが、それぞれ一長一短あり、決定版はまだありません。とりわけ基盤をAppleが握るこの領域では、ほかの分野に比べて発展途上な部分がまだ目立ちます。

そこで鍵となるのが、AIと外部ツールを連携させるオープンプロトコル MCP です。本セッションでは、既存のAIコーディングアシストツールでは足りない部分を自作できるよう、MCPの基礎から実践までを解説します。

まずはFigma MCP、Xcode MCPといったiOSエンジニアになじみのある既存のMCPサーバーの使い方や機能から解説し、MCPの基礎を理解します。続いて最小構成のSwift製MCPサーバー実装を通してプロトコルの要点を学びましょう。あとはCLIやGUI、クラウドAPI等、iOS開発で役立つさまざまなツールをMCP経由でAIに道具として使わせる実践へと移ります。

足りないものは自作するのが我々エンジニア。AI向けの道具の作り方を覚え、AIをさらに便利に活用していきましょう。

１つ何かをするだけで膨大な再描画処理が行われ、画面が固まってしまうアプリ

ミニプロジェクトを立ち上げて改善しよう！
ここから始まったプロジェクトがまっっったくミニじゃなくなった
・どうして再描画がこんなにも発生しているのか？　→　トリガーがわからない
・永遠に引きずり回されてるデータがあるから不要なのはなくそう　→　数が多すぎて本当にわからない
・テキストを入力してから表示されるまでの流れを見てみよう　→　Viewファイル内で迷子になる
・ちょいちょい意味がわからないコメントが書いてある、伝わるように書いてよ..　→　（数ヶ月後に）最後の気力で残してくれた先人のダイイングメッセージと気づく

→　仮に再描画抑えれたとしても、保守できない。もう作り直すしかないね

こんな感じで大きく流れが変わったプロジェクトの

1. 正しい仕様書がない
2. 既存コードでの問題点/原因（結局把握はしきれなかった）
3. 対策/改善方法
4. 壮絶なリアーキテクチャ
5. こんなところまで良くなったね！本当に頑張った！ ダイイングメッセージもありがとう！

みたいな話

私たちの運用するアプリは、ファーストリリースから8年経ちました。リリース当初はWebViewを主体としたガワネイティブで開発されていました。しかし、ユーザー層の多様化（地下街のレストランや工場で勤務される方、最低限のスペックの社用端末を利用される方など）に伴い、通信環境が不安定な状況でのパフォーマンス課題が顕在化しました。特に、複雑なUIを持つ画面におけるもたつきやカクつきが、ユーザー体験を損ねているという課題に直面しました。

この課題を解決するため、そのような複雑な画面をガワアプリからSwiftUIに移行する計画を開始しました。
本セッションでは、その背景、技術選定、そして実現までの道のりをご紹介します。

• ゴール設定の策定基準について
• 長期間の開発が必要なリプレイスプロジェクトをどう社内に伝えたか
• 仕様やデザインの見直しはどこまで行ったか
• SwiftUIを主軸にすることで得られた開発・UIデザイン上の知見
• WebViewから移行する上で気をつけるべきこと
• 結果、どれだけパフォーマンスが改善されたか

複雑な画面のSwiftUI移行を検討されている方や、そのプロセスに関心のある方にとって実践的な学びとなれば幸いです。