トーク

「暑い日にスマートフォンを使っていて、アプリの動作が遅くなった…」そんな経験、ありませんか？
特に屋外で利用されるアプリにとって、端末の温度はユーザー体験を大きく左右する重要な要素です。
スマートフォンが熱を持つと、アプリのパフォーマンスが著しく低下したり、一部の機能が制限されたりすることがあります。このような影響を把握しておくことは、快適なサービス提供のために非常に重要です。

本LTでは、Foundationフレームワークに含まれる ProcessInfo.ThermalState API に注目します。このAPIを使うことで、デバイスの熱状態を4段階で把握することが可能です。
今回は、実際に屋外で利用されるモビリティアプリにおいて、春から夏にかけてThermalStateがどのように変化するのかなど、実測データと共にご紹介します。
さらに、端末が高温になった際にアプリが取ることができる対策についても触れます。

スマートフォンを「熱中症」から守り、夏でもクールで快適なユーザー体験をお届けしましょう！

皆さん、サーバ側で時間がかかる処理のハンドリングや、進捗を表示する際、ついポーリングで実装していませんか？
弊プロダクトでもポーリングを採用するケースが多かったのですが、これからのプロダクトの進化に備えてSSE通信基盤をモバイルアプリで構築し、全面的に採用しました。
本セッションでは、Server-Sent Events(SSE) という2009年から存在する歴史の長い技術について詳しく説明し、ポーリングと比較した際のメリット、生成AIを活用したプロダクトにおけるUX向上の実例も交えて解説します。

• SSEの技術的な説明
• ポーリングとSSEの比較
• 生成AIとSSE
• プロダクトでの活用事例

「ポーリング以上、WebSocket未満」
そんな立ち位置のServer-Sent Events(SSE) がこの大LLM時代の流れに乗って知名度が上がり、普及されることを祈ってお届けします。

最近、一部のiPhoneでApple Vision Pro向けの空間写真や空間ビデオを撮影できるようになりました。しかし、「立体的に表示するにはApple Vision Proが必要で、あまり使っていない」という方もいらっしゃるのではないでしょうか？実は、Meta QuestやPICO 4といったHMDも対応していますし、Looking Glass Goを使えばHMDを着用せずに楽しむこともできます。

さらに、iPhoneの保護ガラスとしても機能するSpatialGlassを利用すれば、もっと手軽に空間写真と空間ビデオを楽しむことができます。本トークでは、空間写真と空間ビデオの基本概念の理解から始め、効果的な撮影のコツを共有し、撮影後の楽しみ方までを一気通貫でお伝えします。

※空間写真と空間ビデオの特性上、スライドではその魅力を十分にお伝えしきれないため、会期中にお声がけいただければ、いつでも実物をご覧に入れます。

iOS初期のスキューモーフィズムは現実世界を画面に写し取ることで触れたくなるデザインを生み出しました。iOS7ではフラットデザインへと進化し、画面内での抽象的な操作感が当たり前になりました。そして去年の登壇で私は、iOSらしさとは「画面上の要素が現実世界に近い挙動をしていること」だと話しました。私たちはこれまで、四角い画面の中にUIを閉じ込め、その中で現実世界に近い挙動を再現してきました。
そして今、Apple Vision Proの登場やLiquid Glassのような技術によって、画面という枠の存在感が薄れ、UIは現実世界とソフトウェアが直接つながる存在へと変わりつつあります。

この登壇では以下の内容をお伝えします。

1. Appleの新しいデザインシステムがどのように「空間に馴染むデザイン」へ進化しているか
   iOS26で変わった光の扱いやマテリアルの表現、奥行き感の演出など、具体的なUIデザイン要素を解説します。

2. 画面がありながらも空間に馴染むデザインを目指している、いま私がつくっているプロダクトの紹介
   顔認証やドア前での会議室予約を行う常設型アプリのUI設計では、ユーザーの手元にデバイスがあるわけではないため、空間に自然に馴染むデザインが求められます。その中で実践したUI設計の工夫や試行錯誤を共有します。

3. 画面という枠がなくなる未来を見据えた体験設計のヒント
   画面内だけでなく周囲の物体や光、空間の広さなど現実世界の制約を踏まえたUI/UX設計で何が求められるかを考察します。

現実世界と一体化したデザインを目指してプロダクトをどう進化させていくか、一緒に考えていきましょう！

Apple Vision Proの登場により、Safari上で動作するWebXRの可能性がますます広がっています。
本セッションでは、WebXR Device APIの基本とともに、Safari on visionOSとSafari on iOS間で体験できるWebXRの違い、Meta Quest Browser とのAPI対応差を整理しながら、Apple Vision Proならではの“Spatial Web”体験を掘り下げます。
可能性は広がりましたが、まだできないこともあるので何ができて・何ができないかを明確にします。
さらに、WebKit公式ブログで発表された visionOS 26（Safari 26）で強化される新機能にも触れ、空間表現の可能性が今後どう広がるのか、予想される今後の展望を解説します。
ネイティブアプリとの棲み分けを意識しつつ、来たるべき“Spatial Web”時代に備えるための視点を提供します。

皆さん、最近健康診断は受けましたか？
実はアプリでも健康診断は行われているんです。

起動時間やHang率など、パフォーマンスデータは自動で記録されています。
ただし、それを確認するにはXcode Organizerを開いて自分で見に行く必要があります。
でも、わざわざ開くのは面倒だし、忙しいとつい忘れてしまいます。
そのまま見逃してしまえば、アプリからのSOSに気づけないままに…。
・バッテリー消費が激しい
・スクロールがカクつく
・画面がフリーズする
こうした不調が続けば、ユーザーのiPhoneからあなたのアプリが静かに削除されてしまうかもしれません。

本トークでは、App Store ConnectAPI × GitHub Actions で構築する自動パフォーマンス監視体制について、5分で解説します。

Next Talk's HINT：
・App Store ConnectAPI（perfPowerMetrics）
・GitHub Actions
・Xcode Organizer

現代のiOSアプリ開発において、インデントは4スペースではなく2スペースが選択されていくべきであり、将来的には4スペースを使っているのはレガシーコードの匂いがするようになる、という話をします。

まず、2スペースの長所と4スペースの短所を明確にし、世界のSwiftスタイルガイドやOSSプロジェクトでの2スペース選択状況を解説します。さらに、個人プロジェクトで2スペースを導入する具体的な方法についても実践的なアドバイスを提供します。

このセッションの後には、4スペースを疑いもなく使うということはなくなり、思い込みを捨て2スペースを採用する参考になれば幸いです。

SwiftUIを使っているあなたは 実はすでに関数型プログラミングに入門しています 。なぜならSwiftUIの宣言的なUI記述は、関数型プログラミングの宣言的アプローチをUI構築において採用したものだからです。

UI構築における宣言的アプローチの「どのように描画するか」ではなく「何を表示するか」を記述する思考法は、複雑さを排除して予測可能性を高める関数型プログラミングの戦略と同じと言って良いでしょう。しかし多くの開発者はUI以外のコードでは手続き型の書き方に戻ってしまいます。もしビジネスロジックやデータ処理、またはテストコードでさえも関数型プログラミングの宣言的アプローチを使えば、「どのように処理するか」でなく「どのような結果が欲しいのか」を明確に記述でき、コードの予測可能性と可読性を向上させることができます。

これからはAIがコードを書いていく時代でもあり、AIに的確かつ多くの指示を出していきコーディングをしていくことは逃れられません。しかし、AIへ宣言的アプローチを使わせず低い可読性のコードを生成させる場合、コードをレビューをするあなた自身がボトルネックとなるはずです。もしくは、コードをレビューをせず何も考えずにAIに言われるがまま、良さげな結果のガチャを引き続けることになるのでしょうか。しかし、そんなやり方でソフトウェア開発を楽しめると思えますか？あなた自身は到来するAI時代に確固たる自信を持つタイミングはくるのでしょうか？ なぜあなたはSwiftを使っているのにUI以外でも関数型プログラミングをしていないのか、いますぐやるべきではありませんか？

このセッションでは、SwiftUIで慣れ親しんだ宣言的アプローチを他の領域にも拡張する具体的な手法とメリットをビフォーアフターとともに解説します。

プロジェクトごとのXcode設定調整の煩わしさを解消し、チーム内でのフォーマット不一致や記述ルールの食い違いに終止符を打ちませんか？
コードスタイルの一貫性は、可読性向上、オンボーディング効率化、そしてチームの健全なコミュニケーションに直結する「チームの調和」の要です。

これまでのXcodeでは、コードスタイルの統一を手動で行うことが多く、この運用は負荷が高いという課題がありました。
しかし、Xcode 16から待望の.editorconfigが標準搭載され、Xcodeはプロジェクトのルールに則った賢いエディタへと進化しました。

本セッションでは、この革新的な変化を徹底解説します。
.editorconfigの基本から、Xcode 16でサポートされる全プロパティについて解説し、各プロパティがコードにどのような自動整形をもたらし、「完璧なコードスタイル」を築くのかを、コード例やデモを通じて視覚的にご紹介します。

特に、大規模プロジェクトでインデントスペースを4から2に統一する際に直面した、数万行規模の変更に伴うコンフリクト回避とその解決策に焦点を当てます。

ゴールは、Xcode 16の.editorconfig活用により手動設定の煩わしさから解放され、堅牢で美しいコードベースを効率的に維持できる開発環境を手に入れることです。あなたのチーム開発に「完璧なコードスタイル」と「真の調和」をもたらす第一歩を踏み出しましょう。

広島という地方生まれの私がパソコンを触るようになったのはExcelでお小遣い管理を始めたのがきっかけでした。そこからVBAを触ったりブログを作ったり、Webサービスを開発するようになりました。最初は書籍を通じて学べていたものの、次第に相談できる人が必要になりました。でも周りに詳しい人はいませんでした。

そんな時出会ったのが地域のITコミュニティでした。
メンバーに相談していく中でカンファレンス運営に携わる機会やインターンを紹介して頂くこともできました。

今、僕が都内でiOSエンジニアとして働くことができるようになったのはコミュニティ活動によるものが大きいと実感するようになりました。
上京や転職など私の人生に大きく影響しているITコミュニティ活動について変遷を紹介します。

iOSDCをはじめとするカンファレンスやSwift愛好会などのコミュニティなどは基本的に有志のメンバーが活動・運営しています。
このセッションを通して少しでもコミュニティに興味を持っていただけると幸いです。

日々の開発作業でシミュレータを操作する際、細かな手間が積み重なって、貴重な時間を奪われていませんか？

「ダークモードの表示を確認したいだけなのに、ホーム画面に戻って、設定アプリを開いて、デベロッパメニューをタップして…。」
「プルリクに添付する動画を撮りたいけど、QuickTime Playerを起動して、収録範囲を選ぶのが地味に手間…。」

そんな、誰もが経験する「ちりつも」な手間に、貴重な開発時間を奪われていませんか？

もし、その面倒な操作がキーボードショートカット一発で片付いたら、どうでしょう？
例えば、あれだけ手間だったダークモードとライトモードの切り替えも、たった一つのコマンドで瞬時に行えます。

本トークでは、このように日々の動作確認を劇的に効率化する、選りすぐりのショートカット術をデモを交えて紹介します。
画面の回転やスクリーンショットといった基本技はもちろん、意外と知られていない2本指操作やシェイク操作など、知っているだけで開発体験が格段に向上するテクニックを厳選しました。

このセッションを聴き終えれば、あなたはもうマウスに頼ることなく、キーボードだけでシミュレータを自在に操れるようになります。開発をもっと快適に、もっと集中できる時間にしましょう。

※ 本セッションは非常に真面目な内容となっております

iOSアプリ開発において画像リソースを格納することは多々あるかと思います。
でもその格納するファイルの形式や内部の構造について正しく把握していますでしょうか。何も考えることなくPDFやSVG形式にしていませんか？
ファイル形式や方法を間違えるとたった100KBの画像を格納したつもりでも、アプリサイズを30MB増えたりする可能性もあります。

本セッションでは、普段何気なく利用している画像リソースの拡張子や格納方法について現時点のベストプラクティスを探求し、効率的な格納方法を見つけ出していきます。

Swift OpenAPI Generatorは、Appleがオープンソースで開発を主導するOpenAPIから関連コードを自動生成するツールです。
このテクノロジーの魅力は、既存のツールと比べてよりSwiftらしい型による安全な表現が実現できる点にあります。
しかしながらSwift OpenAPI Generatorへの移行には、注意すべき点が複数あり、必ずしも簡単とはいえません。具体的には、次のような点に注意が必要です。

• ローカルのモックサーバーへの接続時の注意事項
  ローカル環境でのモックサーバー接続の際に発生しやすい問題点を特定し、それに対する具体的な対策を説明します。

• エラーのハンドリング
  よくあるエラーケースを紹介し、それらをどのように効果的に処理するかについて解説します。

• 生成された型のドメインモデルへの変換
  自動生成された型をアプリケーションのドメインモデルに効果的に統合するための手法を紹介し、コード例を交えて具体的に説明します。

このセッションでは、上記の課題に対する知見を共有し、参加者が実際にSwift OpenAPI Generatorを導入する際の手助けとなることを目指します。

筆者はiOS開発についての技術記事を5年ほど継続的に書き続け、2025年には「iOS開発の教科書」という電子本を執筆するに至りました。本セッションではiOS開発という枠組みを超えて、テクニカルライティング（技術的な内容の文章作成）についての実践知を共有します。テクニックに関しては他にもっと専門的に論じられているものがあるので、モチベーションの部分を厚めに話します。

• モチベーション(10分)
  • 何のために技術発信を行うのか
  • 技術発信はムリして行わなくて良い
  • 公開することの意味
  • 生成AI時代に人間が書く意味
  • 「ネタがない」と戦う
  • マサカリと戦う
  • 「反響がない」と戦う
• テクニック(10分)
  • なぜ技術情報は伝わらないのか
  • 良いドキュメントとは何か
  • 上手く伝えるためのテクニック
  • 技術記事と本の違い

技術発信をしてみたいが躊躇している方の後押しになるのはもちろん、そうでもない方でも日常の技術情報の伝え方の改善につながる内容になるかと思っております。

複数アプリを開発している環境では、あるアプリの機能を別のアプリでも使いたいシチュエーションがあるかと思います。しかし、アプリ全体をパッケージとして公開するのは、規模の大きいアプリでは現実的ではありません。マルチモジュール化されたアプリであれば、必要なモジュールだけを公開したいところです。

Swift Package Manager（SPM）のローカルパッケージ機能を活用することで、特定のモジュールのみを公開し、そのモジュールが依存する他のモジュールは非公開に保つことが可能です。

本セッションでは、SPMを使って特定のモジュールだけを公開する具体的な方法を解説します。また、実際にこの手法を試した結果、期待していたモジュールの隠蔽が実現できず、最終的に採用を見送った経緯についても共有します。

iOSには、サーバーから送られるプッシュ通知と、アプリ内で発行するローカル通知の2種類の通知があります。通知といえばプッシュ通知が目立ちがちですが、実はローカル通知にもたくさんの活躍の場があり、通知UXを支えるうえで欠かせない存在です。状況に応じて、プッシュ通知よりも頼れる選択肢になることもあります。
たとえばアプリがフォアグラウンドにあるとき、プッシュ通知で通知内容を表示しようとすると、UIの更新に必要な情報の取得に失敗することで、アプリの表示と通知の内容が食い違ってしまうことがあります。このようなケースでは、アプリ内部の処理が成功してからローカル通知を表示することで、より安定した通知体験が実現できます。
本トークでは、ローカル通知の特徴や活用シーンを整理したうえで、チャットアプリの実装を例に、プッシュ通知との使い分けや、通知の見た目や動作を整えるための設計上の工夫について紹介します。
Communication Notifications、通知へのアクション、スレッド表示など、プッシュ通知でおなじみの表現がローカル通知でも実現できることを確認しながら、通知UXをより良くするための工夫を共有します。
あなたのアプリでも、ローカル通知が思わぬ形で役立つかもしれません！

リリース作業ってどうしてこんなにも面倒なのでしょう？

アプリを公開するには切っても切り離せないリリース作業。

会社やアプリの規模が大きくなるにつれて利用するツールも増えていきがちで、
・GitHubのリリースノート作成
・リリースブランチ作成
・マイルストーン更新
・Notionで各所に連絡するための資料作成
・QA用の項目列挙…
など多くの "頑張れば自動化できるが中々自動化するには腰が重い" 作業がつきまとってしまいます。

複雑なリリース作業は特定のメンバーに依存してしまうことや、新しいメンバーが覚えにくいなどの問題も発生する可能性もあります。
さらに、仮にBotを作成してもiOSエンジニアには馴染が薄い別の言語を選択せざる負えない状況になってしまうことや、複雑な実行環境が要求される可能性もあります。

こうした問題を解決するため、AWS Lambdaで実行できるSwift製のSlackアプリを開発しました。
本セッションでは、このSwift製リリース作業Slackアプリの開発・運用方法について紹介します。

我が家はかわいい猫と暮らしています。ネットワークカメラとして設置したGoogle Nest Camは、Google HomeのアプリとWebでカメラ映像をストリーミング視聴可能です。せっかくなのでペットの行動をリアルタイムで把握でき、安心して外出できるように、macOSやvisionOSでも実行可能なアプリが欲しくなりました。Smart Device Management APIとWebRTCを使って、ストリーミングアプリを手に入れましょう。Appleプラットフォームでアプリを実装することで、映像再生に留まらず、自分自身で機能拡張が可能になります。Google Nest Camからの映像をAppleデバイスで解析し、VNDetectAnimalBodyPoseRequestを使って猫の骨格を検出、かわいいポーズを可視化するアプリを開発しました。
本LTでは「Smart Device Management APIの準備」「WebRTCでの映像接続」「Vision.frameworkでの映像解析」を経て、制御可能なストリーミングアプリを作成する過程をギュッと5分で紹介します。この発表を通じて、ハードウェアとAppleプラットフォーム技術を組み合わせる楽しさをお届けします。
猫は気まぐれ、開発では振り回されましたが、それもまたかわいいものです。

対象聴衆

• ペットと暮らし、Google Nest Camや類似のネットワークカメラをお持ち方
• Swift/SwiftUIでWebRTCやVision.frameworkを使ったリアルタイム映像解析に挑戦したい方
• とにかくかわいい猫に癒されたい方

現代のiOS開発において、パフォーマンス向上のために並行処理は不可欠です。
Swift Concurrencyは、async/awaitによる非同期処理の記述を簡潔にするだけでなく、Actorや構造化された並行処理によって、これまで開発者を悩ませてきたデータ競合という危険なバグから、コンパイル時という開発の早い段階で私たちを解放してくれます。
これは、これまでの並行処理技術にはなかった画期的な「コンパイラによる安全保証」という大きな特徴を持っています。

では、Swift Concurrency以前はどうでしょう？
例えばGCDやOperationQueue、さらにはNSThreadといった技術はどれほど簡潔ではなく安全ではなかったのでしょうか？
これらの技術は、スレッド管理を抽象化したり、排他制御の基礎機能を提供したりはしましたが、その安全性は常に開発者自身の厳密な規律に依存していました。
一つでも排他制御を忘れると、予期せぬクラッシュやデータの破壊を引き起こすリスクに常に晒されていたのです。

このトークでは、この並行処理の歴史を、現代のSwift ConcurrencyからNSThreadへと遡りながら、その安全性の進化を比較・解説します。
シンプルなカウンタからファイルダウンローダーを例にSwift Concurrency、OperationQueue、GCD、NSThreadの実装例をお見せします。

Swift Concurrencyが目指している安全性を歴史から学び、自信を持ってコードが書ける一助になれば幸いです。

XcodeのデフォルトデバッガであるLLDBはPythonで拡張できますが、あまり知られておらず広く使われていないようです。本トークではPythonによる拡張について、実際に使ってみて得られた知見をお話しします。

LLDBはPythonスクリプトによるコマンド作成をサポートしており、デバッガ内のメモリ・シンボル・ソースコードへのアクセスだけでなく、MacOSのファイルシステムやネットワークリソースも利用可能です。また、Pythonの豊富なライブラリを活用することも可能なので、手軽に実用的な拡張を作成できます。

例えば、変数のログを記録したい場合、コンソールに出力するのは手軽ですが、他のログと混ざってしまいますし、実行のたびに消えてしまいます。代わりに、値をファイルに追記するスクリプトを作成してブレークポイントで呼び出すことで、対象のログだけを記録することが、コードの変更なしに可能になります。

別の応用例として、C++で使っている独自形式の画像など、Xcodeでプレビューできない形式に対して、Pillowというライブラリを使用して画像変換を行いプレビュー表示を実現することができます。

さらに、ローカルhttpサーバーを利用してブラウザでの画像表示を行い、ほぼリアルタイムのプレビュー機能を実現する方法もご紹介します。

これらの知見が、デバッグ作業の効率を向上させる手助けとなれば幸いです。