プロポーザル

あなたのiOSスキルを使って、もっと多くのユーザーにアプリを届けられたら、素敵だと思いませんか？本セッションでは、私たちがなぜKotlin Multiplatform（KMP）を選択したのか、どのように既存のスキルを最大限活用したのか、そして実際の開発で得られた貴重な学びを詳しくご紹介します。KMPにより、iOSとAndroidの両方で迅速かつ高品質なアプリを実現し、開発の可能性を大きく広げました。
クロスプラットフォーム開発に興味はあるけれども、iOS開発のクオリティを維持したい方に最適な内容となっています。ぜひご参加ください！

「外は暑いのにオフィスは寒い！」毎朝の服選びで失敗する問題を解決するため、ハッカソンで開発したクローゼットアプリにESP32を使った遠隔温度モニタリング機能を組み込みました。家にいながらオフィスの温度がリアルタイムで分かる機能です。

クローゼットアプリを作っていて気づいたのが、天気予報だけじゃ服装選びは完璧にできないということ。特に夏場、外は35度なのにオフィスは極寒の20度とか、もう何着ていけばいいか分からない。ハッカソンメンバーからも「私もオフィスのエアコンで凍えてる」「私も毎朝カーディガン持っていくか悩む」という声があがって、それならESP32でオフィスの温度を取得して、アプリに組み込んじゃえばいいじゃん！と思って実装しました。

技術的にはESP32にDHT11温湿度センサーを接続して、5秒ごとにFirebase Realtime Databaseへデータ送信。クローゼットアプリ側ではDatabaseReferenceの.observe(.value)でリアルタイム監視して、取得した温度データを服装提案アルゴリズムに組み込みました。ESP32側でハマったのがFirebaseの時刻同期問題で、NTPサーバーで時刻合わせしないとトークン発行でエラーになって2時間溶かしました。Firebase.reconnectWiFi(true)の設定で、オフィスのWi-Fiが不安定でも安定動作するようになったのは大きな発見でした。

アプリ側では温度によって服装提案を変える仕組みを実装。オフィス温度20度未満なら「カーディガン必須」、27度以上なら「半袖OK」といった具合に、外気温とオフィス温度の両方を考慮した提案ができるようにする予定です。IoTデバイスとモバイルアプリを連携させることで、身近な課題を解決したいです。

大学の授業で、現実世界のサバゲーをデジタルで再現するシステムを開発しました。ESP32の赤外線センサーで被弾を検知し、BLE通信でiOSアプリに即座に通知。SwiftUIで実装した画面上でリアルタイムに体力が減少する仕組みです。
開発のきっかけは「みんなでサバゲーがしたい、でも痛いのは嫌」という単純な動機でした。ESP32にIRrecvライブラリで赤外線受信機能を実装し、被弾検知時にBLEで"button"メッセージを送信。iOS側ではCoreBluetoothでBLE通知を受信し、@Publishedプロパティで体力を管理することで、撃たれた瞬間に体力ゲージが減る体験を実現しました。
実際に授業で複数人対戦を行った際の発見として、Bluetoothは障害物があっても意外と通信が安定していること、赤外線の直進性とBLEの回り込み特性により予想以上に戦略的なゲームプレイが生まれたことなどがありました。プレイヤーごとに異なるUUIDを設定することで、最大10人程度の同時対戦も可能です。
本セッションでは、Arduino（ESP32）側のBLEサーバー実装とiOS側のCoreBluetoothクライアント実装を中心に、ハードウェアとソフトウェアを連携させる際のポイントや、実際に遊んでみて分かった課題と解決策を共有します。今後はCore Locationによる位置管理機能の追加も計画しており、より本格的なレーザータグ体験の実現を目指しています。

iOSアプリ開発において、アプリのライフサイクルイベントは多岐にわたり、AppDelegateやUISceneDelegateのどのデリゲートメソッドがどのタイミングで呼ばれるのか、またそれぞれの適切な使い所について、混乱したり、意図しない挙動に悩まされたりした経験はありませんか？

本トークでは、起動から終了に至るまでのアプリの様々なライフサイクルイベントを網羅し、デモアプリを用いて各イベントで動作するデリゲートメソッドを視覚的に解説します。メジャーなものから見落とされがちなマイナーなものまで、それぞれのメソッドの正確な呼び出しタイミング、推奨される利用シーン、そして具体的な実装例を交えながら、明日からの開発に役立つ実践的な知識を提供します。このトークを通じて、iOSアプリのライフサイクルを深く理解し、より堅牢でパフォーマンスの高いアプリケーション開発を実現しましょう。

iOSアプリエンジニアとして、ビジネスやデザインの要望にただ従うだけになっていませんか？
iOSプラットフォームは我々の手で育てていくものであり、その中で「iOSらしさ」をどう守り、活かすかが重要です。

このLTでは、ガワネイティブやクラスプラットフォームによる開発が広まる中で、iOSアプリをあえてネイティブで作ることを提案・実現していくための考え方を紹介します。
「これがiOSの良さ」と言えるポイントを明確にし、プロダクトの方向性にiOS開発者として主体的に関わるきっかけになれば幸いです。

皆さん、iOSアプリ開発でTCAを使ったことはありますか？

正直、TCAってめっちゃ難しいですよね...
TCAはiOSアプリ開発において採用されることが多いアーキテクチャパターンの1つです。
単方向データフローにより処理の流れの処理の流れが追いやすく、またアプリの状態管理やコンポーネントごとのテストが実施しやすいという特徴がある一方、コードの書き方が独特で初期学習のコストが高く、規模が小さいアプリではオーバーエンジニアリングになりがちというデメリットもあります。

最近は勉強会や技術記事で取り上げられる機会も多く、また公式のチュートリアルも充実しているため、TCAを導入するハードルはかなり下がりました。
しかし、これらで触れている内容はあくまで「導入」や「コーディング」に関することであって、アプリの「運用・保守」に関する情報はあまり多くないように感じます。

最近はTCAを採用したアプリも多くリリースされており、私も複数のプロジェクトでTCAを使った新規開発や保守・運用を経験してきました。
実務でTCAを使った開発を行う中で、勉強会や技術記事などではあまり触れられていなかったTCAのメリット・デメリットは想像以上に多くありました。
このトークでは、私が実際にTCAを使ってみて率直に感じたホンネを皆さんと共有したいと思います。

アプリのアーキテクチャというものはコードの根幹を支えるものであり、一度決めると変更することはなかなかできません。
現在アーキテクチャ選定に悩んでいる人や、これからアプリ開発を行う人に向けて、このトークを贈りたいと思います。

jpg、 png、gifにwebp

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

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

WWDC25に当選した俺は、サンフランシスコ国際空港に降り立つや否や自動運転配車サービス「Waymo」を体験するため、WaymoのiOSアプリを起動する。
初めてのアメリカ。初めての自動運転。位置情報サービスをONにし、心を踊らせながらアプリの起動を待つ。
しかし、Waymoアプリは 「Outside service area」 を示すのだった——

さて本LTでは、

・なかなか乗れないWaymo
・ついに体験するWaymo
・かわいそうなWaymo

以上3本についてお話しします！

アプリのUIや乗車体験、料金などを踏まえ、日本でサービス展開されるときの妄想をみなさんにお届けします。

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

SwiftUIはiOSアプリ開発において魅力的なフレームワークですが、急速な進化によって「いつの間にか非推奨になっていたAPI」が数多く存在します。

例えばiOS 15から非推奨となった「Text以外のforegroundColor」、iOS 17から非推奨になった「TextのforegroundColor」、iOS 18からTabViewの従来の実装方法がdeprecatedになっているなどがあります。

本発表では、個人開発と業務開発での経験から発見した非推奨APIの罠と、SwiftUIコードの中に潜む"隠れた非推奨API"を発見する方法、各OSバージョンに適したモダンな代替手段を解説します。

たとえ今は大きなエラーが発生しなくても、Appleの推奨や新しいAPIを知っておくことで、将来的なトラブルを避けやすくなります。ただし、プロジェクトのミニマムターゲットや開発環境によっては、推奨される書き方がすぐに使えないことも少なくありません。
本発表では、最新のベストプラクティスを「選択肢」として持ちつつ、現場で柔軟に対応できる実践的な知識を具体例とともに共有します。

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

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

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

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

具体的には

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

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

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

ベンチャー企業から有名ベンチャー企業への転職を成功させ、年収アップを実現した私の経験とそのコツについてお話しします。

まず、転職を考えた理由ですが、キャリアアップと年収の向上を目指していました。特に35歳を過ぎるとリーダー経験が求められることが多く、転職難易度が上がるため、若いうちに戦略を練ることが重要です。

私が転職を成功させたポイントは以下の通りです：

「技術スキルの向上」
Swift、Objective-C、そして最新のiOSフレームワークを使いこなすことができるようにしました。
特にSwiftUIやCombineなどの新しい技術を積極的に学び、プロジェクトに適用しました。

「問題解決能力」
チーム内でのコミュニケーションを重視し、問題が発生した際には迅速に対応しました。
例えば、アプリのパフォーマンスが低下した際には、コードの最適化とアーキテクチャの見直しを行い、パフォーマンスを30%向上させました。

「職務経歴書の見やすいフォーマット」
職務経歴書は、プロジェクトごとに成果を数字で示し、具体的なエピソードを交えて記載しました。

「面接官との想定問答」
面接官が求める人材や解決したい課題を事前にリサーチし、それに対する解決策を具体的なエピソードで説明しました。

「リーダー経験の積み方」
若いうちからリーダー経験を積むために、プロジェクトリーダーやチームリーダーの役割を積極的に引き受けること。

「会社の情報を洗い出すAIプロンプトの紹介」

転職先の会社がリモートワークに適しているか、出社が求められるかなど、自分に合った働き方ができるかをリサーチするために、AIプロンプトを活用しました（本番で詳細にお伝えいたします）

これらの戦略を駆使して、私は転職を成功させ、年収アップを実現しました。ぜひ参考にしていただきたいです！

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

iOSアプリ開発において、
UIVisualEffectViewやSwiftUIのMaterialを使った”ガラス風エフェクト”は手軽に利用できますが、
水滴のように屈折しながら混ざり合う“Liquid Glass Effect”は、
iOS26未満で対応していません。

iPhone8、Xのユーザーは、それを許してくれるでしょうか？
iOSエンジニアとして、それを見逃して良いのでしょうか？
それだけではありません。
UI差分は、QAコストの増大にも少なからず影響してきます。

本LTでは、「光の屈折」や「パフォーマンスの工夫」に触れながら、
UIKit/SwiftUI上でglassEffectを一切使わない、
簡易Liquid Glassエフェクトを再現する方法を紹介します。

iOS26未満でもLiquid Glassを使いたい！
そんなワガママを叶えられるセッションとなっています。

In-App Purchases(以下IAP)のサービスを展開していると、様々な問題に遭遇することがあります。
例えば申請内容に不備があってrejectされてしまった、IAPの公開日時が設定できない、求められるアカウント権限が強すぎてやりたい操作ができない、App Storeでエラーが出ているがこれってユーザーに告知していいの、などなど。。。

これらの問題についていろいろ質問したいなぁと思っていたところ、運よくWWDC25に参加できることになりました。
また現地ではApp Storeのオフラインlabが開催されており、実際に参加し色々質問してくることができました。
ただ人気のlabのため事前登録が必要、labの時間は15分のみ、通訳もなく英語に自信がない、Apple Parkは初めていくので色々と不安な自分は色々と準備をしていくことになりました。。

このトークでは、App Store Lab参加までの準備や実際の様子、何を質問し何を得られたのかを共有をします。
labには何を準備していったら良いのか、現地labはどんな様子なのか、labでは何を得られるのか、皆さんのlab参加への一助になるような話ができればと思います。

ゴール:
・Appleのlabに参加するためにやっておいた方が良い準備がわかる
・実際のlabの様子を知り、labに参加する意欲が湧く

アジェンダ:
・何に困っていたのか
・App Store Lab参加のための準備
・labの実際の様子、得られた回答

対象者:
・labの様子や回答内容が知りたい方
・labに参加してみたいがまだ勇気が出ない方

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

内容:

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

ちょっとそこのあなた、「Swift 6の新機能を使いたいのにSwift Concurrencyの対応をしないとまだSwift 6にはできない」などと思っていませんか？

もしあなたがXcode 16をインストールしXcode CLI ToolsをXcode 16と設定してビルドできている時点で、実はもうSwift 6によってアプリをビルドできているのです。なぜなら、Xcode 16のCLI Toolsに同梱されるSwiftコンパイラバージョンはSwift 6だからです。つまり、あなたはすでにSwift 6の言語機能も使えるんです。

勘違いの原因として、デフォルトでlanguage-modeがSwift 5と設定されていることをSwift 5系でコンパイルしている、と勘違いしている可能性があるんじゃないでしょうか。またはPackage.swiftの最上部に書かれた// swift-tools-version: 5.xをコンパイルするSwiftのバージョンと勘違いしているということはないでしょうか？

このLTでは、CLI Toolsの基礎、コンパイラバージョンとlanguage-modeの違い、それが提案されたSwift Evolutionのプロポーザルなどについて話します。

Liquid Glass、いいですよね。私もユーザーとして触ってみたいです。

Liquid Glass といえば、Flutter は独自のレンダリングエンジンで画面を描画しているため Liquid Glass を使えず公式も対応を見送っている、という話をご存知でしょうか。ということは Flutter を使っている限り「古い」見た目のアプリしか作れないのでしょうか？

、、と悲観的に見てしまうのはちょっと軽率です。

そもそも Flutter の UI に対する優先度はそこではありません。Flutter の UI に対する姿勢には「プラットフォーム標準」よりも優先したい要素があり、Flutter アプリ開発者にとって Liquid Glass の完全再現はそこまで求めるものでもなかったり、というかそもそも「Liquid Glass が使えない」にも語弊がありまして、、そんな話を 5 分間だけ好き勝手に話させてください！