トーク

「外は暑いのにオフィスは寒い！」毎朝の服選びで失敗する問題を解決するため、ハッカソンで開発したクローゼットアプリに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アプリのライフサイクルを深く理解し、より堅牢でパフォーマンスの高いアプリケーション開発を実現しましょう。

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

さて本LTでは、

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

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

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

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

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

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

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

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

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

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

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

React NativeやFlutterの甘い誘惑に惹かれTypeScriptとDartに浮気した結果、すぐに「やっぱり推しはSwift」と再認識。距離を置いたからこそ光った3つの推しポイントを紹介します。

・Swiftのenumでできること多すぎる件
　Associated valueで状態とデータを一体化。Computed propertyやメソッドも搭載可能。extensionで後から機能追加も。

・ありがとう guard let
　nilチェック、型キャスト、追加条件を一度に書ける早期リターン。if連打や深いネストを根本から回避し、読みやすさと安全性が段違い。

・Typed throws そんな文明まだない
　「この関数が投げるのはこのエラーだけ」と表現できる安心感。Result型で消耗しない世界線。

5分後、Swiftの強みを改めて噛み締めつつキーボードに向かいたくなる“再発見”ライトニングトーク。浮気で得た気づきとSwift愛をぜひ持ち帰ってください！

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

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

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

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

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

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

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

iOSアプリ開発における依存性注入（Dependency Injection: DI）は、設計やテストの柔軟性を高める技術として広く使われてきました。その手法は多岐にわたり、Protocolを活用した実装から、SwinjectやResolverなどのDIコンテナ、PropertyWrapperによる注入の工夫、そしてSwift Dependenciesのような最近のフレームワークまで、時代とともに選択肢が広がっています。

中には、型パラメータインジェクションのように、初めて見たときに「こんなやり方があるのか」と驚くようなユニークな手法もありました。それぞれのアプローチには、設計方針や技術的背景、実際の導入シーンに応じた向き・不向きが存在します。

本LTでは、これまでiOSで使われてきたDIの手法を簡潔に紹介しつつ、その変遷を整理します。各手法がどのような課題に対して提案されてきたのか、現在どのように使われているのかを俯瞰することで、これからDIを導入したい方や、既存の設計を見直したい方のヒントになることを目指します。

私、迅速大学4年のはやみ！視覚系の研究室で卒業研究のテーマに迷う普通の女子大生！

平凡な日常を過ごしていたある日、大学にApple Vision Proがやってきたの！Apple Vision Proに心を奪われた私は卒研で使うことを決意。必死で交渉する私の前に、一台のApple Vision Proが――

Apple Vision Proで実験をしたい！でもSwiftで3Dの実験アプリを作るのは大変！
そんな私がひねり出したアイデアとApple Vision Proとの格闘を見逃すなッ…！

というテーマで、私が実際に行った3年次事前研究「HMDを使用した情報表示における奥行き軸の活用と評価」の取り組みと、実験用アプリの開発の取り組みを紹介します。

このLTで話すこと

• 研究用3Dアプリ開発で直面したRealityKitのUI表示問題
• RealityKitによる3D空間へのオブジェクト精密配置とSIMD3活用術
• Apple Vision Pro初体験の被験者でも扱える操作方法とサポート術

iOSアプリ開発において、OSのバージョンや言語のバージョン等で今まで動いていたものが動かなくなることもあります。
非推奨なコードの中にはXcode上での警告によって簡単に気づき、修正することができるものもありますが、危険なコードではあるが警告が出ずにちゃんと動くものも存在するため、その例をいくつか紹介させていただきます。
危険なコードだが警告は出ない場合の例としては、「公式ドキュメントに定義されていない動作」 や 「公開されていないAPIに依存した実装」などが挙げられます。
それらを具体的なコードと共に紹介させていただきます。

Appleのドキュメントには、みんながよく知るKitたちが堂々と並んでいます。
でもそのすみっこには、目立たずひっそり、でもちゃんと役割を持ったKitたちが暮らしています。

「こんなアプリを作れたらいいな」と思ったとき、
ふとした偶然でそんな隅っこKitに出会うことがあります。
「あれ？知らなかったけど、こんなKitがあったんだ！」と、思わずほっこりする発見です。

このライトニングトークでは、そんなAppleドキュメントのすみっこで静かに息づく控えめだけど頼れるKitたちをゆるっと紹介します。
知られざるKitの世界を覗いて、ニッチなジャンルのアプリ開発の新しいアイデアを持ち帰ってもらえたら嬉しいです。
あなたの開発ライフの「すみっこ」で、静かに息づくKitたちの物語をぜひ覗いてみてください。

Kotlinカキカキソフトウェアエンジニアとして日々過ごしていてた私、iOSアプリ開発を始めるためにSwiftを業務のプロダクトで書き始めました。
KotlinとSwiftどちらもモバイルアプリ開発に使われる機会が多い、似ているシンタックス、簡潔な構文、非同期処理のネイティブサポート、表面的には非常に似た特徴を持つ２つの言語です。
一方で、書けば書くほどその裏側にある哲学が異なるのを感じます。

その違いを踏まえつつ、5分という尺をフルに使って、感じているあらためてSwiftのいいところを6個と、そして、気になるところを共有します。どちらが優れた言語だということを話すのではなく、改めてKotlinを長く書いてきたエンジニアの目線から見たときの「差分」を流れるように紹介し、議論に発展させる足がかりのLTにします

いいところ

• 値型を中心にした言語設計
• プロトコル指向(POP)による柔軟でテストしやすい設計
• 柔軟なenumによる表現力の高いデータモデリング
• Actorを中心とした安全な並行処理とそれを実現するコンパイラ
• SwiftUIのPreviewProviderによるPreviewの柔軟性の高さ
• macOSとの統一されたエコシステムによるXCodeの使用体験

気になるところ

• UIKitとSwiftUIを並行して使う・マイグレーションしていくうえでの障壁
• OSバージョンと機能が密結合するジレンマ
• SPM以外の依存関係管理ツールとの向き合いかたの難しさ・SPMへの移行の難しさ

中途入社でiOSエンジニアに転身。
そんな私に最初に与えられたタスクはiOSアプリへの「Google Cast SDKを使ったChromecastの実装」でした。

Chromecastってアプリ画面をテレビにミラーリングするもの？AirPlayみたいなもの？？
アプリの動きを見てそう思ったのも束の間、実際はまったく違いました。

スマホ（Sender）とテレビ（Receiver）がそれぞれ独立したアプリとして動き、相互に情報を送り合う独特なアーキテクチャ。

TVerやNetflix、YouTubeなどで見かけるキャストボタン。アプリでは目立つところにあるChromeCastですが、開発者にとってはドキュメントが少なく、
ハードルの高い技術です。（入社1年経った今でも難しい技術だったと思います）

このLTでは、Chromecastの基本的な仕組み、ハマりやすいポイント、実際のコード例を交えながら、リアルな開発の舞台裏をお届けします。

あなたのアプリは、すべてのユーザーに届いていますか？

VoiceOverユーザーが見落とすボタン、Dynamic Typeに対応しないレイアウト、コントラスト不足で読みにくいテキスト…これらは多くのiOSアプリが抱える課題であり、せっかく開発したアプリが一部のユーザーにとって「存在しない」ものになってしまう原因です。アクセシビリティ対応は、もはや「あればいいもの」ではなく、すべてのiOSエンジニアが取り組むべき「必須要件」です。

このトークでは、手探りのアクセシビリティ対応に終止符を打ちます。AIツールが、VoiceOverの読み上げ順序からDynamic Typeの最適化、さらには複雑なアクセシビリティ問題の検出と改善提案まで、あなたの代わりに「考える」ことで、いかに開発プロセスを劇的に加速させるかを具体的にご紹介します。

AIは、あなたのアシスタントとして、アクセシビリティ機能の実装を強力に支援し、見落としがちな問題を洗い出し、改善策を提示してくれます。もはや専門家でなくとも、誰もが使いやすい、真に「すべてのユーザーに届く」iOSアプリを開発できる時代が到来しました。

アクセシビリティを「特別なタスク」ではなく、「当たり前の開発プロセス」に変革するAIの力を、あなたのアプリ開発に導入しませんか？

ターゲット
・アーキテクチャの歴史を復習したい人
・最近iOS,Androidに触れ、昔の歴史を加味してアーキテクチャを理解したい人

概要
参加者の中には最近iOSエンジニアになった方や学生の方々も多いのではないでしょうか。
そんな方々に向けた、今までの歴史を振り返り、アーキテクチャの理解度を上げるためのセッションです。
初期からのアーキテクチャの主要な部分をiOS,Android横断で遡り、現状のTCA,MVVMなどの思想の分かれ方の理解を深めます。

詳細↓

テーマ理由
・宣言的UI普及により、アーキテクチャが転換期であるため
・他の方のセッションで最先端のアーキテクチャ考察があると考え、前提となるセッションがあった方が良いと考えたため。

初期（2008-2012）
iOS
・MVCが標準
・UIViewControllerが中心
・"Massive View Controller"問題の兆候
・デリゲートパターン
Android
・Activity中心
・"God Activity"問題の始まり
・Fragmentという概念の導入

パターンの確立期（2013-2017）
iOS
・MVVMパターンの普及
・ReactiveCocoa/RxSwift
・VIPER
・Swift登場
Android
・MVP推奨
・Architecture Blueprints
・Architecture Components発表
共通
・MVP、MVVM、Clean Architecture、Redux普及

宣言的UI時代（2018-2024）
iOS
・SwiftUI
・Combine
・MVVM
・TCA
Android
・Jetpack Compose
・Single Activity
・Navigation Component

実際の企業の採用状況
・9月時点の情報

iOSアプリ開発者の皆さん、デバッグとパフォーマンス最適化に費やす膨大な時間にうんざりしていませんか？

原因不明のクラッシュ、もたつくUI、そして悪夢のようなメモリリーク。これらは私たちの貴重な開発時間を容赦なく蝕み、リリースを遅らせ、ユーザーエクスペリエンスを低下させます。しかし、もうその苦しみは終わりです。

このトークでは、Xcodeに頼りきりだったデバッグと最適化の常識を覆します。CursorやClaude Codeのような汎用AIツールが、あなたの想像をはるかに超える形で、これらの複雑なタスクをどのように劇的に支援するのか、具体的な事例を交えてご紹介します。

AIは単なるコード補完ツールではありません。まるで熟練のベテランエンジニアのように、エラーの原因を光速で特定し、パフォーマンスのボトルネックをピンポイントで突き止め、手ごわいメモリリークさえも瞬時に検出する力を秘めています。

AIの力を借りて、あなたのiOSアプリ開発を次のレベルへ引き上げましょう。
無駄な時間を減らし、本当にクリエイティブな仕事に集中できる未来が、今、ここにあります。

　 ∧,,∧
　(；`・ω・）　　｡･ﾟ･⌒） カレンダー作るよ！！
　/　　 ｏ━ヽニニフ))
　しー-Ｊ

[話すこと]

• UICalendarView/DatePickerの特徴と使いどころ
• SwiftUIのカレンダーライブラリが無い？無いなら自作すればいいじゃない！
• 日本のカレンダーならではの話 〜曜日はどうやって取得する？祝日は？〜
• TabView + GridでカレンダーUI作るよ！！

アプリを多言語対応する際の最も面倒な作業はみなさんご存知ですか？
もちろんそうです。AppStore用のスクショの作成です！！！

アプリの画面を撮影してFigmaなどで上部に文章を加えるのがよくあるパターンですが、言語ごとにiPhone/iPad用のスクショを作成するのは単調な作業で全く面白くないです。
「でも多言語対応って言っても数言語でしょ？」と思うかもしれませんが、私が個人でリリースしているアプリでは16言語対応しています。
16言語分の各画面のスクショと言語ごとの文章を当てはめるのはただの苦行です。

このLTでは、そんな面倒な16言語分のスクショ作成を加速させた方法を紹介します。

• 各言語/地域ごとの撮影の自動化
• Figmaを活用した言語ごとの文章やスタイル設定の簡略化

実際、対応した言語圏のユーザからのinstall数は多いです。このLTを通じて皆さんの多言語対応の1つの壁を打ち砕きましょう！

アプリをインストールして起動すると表示される起動画面。
ロゴが表示されたり、さらにはアニメーションしたりすると、リッチに見えたりもします。
一方、通信環境が悪いところだとロゴの画面から全然動かなかったりすることも。

Human Interface Guidelines(HIG)には、「アプリ起動」の項目もあり、起動画面についてもガイドラインが示されています。
このLTでは、HIGに基づいたアプリ起動体験とベストプラクティスについてお話しします。

このセッションで話すこと:

• HIGの「Launching」と「Onboarding」について

このセッションで話さないこと:

• アプリ起動のパフォーマンス改善手法