トーク

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ツールを導入する過程で経験した、リアルな失敗談を共有します。
そして、その経験から得た「ツール選定前にチームの課題を明確にすることの重要性」や「導入効果を具体的に示すためのアプローチ」といった、新卒エンジニアが失敗を通して改めて伝えたい教訓についてお話します。

iOSアプリにおいて Bluetooth 接続のレシートプリンターで印刷するにあたって、私は各メーカーのSDKに頼らず、 Foundation Framework に含まれる Stream API を使用したアプローチを採用しています。
複数メーカー製プリンターを共通の仕組みでサポートするためのプロトコルを定義し、 OutputStream に印刷データを書き込むことでレシート印刷を実現しました。

この方法は、各メーカーSDKの仕様変更や機能差異に左右されにくいという大きなメリットがあります。
一方で、 Stream API の仕組みや Bluetooth を使用したiOSアプリとレシートプリンター間通信の特徴を正しく理解していないと、私が実際に経験したように「印刷が途中で止まってしまう不具合」に遭遇することもあります。

本トークでは、レシートプリンターとの通信に必要な Stream API の基本知識を整理しつつ、複数メーカー製プリンターを共通の仕組みで制御する方法、そして印刷が途中で止まってしまう不具合の対処法について具体的に紹介します。

トーク内容
・Stream API でバイナリデータを送受信する方法
・レシートプリンターの特徴と Bluetooth 接続方法
・レシート印刷に必要な技術的な構成
・複数メーカー製プリンターをサポートする仕組み
・印刷が途中で止まる不具合と Stream.Event を用いた対処法

本トークは、iOSアプリでレシート印刷をしたことがない方はもちろん、これから実装したいと考えている方にも楽しんでもらえる内容です。
本トークのテーマであるレシート印刷の内容を通してバイナリデータ通信全般に応用できる技術知見をお届けします！

iOSのWidgetは、アプリを開かずに静的な情報を即座に確認できる便利なUIコンポーネントとして発展してきました。

従来は「見る」だけの体験が中心でしたが、iOS 17から導入された Interactive Widget によって、ボタンやトグルを用いた直接操作が可能となり、よりリッチで能動的なユーザー体験が実現しました。同バージョンではアニメーション表現のサポートも追加され、動的かつ魅力的な情報提示が可能に進化しています。さらにWWDC25で発表された WidgetKit Push により、サーバーからのプッシュ通知を活用したリアルタイム更新が可能となり、ユーザーに最新情報を即座に届けられるようになりました。

このトークでは、これら最新技術を活用したWidget開発の実践的なアプローチと設計上の要点を技術的視点で深掘りします。

デザイナーからFigmaファイルを受け取って実装する際、コンポーネントの細かい値を確認したり、デザインシステムとの整合性を保つのに時間がかかることがよくあります。

Figmaから公式にリリースされたDev Mode MCPサーバーを使うことで、CursorやClaude CodeからFigmaのデザイン情報を直接取得し、SwiftUIコードの生成を効率化できるようになりました。
公式MCPサーバーならではの正確なメタデータ取得により、より信頼性の高いコード生成が可能です。
このLTでは、実際にiOSプロジェクトで試した活用例をご紹介します。

フィーチャーフラグは新機能の段階的リリースやA/Bテストを可能にする強力な手段ですが、一方で乱立・肥大化すると管理が複雑化しやすく予期せぬバグやインシデントが発生しやすくなります。

今回、私は株式会社ヤプリが提供するノーコードアプリプラットフォームのiOS基盤に、長期ブランチの滞留やインシデントの復旧遅延を解消するためにフィーチャーフラグを導入しました。

しかし、その導入は容易ではなくノーコードアプリプラットフォームならではの課題に直面しました。

まず、一つのコードベースから多数のアプリをビルドするために、従来のフィーチャーフラグ手法ではアプリごとの条件分岐や設定管理が膨れ上がり現実的な運用が難しくなってしまいます。

次に、1つの不具合が多数のアプリ全体に波及するインシデントへと直結するため、リリースコードに少しでも変更があればQAの実施が必須となっています。

最後に、開発チームでは過去に何度か検討されながら「すでにあるアプリ編集機能で十分では？」という意見も多く、導入意義をチームで合意する必要がありました。

このような課題に対して、私は丁寧に「フィーチャーフラグ」についてチームのコンセンサスをとりながら、安全に導入するためにSwift MacrosとBuild tool pluginを用いた仕組みを設計しました。

1. 宣言的なフラグ定義により全体のフラグ状態を静的に把握
2. Swift MacrosとユニットテストでQA工数を抑制しながら「動かないコード」を撲滅
3. コード自動生成で対象外フラグをビルド時に無効化する仕組みを構築

例えば、この設計でコード内で個別アプリごとの条件分岐が不要になっています。

このトークではこれらのアーキテクチャとワークフローを具体的なコードとともに紹介しながら、導入に伴う成功と失敗の両面から皆さんに共有します。

Apple Vision Pro 向けのコンテンツ開発は、大きく分けて2つのアプローチがあります。1つは Apple 標準の Xcode を使って Swift で開発する方法、もう1つはゲームエンジンを使用する方法です。特にゲームエンジンには Unity、Unreal Engine、Godot Engine などの選択肢があります。

iOSDC Japan の参加者の多くは Xcode で Swift を用いた開発に精通していると思われますが、Apple Vision Pro の登場以前から、XR 領域でのコンテンツ開発にはゲームエンジン、特に Unity が多く用いられてきました。Apple はこの Unity と連携し、「PolySpatial」という Unity 用のソリューションを提供しています。これは、Apple Vision Pro 向けのコンテンツ開発を支援するものです。

このトークでは、Unity の PolySpatial を用いて Apple Vision Pro アプリを実際に開発している数名の開発者と一緒に、Unity を使用した Apple Vision Pro 向けアプリ開発の現実と課題について、Xcode で Swift を用いる方法と比較しながら、一問一答形式でお届けします。具体的には、PolySpatial の基本的な概要から、その利点と欠点について詳しく掘り下げます。

日々の開発の中で「この処理をBuild時やCIで実行しておきたい」と思い、自作コマンドを作ってる人は少なくないと思います。

しかしながら、自作のツールをチームに共有する手法が確立していないという問題があります。
毎回メンバーにビルドしてもらうのは避けたいですし、バイナリを配布するのはhomebrewのtapを作ったりする必要があったりとなかなか面倒でした。

SwiftではartifactbundleとCommandPluginを活用することでサードパーティのツールに頼らず、ビルド済みのバイナリを配布し実行することができます。

このトークではSwiftツールチェインだけでSwift製バイナリを配布・実行する方法について紹介します。

• Swiftで自作コマンドを作成する
  • SwiftにSLコマンド移植してみた
• artifactbundleとして配布する
• artifactbundleをCommandPluginにする
• CommandPluginを使う
  • ダミーSwiftPackageにCommandPluginを追加する