トーク

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フレームワークを組み合わせて、猫との暮らしをハックする。そんな日常を拡張するアプリ開発の楽しさをお届けします。
実際にどのように検出されるかは、我が家の飼い猫「ビビ」の気まぐれ次第です。

ショッピングアプリや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アプリ開発の姿を具体的にイメージしていただき、自身の開発ワークフローを革新するための具体的な知識とノウハウを持ち帰っていただくことを目指します。手動による煩雑な作業から解放され、より本質的な開発に時間を費やすための第一歩を踏み出しましょう。

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 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万件以上のデータのインポート処理」を実装してきた経験を基に、実用的な速度と利用感を実現するための具体的な手法をお話しします。

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

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

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

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

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

現在、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移行を検討されている方や、そのプロセスに関心のある方にとって実践的な学びとなれば幸いです。

従来、iOSアプリに翻訳機能を組み込む際は、Google翻訳やAmazon Translateなどの外部APIに頼るしかありませんでした。これにより、従量課金・通信依存・オフライン非対応といった課題がつきまとっていました。

そんな中、iOS 17.4以降で登場した「Translationフレームワーク」は、Apple純正のオンデバイス翻訳モデルを活用することで、ネットワーク接続なし・高速・回数制限なしという理想的な翻訳体験を実現できます。

本トークでは、私がこのTranslationフレームワークをAVSpeechSynthesizerと組み合わせて開発した「喋った内容をオフラインでもリアルタイム翻訳するアプリ」を題材に、以下の実践的な実装ノウハウをお話しします。

• translationPresentationによる標準UIの制約と可能性
• SwiftUIのViewに依存するTranslationSessionをロジックに組み込む活用法
• AVSpeechSynthesizerとの組み合わせによる音声認識→翻訳→読み上げのフロー
• 翻訳モデルの自動削除問題と対処法（ストレージ管理）
• App IntentsやWidgetなど、アプリ外での応用可能性

また、実際に開発したアプリのデモを通じて、喋った内容がリアルタイムに翻訳・発話される様子をご覧いただきます。
このトークを通して、「どんな環境であろうとも瞬時に翻訳される体験」の実装方法を学ぶことで、みなさんのアプリにオンデバイス翻訳を導入する選択肢を広げていただければ幸いです。

楽天グループ株式会社が運営する「楽天リーベイツ」のiOSアプリは、2025年で9周年を迎えました。

2020年当時、8年以上にわたり運用されてきたiOSアプリを1人で引き継ぎ、数ヶ月間メンテナンスされていなかったレガシーコードに立ち向かいながら、ビジネス要件への対応、A/Bテストの実施、ユーザー体験の最適化、そしてチーム立ち上げを少しずつ進めてきました。

今回は、Biz やデザインチームの担当者と交渉しながら、iOS開発者としてどう目標を立て、どう改善を進めたか、その考え方をシェアします。最後に、これからの展望もお話しします！

WWDC 2025で発表された 「Liquid Glass」 は、10年ぶりのデザイン大刷新です。本トークでは元UI/UXデザイナー出身のiOSエンジニアが、秋の正式リリース前の今、知っておくべきポイントを、技術とデザインの両面から解き明かします。

• なぜ今Liquid Glassなのか？: 初代iOSのスキューモーフィズムからiOS 7のフラットデザイン、そして今回のLiquid Glassへ。Appleの技術とともに進化してきたデザインの変遷を振り返り、Liquid Glass導入の背景やAppleのビジョンを考察します。
• Liquid Glassとは何か？: Liquid Glassは従来の“ガラス風UI”と何が違うのか？デザインと技術の融合によって生まれたLiquid Glassの本質に迫ります。
• UIコンポーネントの変更点: UIの基本要素が実際にどう変わったのか、アイコン・コントロール・ナビゲーションの変更点を解説します。
• Xcode 26での実装方法: .glassEffect() や .buttonStyle(.glass) などの新APIの具体的なコード例、レガシーUIへの対応手段について紹介します。
• 実際にベータ版を触ってみた印象: 私がベータ版iOS26を実際に使ってみて感じた印象や課題を率直に共有します。
• デザイナーとエンジニアが連携すべきポイント: UI刷新はデザイナーとエンジニアの共同作業なくして実現しません。HIGの読み解き方や、実装側が意識すべき「デザインの意図」についても解説します。

このセッションを通じて、参加者は、今押さえておくべきLiquid Glassの思想や実装方法を学ぶことができ、自アプリへの導入にすぐ活かせる実践知を持ち帰れます。

日常生活の中でスマートスピーカーのように、声だけで家電を操作する体験が当たり前になりつつあります。音声操作体験に求められる期待値も徐々に上がってきています。

iOSではSpeech Frameworkを使うことでリアルタイム音声認識を実現することができ、AVSpeechSynthesizerを使うことで読み上げを実現することができますが、実環境下で運用するためには様々な課題に直面することになります。
例えば、iPadにケースを装着したことによる認識精度の低下、Speech Frameworkが対応していないWake Word検出の実現、読み上げ時の利用可能な音声の制約、OSのバージョンによる制約, プライバシーの考慮などの課題に直面します。

このトークでは、Speech Frameworkを使って音声だけで家電を操作する機能をリリース, 運用した経験をもとに、AVAudioEngine, Speech Framework を使った音声認識の基本から、上述したような実環境下で直面する課題の解決方法までを詳しく解説します。