プロポーザル

visionOSやAndroid XRなど、私たち開発者にも「空間をどう見せるか」が問われる時代がやってきました。
このセッションでは、オープンソースの3D編集ツール「Blender」を使って、開発者が知っておくと便利な次の5つを紹介します。

• 3Dオブジェクトの作成
• アニメーション
• ノーマルマップとマテリアル
• プラットフォーム毎の書き出しと互換性
• バージョン管理

特に、ノーマルマップやマテリアル設定による軽量かつリッチな表現手法、glTF/USDZ形式での出力ポイント、そしてBlender Git Addonを用いたバージョン管理術など、「触ってみたいけどとっつきにくい…」と感じている方にこそ届けたい実践的な知見をお届けします。

visionOSやAndroid XRの登場により、私たちアプリ開発者にも「空間をデザインする力」が求められる時代になりました。
そこで注目したいのが、オープンソースの3D編集ツール「Blender」です。

このLTでは、開発者が知っておきたいBlender活用術を紹介します。

• モデルの質感を軽量にリアル化するノーマルマップ
• glTF/USDZ形式での書き出しを見据えたマテリアル設定
• バージョン管理

「ちょっと触ってみようかな」と思えるきっかけを5分でお届けします！

SwiftUIでUIを実現したいが表現力が足りない。そんなときに便利なのがUIViewRepresentableやUIViewControllerRepresentableです。
しかし、そのRepresentableシリーズの使い方はちゃんとマスターしているでしょうか？
Representableシリーズには、Appleのドキュメントを読むだけではわからない、いくつかの『罠』が存在します。なんなら、AppleのサンプルコードですらハマっているCoordinatorのアンチパターンまで存在するのです。
このセッションでは、そうしたドキュメントを読むだけではわからないアンチパターンに焦点を当て、堅牢なコンポーネントを作るための指針をお教えします。

Swiftでは、Arrayに対してfilterやmapをつなげた宣言的な記述をよく使いますが、「この書き方で実行速度は大丈夫？」と感じたことはないでしょうか？

このLTでは、users.filter { $0.isActive }.map { $0.name } のような典型的な記述を対象に、filterやmapをつなげた場合の処理速度を、書き方の違いによって比較検証した結果を交えて紹介します。

ちょっとした記述の違いやlazyの有無によって意外な差が生まれ、期待通りに高速化されないケースもありました。
実際のコード例や計測結果を交えながら、宣言的コードとパフォーマンスのバランスをどう考えるかについてお話しします。

「lazyは速いと思ってたのに…」そんな小さな驚きと発見をお届けします。

Swift 6の足音が聞こえる今、私たちのコードは大きな変化に直面します。特にConcurrencyチェックは「警告」から「エラー」へとその厳格さを増し、私たち開発者にはより正確なコードが求められるようになります。この変化に備え、私たちが日頃から頼りがちな@MainActorの使い方、一度本気で見直しませんか？

「UIに関わるかもしれないし、とりあえずクラス全体に付けておけば安全だろう…」

その、善意からくる@MainActorが、実はUIのカクつきやパフォーマンス低下を招く「静かなる技術的負債」になっているかもしれません。ネットワーク通信やJSON解析といった、本来バックグラウンドでやるべき重い処理までメインスレッドを占有してしまうアンチパターンは、今こそ断ち切るべきです。

このトークでは、そんな「@MainActorの汚部屋」状態を具体的なコードで示し、どこに付け、そしてどこに付けてはいけないのかを明確に切り分けます。パフォーマンスとコードの見通しの良さを両立させるための、明日からすぐに実践できる「@MainActor大掃除テクニック」を、5分という短い時間に凝縮してお届けします。

合言葉は「@MainActorは、UIスレッドへの最後の出口だけ」。

このトークを聴き終えた時、あなたはきっとご自身のコードから不要な@MainActorを一掃し、気持ちよくSwift 6を迎え入れる準備を始めたくなるはずです。

再帰って便利ですよね。関数の最後に再帰呼び出しを置く「末尾再帰」なら、スタックも節約されて、ループと同じくらい効率的に動く。

そんなふうに信じていた時期が、私にもありました。

「末尾再帰なら安心！」と信じて書いたSwiftのコード。動作確認もOK、見た目もスッキリ、ところがある日、ちょっと大きな値を渡しただけでStack Overflowで爆死！
何が起きたのか? 調べてみると、Swiftは末尾再帰の最適化（TCO）を保証していないらしいです！
しかも、見た目的には末尾再帰に見えるのに、ちょっとした演算の影響で最適化されないことも。

このLTでは、そんな「Swiftの末尾再帰、信じすぎ注意！」という話を、実際に書いて動かして試してみた結果とあわせて紹介します。

なぜStack Overflowが起きたのか?
末尾再帰が最適化される場合とされない場合の差は?
今は大丈夫なコードでも、未来永劫ずっと安全?

楽しく聞いて、明日から「ちょっと再帰が心配になる」。
そんな5分をお届けします。

SwiftUIが主流の昨今ですが、UIKitベースのレガシーコードと向き合っている方もまだまだいるのではないでしょうか。長い歴史を持つコードベースでは、複雑に絡み合った責務、肥大化したメソッド、長大なViewControllerなど様々な問題のあるコードに直面することがあります。このようなコードに出会った時、アーキテクチャの刷新や技術スタックの移行も重要ですが、まずは「読めるコード」にすることから始めるアプローチがあります。

「読めるコード」にするためには、ファイルの行数を減らし、関連する処理をまとめ、重複や不要なコードを削除するといった地道な改善が必要です。
このトークでは、実際のプロダクトコードで行った2つのViewControllerのリファクタリング事例を通じて、このような地道な改善を、比較的安全に段階的に実施していく方法を共有します。

また、「読めるコード」への改善は、AIを利用した開発においても重要な意味を持ちます。人間にとって読みやすいコードであることにより、AIもまたコードを理解し、適切な提案をすることができます。コンテキストウインドウの浪費も抑える事ができます。AIの恩恵を最大限に活かすためのリファクタリングについても考察します。

話すこと

• 「読めるコード」への段階的な改善手法
• 実際のプロダクトコードでの事例紹介
• コードの可読性がもたらすAIを利用した開発への効果

話さないこと

• 特定のアーキテクチャパターンへの移行
• UIKitからSwiftUIへの移行手法
• 理想論や銀の弾丸的な解決策

とある開発期間1年・iOSメンバー5人の長期アプリ開発プロジェクトにおいて、QAでの不具合発生率を普段の半分以下の2%に抑えることに成功しました。
この要因の1つはメンバー全員が「小さなPull Request」を作り続けてきた事です。
「小さなPR」は品質向上と開発効率に大きく貢献するのです。
「PRは小さければ小さいほどレビュワーに優しく、早くマージされ、バグ発見率も向上する」という原則を深掘りします。

多くの開発者が「差分行数」でPRの粒度を判断しがちですが、本当に重要なのは「関心事の少なさ」です。
ユニットテストやXibの差分でPRが膨らんでもレビューが苦にならないのは、関心事が少ないためです。

本セッションでは、具体的な画面実装の例を挙げ、API層、UIコンポーネント、通信処理など、関心事ごとにPRを分割する具体的な戦略を詳細に解説します。
このセッションを通じて、チーム全体の生産性とプロダクト品質を向上させるヒントを持ち帰っていただければ幸いです。

とある開発期間1年・iOSメンバー5人の長期アプリ開発プロジェクトにおいて、QAでの不具合発生率を普段の半分以下の2%に抑えることに成功しました。
この要因の1つはメンバー全員が「小さなPull Request」を作り続けてきた事です。
「小さなPR」は品質向上と開発効率に大きく貢献するのです。
「PRは小さければ小さいほどレビュワーに優しく、早くマージされ、バグ発見率も向上する」という原則を深掘りします。

多くの開発者が「差分行数」でPRの粒度を判断しがちですが、本当に重要なのは「関心事の少なさ」です。
ユニットテストやXibの差分でPRが膨らんでもレビューが苦にならないのは、関心事が少ないためです。

本セッションでは、具体的な画面実装の例を挙げ、API層、UIコンポーネント、通信処理など、関心事ごとにPRを分割する具体的な戦略を詳細に解説します。
また、「小さなPR」を実践すると先行PR・後続PRが連なっていきます。それぞれのPR同士の文脈を繋げる実践的なTipsも紹介します。

このセッションを通じて、チーム全体の生産性とプロダクト品質を向上させるヒントを持ち帰っていただければ幸いです。

2025年秋にリリース予定の「macOS Tahoe 26」が、Intel製CPUを搭載したMacへ提供される最後のOSであることをAppleが発表しました。CPUアーキテクチャの異なるApple Siliconへの移行という偉業を成し遂げたApple。その技術的背景を、いま一度振り返ってみる価値があるのではないでしょうか。

本トークでは、Appleが歩んできたCPUアーキテクチャの変遷を振り返りつつ、x86からArm（Apple Silicon）へと至る道のりを解説します。そして、実際にApple Silicon搭載Mac上で動作するアセンブリコード（計算と文字出力）を題材に、命令セット・システムコール・レジスタといった低レイヤの要素をやさしく紹介します。

アセンブリは一見アプリ開発に無縁に思えるかもしれませんが、実はクラッシュログ解析やパフォーマンス調整、Rosetta 2の仕組み理解など、日常の開発と意外なところでつながっています。iOSエンジニアが“いまこそ”学び直す意義のある低レイヤ世界を、一緒に覗いてみませんか？

AIコーディングがiOS開発でも注目される中、visionOSの空間アプリ開発にもClaude Codeを使って挑戦してみました。

SwiftUI × RealityKitでの開発は一筋縄ではいかず、空間体験の構築には想像以上の試行錯誤が必要でした。

コーディングだけでなく、3Dモデルは生成AIやBlender MCP、Skyboxは画像生成AI、効果音は音声生成AIに任せ、アセット面でもAIをフル活用。

さまざまな壁にぶつかりながらも、AIと二人三脚で空間アプリを形にしていく中で得た知見をお伝えします。

MVVM、それはSwiftの誕生前から、人気のアーキテクチャの一つ。そしてSwiftUIが登場して6年経った今もなお、その人気っぷりがなかなか衰えを見せません。

ところが、あなたは本当にMVVM、もっと言えばViewModelのことを分かった上で使っていますか？
「みんなが使っているから、私も使おう」
「画面のテストが書けるから、私もViewModel入れよう」
「プレゼン層とドメイン層を繋げるために、ViewModelが必要」
そんな単純な思いで、MVVM使っていませんか？

はっきり言いましょう、そんなあなたは、別にViewModel、もっと言えばMVVMなんて本当は必要としていないです。むしろある意味、SwiftUIとMVVMは、相性が非常に悪い組み合わせだと断言します。

このトークは、ある程度SwiftUIでの開発が慣れているエンジニアをターゲットとし、以下の内容を含める予定です：

• なぜあなたが必要なのはViewModelではないと私が言うのか
• なぜSwiftUIはMVVMと相性が悪いのか
• ViewModelを無くしたら、どのようにしてViewの処理を保証すればいいのか
• MVVM使わないなら、どんなアーキテクチャがいいのか

このトークを聞いて、ぜひ一度SwiftUIの原点に立ち戻って、SwiftUIに適したアーキテクチャを再考してみませんか？

UIKit ベースで長年開発されてきたアプリを、SwiftUI + Observation を取り入れながら段階的にリアーキテクチャしている最中の現場から、移行と共存のリアルな取り組みをご紹介します。

なぜリアーキテクチャに取り組むのか、どのようにアーキテクチャを考えていったのか、結果どのようなアーキテクチャになったのか、、

そして、実際にプロダクトに実装して見えた改善点など、理想と現実のギャップに向き合い改善を進めている、リアルな“今”のストーリーをお届けします。
「SwiftUI に切り替えたいが、現実的にどう始めればいいかわからない」「SwiftUI を取り入れたが、既存アーキテクチャと相性が悪そう」「Observation を使った実践例が知りたい」といった悩みを持つ開発者にとって、同じ課題に直面した私たちのプロセスはきっと参考になるはずです。

2017年に発売されたiPhone 7以降、iPhoneにはNFCリーダー/ライターが搭載されるようになり、NFCは私たちの生活にとってより身近な技術になりました。
AppleからもCore NFCフレームワークが公開され、我々開発者はNFCタグの仕様を深く知らずとも、アプリを簡単に開発できます。

弊社でもNFCタグを用いたプロダクトの開発が進められており、
ある日私は「パスワードで保護されたNFCタグを使った新機能」を開発することになりました。
しかし、その技術検証の過程で、NFCタグの仕様を深く理解していなかった私はさまざまな壁にぶつかります。

「パスワード認証ってどうやるんだろう？それっぽい専用のAPIは見当たらないけど...」
「どうにかパスワード認証できたぞ！あれ、データ読み込みがエラーになるな...」

結局、この壁を乗り越えるために、NFCタグにまつわる幾つかの技術仕様を基礎から学び直すことになりました。

本トークでは、検証の過程で学んだNFCタグの技術仕様の説明を交えつつ、どのようにこの機能を実現したのかをお話しします。
Core NFCが普段どのような処理をラップしてくれているのか、その裏側をちょっと覗いてみませんか？

話すこと

• NFCタグ(NTAG215)にまつわる技術仕様
  • NDEF Message/Record
  • NFCタグのデータ構造
  • MiFareコマンド
  • TLV形式
• パスワードで保護されたNFCタグからデータを読み取る方法
  • sendMiFareCommandを用いたパスワード認証・データ読み取り
  • 読み取ったデータのNFCNDEFMessageへのパース

Swiftが大好きなあなたに語りかけています…
SwiftUIのようなシンタックスでウェブサイトを構築できたら、最高だと思いませんか？
さらに、iOSなどのネイティブアプリとロジックやリソースをシームレスに共有できたら、ウェブサイト開発に対するイメージが180度変わるはずです。

そんな理想を実現するのが、Swift製の静的サイトジェネレータ“Ignite”です。
このセッションでは、Igniteを使ったウェブサイト開発を題材に、Result BuildersやString Catalogs、XCAssetsの扱い方を通じて、Swiftの言語仕様やXcodeの仕組みに踏み込みます。再利用可能な設計と実装のコツを、豊富な実例とともに紹介します。

⸻

宣言的UIの正体に迫る

SwiftUIやIgniteで使われている「宣言的UI」についてResult Buildersの仕組みから紹介します。
これによって、Igniteがサポートしていないコンポーネントの追加はもちろん、SwiftUIでの柔軟なカスタムコンポーネント設計にも応用できるスキルが身につきます。

String Catalogsを読み解く

ウェブサイトをローカライズする過程で得た、String Catalogsの内部仕様やビルド後の挙動に迫ります。
GUIに隠れた“裏の挙動”を知ることで、アプリでの予期せぬ不具合にも迅速に対応できるスキルが身につきます。

アプリとのロジック＆リソース共有

ネイティブアプリで使っているコードやアセット（XCAssetsやローカライズ文字列）をウェブサイトでも再利用する方法を紹介します。
SwiftPMをまたいでBundleを扱うテクニックや、LinuxとmacOSビルドの差異など、マルチモジュール設計に役立つ実践的なTipsも共有します。

比較的高額な決済機能を有する金融サービスでは、犯罪収益移転防止法に基づく本人確認の実施が義務付けられています。

私たちが提供する『AI家計簿アプリ ワンバンク』では、 "eKYC" と呼ばれるオンライン形式での本人確認フローを自前で構築し、サービスの成長を支えてきました。その運用の過程ではユーザー体験や堅牢性の向上、ガイドラインへのさらなる準拠などさまざまな改善を積み重ねてきました。

また、近年は不正利用も深刻化する中で従来の書類と顔写真の撮影を伴う本人確認方式は廃止の流れにあります。ICチップの読み取りによる信頼度の高い方式への移行が求められ、私たちのサービスでも対応を進めてきました。

このトークでは、私たちがこれまで本人確認フローに積み重ねた改善にフォーカスし、さまざまな観点での工夫やTipsを紹介していきます。そして、JPKI方式（公的個人認証サービスを利用したマイナンバーカードによる本人確認）への対応など、環境の変化へ追従するための直近の取り組みにも触れていきます。

【内容（予定）】

・自前で構築した本人確認フローの運用の中で積み重ねた改善
・本人確認フローの突破率を最大化するための試行錯誤
・撮影機能が依存するライブラリ（ML Kit -> Vision.framework）の安全な移行に向けた工夫
・従来の本人確認方式の廃止を伴う法令改正に備えたJPKI方式対応などの直近の取り組み

このトークでは、VisionフレームワークのOCR機能とCoreMLのシンプルなテキスト分類モデルを活用し、レシートの自動仕分けに挑戦した事例を紹介します。
画像からテキストを読み取り、正規表現を用いて金額を抽出し、商品名をカテゴリに分類するプロセスについて解説します。
複雑な前処理や高度なモデルを用いず、どれだけシンプルな仕組みで実用化に近づけるかを探求した結果を共有します。
手軽に試せる手法であるため、個人で家計簿や経費精算の自動化アプリを作成したいと考えている方々にとって、有益なヒントとなることを目指しています。

2020年にリリースされたApp Clipは、今年の秋に6年目を迎えることになります。
以前よりは少し知名度が上がったとはいえ、WWDC25では2年連続でセッションがなく、未だに存在の薄さが否めないApp Clip。

「アプリの一部をコンパクトにしたもの」
「完全版のアプリの一部として管理」
このような性質上、決して"主役"にはなれないものの、アプリの体験を裏から補強するそのポテンシャルは、はたしてどれだけの人やビジネスを動かしたのでしょうか。

このトークでは、App Clipが生まれてから今日に至るまでの5年に至る歴史を紹介していきます。
App Clip 自体のアップデートや、国内外での各業界（飲食、小売、交通、ゲーム等）における実用例を振り返りつつ、その進化と残された課題について見ていきます。

App Clipを待つのは夜明けか、それとも日没か。
5年経った今だからこそ見えるその可能性に迫っていきませんか。

@Environment(.keyPath)、それはSwiftUIが提供しているデータフローの仕組みの一つであり、SwiftUIでアプリを組んでいるエンジニアで、これを全く使ったことがない人はいないでしょう。

ところが、あなたは本当に@Environment(.keyPath)を正しく使っているのか？もしくは@Environment(.keyPath)の実力を知ってて使っているのか？@Environment(.keyPath)の思わぬ落とし穴に陥ったことありませんか？

このLTでは、そんな@Environment(.keyPath)にまつわるクイズを集め、ぜひ会場の皆さんに挑戦していただきたいです！そして全問正解の方は、「@Environment(.keyPath)王」の称号を授けましょう（嘘）！

「このAIツールを使えば、チームの開発はもっと効率的になるはず！」

そんな純粋な期待を胸に、新卒エンジニアとしてAIツールの導入に挑戦しました。
しかし、その先に待ち受けていたのは、技術的なメリットだけでは乗り越えられない、ツール選定、予算、社内申請、そして導入効果への説明責任といった、いくつもの「見えていなかった壁」でした。

特に当時のiOS開発においては、メインのIDEであるXcodeにAIが統合されておらず、拡張機能も不安定でした。そのため、他の開発環境と比較して、AIツールのサポートが不足していました。また、VSCodeを普段の開発でメインに使うのもチームメンバーに抵抗なく受け入れてはもらえない状況でした。
さらに多くの企業にも当てはまるように、AIツールの導入に関する予算が限られており、検証のための時間も捻出しづらいのが現実です。

本トークでは、そのような状況の中、新卒エンジニアの私が所属チームにGitHub CopilotやCursorをはじめとする生成AIツールを導入する過程で経験した、リアルな失敗談を共有します。
そして、その経験から得た「ツール選定前にチームの課題を明確にすることの重要性」や「導入効果を具体的に示すためのアプローチ」といった、新卒エンジニアが失敗を通して改めて伝えたい教訓についてお話します。