トーク

最近、一部の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”時代に備えるための視点を提供します。

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

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アプリの開発・運用方法について紹介します。

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

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

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

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

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

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

XcodeCloudを快適に利用できていますでしょうか？

AppleはWWDC21にてCICDツールである "XcodeCloud" を発表しました。2021年登場から4年が経過し、他のCIツールに比べてコスト面の圧倒的優位性や導入の容易さ、署名周りの運用コストの低さなどから利用されることが多くなっています。
しかし、XcodeCloudは「マシンスペックの選択」ができないため、利用対象のアプリが巨大だとしても、より高価なマシンを選択することができず、1回の実行時間が普段の開発で利用するには耐えられないほど（40分〜）長くなってしまう問題があります。

本セッションでは、XcodeCloudを利用されている方や別のCIツールを利用している方を対象に、最小限の対応で現実的な実行時間（〜20分）に抑えるための改善についてお話します。具体的には最新のビルド改善方法やワークフローの最適化設定、差分テスト実行、パッケージ取得の効率化などの改善についてご紹介します。

以下の内容について紹介します。
・XcodeCloudの概要（実行環境、ワークフロー構築）
・XcodeCloudの改善 - 設定変更
・XcodeCloudの改善 - ワークフロー実行改善
・XcodeCloudの改善 - ビルド改善
・XcodeCloudの改善 - 差分テスト実行のための仕組み構築

みなさんSwift Package Managerで依存パッケージをブランチ指定している場合など、意図したバージョンが利用されずに困ったという経験はないでしょうか。

このような問題に直面した際、私たちはその根本原因が分からないまま、手探りでキャッシュを削除したり、Xcodeを再起動したりといった非効率な試行錯誤に多くの時間を費やしてしまいがちです。

特に、ライブラリのバージョンが古いまま残っているかどうかは、その挙動をしばらく観察しないと判明しないこともあり、問題解決までにかかる時間がさらに長引くケースも少なくありません。

本トークでは、Swift Package Managerのキャッシュの仕組みを深掘り、その適切な取り扱い方を理解することで「分からないから手当たり次第に試す」という状況から脱却できるようになることを目指します。

具体的には以下のようなトピックを取り扱います。

• Swift Package Managerがキャッシュしている項目について
• Package.swiftのManifest解釈プロセスについて
• 依存解決のされ方とキャッシュの適切な飛ばし方について

多くのプロジェクトでCIは、テストや静的解析を通じて品質を保証する重要な役割を果たしています。
一方で、CIの待ち時間はプルリクエストをマージするまでの時間に大きな影響を与えています。

「家族アルバム みてね」のiOSアプリでは、各プルリクエストでユニットテストと静的解析を実行していますが、その待ち時間が最大で約50分に達し、開発スピードを阻害する要因になっていました。
特にiOSに関わるメンバーが10人から20人へと倍増したことで、全メンバーがこの待ち時間の影響を受け、ボトルネックとなる場面が頻発していました。
コードレビューによる修正が多くなると影響を受けるのはもちろんのこと、hotfix等の緊急対応が必要な場面で特にもどかしさを感じていました。

これらの課題を解決するために、CIで2つの並列化手法を実践し、待ち時間を約20分まで短縮することに成功しました。

• CIのJobの並列化
  • マルチモジュール化によって得られた並列化の恩恵
  • CIとローカルでのTestPlanの使い分け
• ユニットテストの各テストケースの並列化
  • Swift Testingの活用とXCTestからの移行
  • 並列化で発生したFlaky Testの問題と解決

本セッションでは、導入までのステップ、導入時の課題、得られた効果について詳しくご紹介します。

生成AIの目覚ましい進化により、LLM（大規模言語モデル）を活用した開発が急激な勢いで発展しています。
モバイル領域の開発も例外ではなく、LLMを活用して開発を効率化していくことが求められてきているかと思います。

本セッションでは、LLM活用して iOS/Android 両OS アプリの効率的な開発手法についてお話いたします。
具体的には、以下を深堀ってお話しいたします。

• Cline, Cursor, Claude, Codex, Gemini など複数のAIコーディングアシスタントを活用したアプリ開発
• AI活用したモバイルアプリ開発を効率化するために、「iOS/Android モノレポ化戦略」について
• モノレポ化によって、得ることができた Mobile 開発の効率化
  • iOS ↔ Android 相互にコード変換
  • AIコーディングアシスタントを用いた iOS/Android 同時並列開発について
• 今後、想定しているAI活用戦略

私が所属する大学の研究室では, 音声解析の結果や録音した音声からグラフを作成する機会が多くあります. しかし, 研究室全体で利用している既存の音声編集ソフトウェアのグラフ表示機能には, 「複数の音響データを同一のグラフに重ねて表示できない」, 「データ間の詳細な差分を比較できない」などといった問題があり指導教員がこの点に不満を抱いていました.

そこで普段からiOSアプリの開発をしている私は, AVFoundationで音声ファイルを読み込み, 音声信号が時間とともにどのような周波数成分を持っているかをAccelerate FrameworkのAPIを用いて高速フーリエ変換 (FFT: Fast Fourier Transform)を行うことで解析し, その結果をSwift Chartsを用いてスペクトログラムを描画するようなシンプルなアプリケーションを作成しました.

このアプリを使用することで, 複数の音声ファイルの音声スペクトルを重ね合わせて表示したり, 差分を表示したりすることが可能になり, より直感的な音声特性の分析を実現しました. これにより音響データの比較検討が効率化されたとともに, ゼミの発表資料などで成果の視覚的な説明ができるようになりました.

このトークでは

• AVFoundation, Accelerateを用いた音声ファイルに対しての高速フーリエ変換とスペクトルの解析
• Swift Chartsによるスペクトログラムのカスタマイズや描画
• ドラッグアンドドロップによる音声ファイルの選択とスペクトログラムのクリップボードへの保存

について, 高速フーリエ変換の基礎や作成したアプリケーションの実装に触れつつお話します.

macOS では InputMethodKit を活用することで、自作の日本語入力システムを開発できます。本トークでは、日本語入力機能を備えた Input Method の構築を目標に、
・InputMethodKit の基礎と使い方
・開発をスムーズに進めるコツ
・日本語入力機能を実装する際に役立つライブラリの紹介
を順に解説します。これをお聞きいただければ、誰でもデスクトップ向け日本語入力システムを DIY できるはずです。

私は iOS 向けに開発した日本語入力キーボードアプリ 「azooKey」 を macOS へ移植し、過去 1 年にわたり開発・運用を続けてきました。
GPUを用いた強力な変換機能を作ったり、端末外のAPIにアクセスすることによってLLMなどを活用することも、機能的制限の緩いmacOS環境なら容易に実現可能です。
本トークではこうした自作Input Methodの魅力を紹介します。

一方、macOS特有の制約も様々に存在します。変換候補ウィンドウの表示、容易にいかないデバッグなど、さまざまな難しさがあります。こうした地雷を避けつつ使い勝手の良いInput Methodを開発するための知見も紹介します。

※2023年のiOSDCではiOS向けのキーボードアプリの開発についても話しました。こちらもぜひご覧ください。
https://fortee.jp/iosdc-japan-2023/proposal/87be3428-5381-4aa3-8127-cfd714663429

音声でアプリの入力が完結したらとても便利だと思いませんか？

音声入力の代表格である Siri は2011年に iPhone に登場して以来年々進化を遂げ、「声で操作する」という動作は当たり前のものになりました。
音声入力をアプリに組み込む方法としては Speech framework があり、日本語もサポートされており、音声をそのままテキストに変換ができます。
しかしアプリの入力は、テキストだけではありません。
トグルやピッカーなど、テキスト以外のアプリ入力としては Speech framework 柔軟性に欠けていました。

ところが、WWDC25 で発表されたオンデバイスLLM Foundation Modelsを使うと状況が一変します。
@Generableマクロを使うことでプロンプトから任意のSwift型のデータを出力できるようになったのです。
つまり Speech frameworkで音声入力をしてテキストに変換し、Foundation Modelsのプロンプトとして渡せば、アプリの入力を音声で完結できるようになりました。

このトークではSpeech frameworkとFoundation Modelsでアプリの入力を簡便にする方法を発表します。
Todoアプリを例に実装例やオンデバイスLLMでの効果的な利用方法をお話します。

「目次」
・Foundation Modelsとは？対応機種や制限は？
・Speech frameworkと組み合わせる実装例
・効率の良いプロンプト作成方法
・実際のユーザーの評価とフィードバック

あなたのアプリもキーボード中心の UX を“声だけの入力”へアップグレードしてみませんか？

iOS/iPadOSアプリを作る上で、開発者としての基本姿勢はAppleの標準APIを使ってUIを実現することです。
Appleが用意した高レイヤーのAPIを使うことで、簡単にリッチなUIを実現できます。

しかし、そういったAPIは高レイヤーがゆえに、時には小回りがきかないことも事実です。
そのような場合に、UIViewからフルスクラッチでカスタムUIを作ることが選択肢になります。
Appleが提供するAPIにはない表現を実現することができ、みなさんのアプリの世界観にピッタリなカスタムUIを提供できます。

ただ、カスタムUIを実際に作るとなると、標準APIがカバーしてくれていた多くのことを自前でカバーする必要が出てきますが、そのコストは過小評価されがちです。
アニメーション、ジェスチャー、インタラクション、パフォーマンス、入力デバイス、アクセシビリティ...
開発者はこれら全てに対して、Appleが用意した標準のUIと並んでも違和感がないレベルまで実装し、メンテナンスし続ける「覚悟」が求められます。

このトークでは実際に自分が作ったカスタムUI、作らなかったカスタムUIを題材に、以下の流れで話をします。

• どういう場合にカスタムUIを作るべきか、作らないべきか
• カスタムUIを実装する時、どのような点に注意すればいいのか
• 実装されたカスタムUIに対して何を確認したらいいのか
• カスタムUIを導入する際の覚悟

このトークを通じて、みなさんがiOS/iPadOSアプリ開発者として、適切にカスタムUIと向き合えることを目指します。