トーク

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も共有します。

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

@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の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を追加する

「ふつうのアプリ」とは何でしょうか。
ソーシャルネットワークMastodonのアプリを作る過程で、この問いと深く向き合うことになりました。

Mastodonは少し特殊なSNSです。サーバーの概念や公開範囲の複雑さ、サーバーごとの固有機能など、それらの仕様は直感的なものではありません。
実際にアプリをリリースしてみると、ユーザーが求めていたのはMastodonの機能を完璧に扱えるアプリなのではなく、直感的に使える「ふつう」のSNSアプリなのでした。
TwitterやInstagramのような既存のSNSで慣れ親しんだUIパターンを期待していたのです。

ここから学んだのは「ふつう」を実現することの難しさです。開発者にとって当たり前の操作でも、一般ユーザーにとっては全く理解できない可能性があります。
開発者やデザイナーは独創的なUIを作りたがりますが、ユーザーは慣れ親しんだパターンを求めています。重要なのは、新しい概念を既存のメンタルモデルに合わせることです。
これらは、もちろんMastodonのアプリに限った話ではありません。

このトークでは、アプリのUIデザインを考察した上で発見した「ふつう」の見つけ方、既存UIパターンの評価方法、そしてそれらを妥協せずに実装するための実践的なテクニックを紹介します。

本文の提案:

アプリ開発で、バックエンドAPIの準備が整っていないために、モックサーバ構築に多くの時間を費やした経験はありませんか。
本セッションでは、iPhoneを活用して軽量なHTTPサーバを動作させ、開発中のアプリが必要とするAPIを迅速に提供する手法を紹介します。
この手法は、複数クライアントを捌く本格的なサーバではなく、1対1で開発中のアプリとペアリングするシンプルな構成であり、手軽に導入できる点が特徴です。

従来のモックサーバ構築では、APIスキーマの定義、レスポンスデータの準備、サーバ環境の構築など、多くの工程が必要でした。
しかし、iPhoneサーバアプリを使用することで、これらの課題を効率的に解決できます。

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

• iPhone上での軽量HTTPサーバの実装方法
• モックAPIの効率的な構築方法
• 実装デモの紹介

対象者:

• iOSアプリ開発者（初級〜中級）
• バックエンド開発を待つことなく効率的に開発したいエンジニア
• モックサーバ構築の手間を省きたいチーム

モバイルアプリ開発において、データの同期や共有が必要な要件に直面したとき、皆さんはどのようなデータ管理サービスを選択しますか？
おそらく次のような意見をよく耳にするでしょう。

「FirebaseのRealtime Databaseがベター！データ同期も簡単だし、他サービスとの連携も楽々！」
「柔軟性を考えるなら、サーバーもデータベースも自前で構築すべき」
「とにかくUserDefaultsに無理やりぶち込んでしまえ！（いや、流石にそれは厳しい……）」

私自身もこうした選択肢で悩む一人でしたが、最近になって「Supabase」というBaaS（Backend as a Service）を知りました。
Supabaseは、Firebaseと異なりオープンソースであるため、カスタマイズ性や拡張性が非常に高いです。またSQLベースでデータの複雑な処理が可能なことや、料金体系が明瞭でコストの予測がしやすいという魅力もあります。

そこで本セッションでは、Supabaseを活用して実際に簡単なアプリを作成しながら、その使いやすさや特徴を皆さんと共有します。
Supabaseを使ってみることで、皆さんの個人開発ライフに新しい選択肢を加えてみませんか？
一緒にSupabaseの世界へ一歩踏み出しましょう！

SwiftUIが利用可能となって6年が経過し、今では500個以上のAPIが存在します。iOS 13でのリリース以降、毎年開催されるWWDCで新しいAPIが追加され続けています。それにも関わらず、私はiOS 13からiOS 15で利用可能となった基本的なAPIに留まり、新機能への追従ができていませんでした。

この現状を打破するため、「SwiftUI未使用API100本ノック」と称し、自分が使ったことがないAPIをひたすら学習・検証する活動を行いました。それにより、従来の複雑な実装がより簡潔に、そしてレンダリングに優しい書き方に変えられることを学びました。本トークでは、100本ノックで発見した便利なAPIを実際のコードに適用した事例を紹介します。GeometryReaderの代わりに containerRelativeFrame(_:alignment:) を使う方法や、 onGeometryChange(for:of:action:) による効率的な値の監視など、実践的な改善パターンをお見せします。

このトークのゴールは、より効率的でメンテナンスしやすいSwiftUIコードを書くための具体的な方法を学んで持って帰っていただき、日々の開発に役立てていただくことです。

対象聴衆は以下の方です。

• iOS 16からiOS 18までのSwiftUIのAPIを使いこなせていないと感じている方
• 既存のプロジェクトでコード改善を考えている方
• SwiftUIコードの可読性向上を目指している方
• GeometryReaderを多用している方

Apple Vision Proが登場し、私達はついに空間コンピューティングへのチケットを手にしました。
3次元の形状を、ディスプレイに投影された平面的なものではなく空間的に体感できるようになったのです。

RealityKitのMeshResourceでは、直方体(Box)、平面(Plane)、球(Sphere)、円錐(Cone)、円柱(Cylinder)、そして文字(Text)といった基本的な形状を簡単に作成できます。
また、Reality Composer Proではカプセル(Capsule)も配置できます。

しかし、これら以外の3次元形状を作成したい場合、どのようにすれば良いのでしょう？
もちろんメッシュの頂点を指定すれば好きな形状が作成できますが、大量の頂点をコード上で逐一指定するのはあまり現実的な方法ではありません。

そこで、パラメトリック曲面と呼ばれる概念を取り入れます。
この手法はすべての頂点を指定する変わりに、2次元のパラメータを指定することで曲面上の座標を表現し、メッシュの頂点を計算させる方法です。

例えば代表的なものとして、多くのベクターイメージ編集ソフトなどでお馴染みの「ベジエ曲線」を拡張した「ベジエ曲面」があります。
これはベジエ曲線と同様に、制御点を動かすことで曲面の形状を直感的に定義することが可能です。

本セッションでは一般的なパラメトリック曲面の解説とベジエ曲面の解説を行い、曲面を直感的に変更できるところをお見せします。
また、ベジエ曲面の性質や限界、実装上の注意点などについてお話します。

学習管理アプリStudyplusでは、「スマホを隔離して集中して勉強したいけど、勉強の記録もしたい」というユーザーの声が多数寄せられていました。これらの声に対してStudyplusでは、FlutterアプリとApple Watchを連携して、Apple Watchでも記録がつけられるようにすることでユーザーの要望に応えることができました。
この対応にはFlutter、iOS、Apple Watchの3つの環境をまたいだ実装が必要となり、それぞれの連携方法を理解することが重要になります。
本セッションでは、Studyplusでの実際の対応事例をもとに、設計から実装、そして得られた価値まで包括的に解説します。

具体的な内容

• ユーザーの要望の分析や提供したい価値の決定
• どの機能をApple Watchに切り出すかの仕様決定
• Flutter・iOS・watchOS間の実装設計と技術選択
  • WCSessionを使ったiOS・watchOS間のデータ通信・監視
  • Method Channel、Pigeonパッケージを使ったクロスプラットフォーム連携
  • Apple Watchの制約を考慮したUI/UX設計
• 対応によってユーザーに提供できた価値

Apple Watch対応を通じて実際のサービス開発で得られた知見を余すことなく共有し、すぐに活用できる実践的な内容をお届けします。

対象者

• Apple Watch対応を検討中のアプリ開発者
• iOS・watchOSアプリ開発者
• クロスプラットフォーム開発でのネイティブ実装を学びたい開発者

visionOSの登場により、従来のARKitでは難しかった高精度で安定した空間アンカリングが実現可能になりました。インテリア配置アプリ、教育・トレーニング、設計支援など、様々な分野でデジタルオブジェクトを物理空間に正確に配置し続ける需要が高まっており、「一度配置したらずっとそこにある」という体験の重要性が注目されています。
この体験を実現する技術がvisionOSのWorldAnchorです。WorldAnchorを活用することで、ユーザーが一度配置したオブジェクトを物理空間に「永続化」し、まるで現実世界に存在するかのような「ずっとそこにある」体験を実現できます。

本セッションでは、実際に開発したデモアプリの事例をもとに、WorldAnchorの実装から期待されるユースケースまで、実践的な観点で解説します。WorldAnchorの活用方法を知りたい開発者の参考になるような内容を目指します。

具体的な内容

• WorldAnchorとは何か？
• 基本的な実装方法（作成・保存・復元の流れ）
• 実際のデモアプリで見る「永続化」の体験
• 今後期待される新しいユースケースの展望

このセッションを通じて、WorldAnchorの可能性を理解し、「物理世界とデジタル世界が融合した新しい体験」を自分のアプリで実現するための具体的なイメージを持っていただけます。

対象者

• visionOS開発に興味があるiOS開発者
• Spatial Computingの具体的な活用方法を知りたい方

2023年にApple Vision ProとともにvisionOSが登場し、iOSエンジニアにとって空間コンピューティングという3Dコンテンツを交えた開発がより身近なものになりました。

SwiftUIやRealityKitといった馴染みのある技術を活用できる一方で、3Dモデリングに関する用語や概念に戸惑いを覚える方も多いのではないでしょうか。

中でも「マテリアル」は、オブジェクトの見た目や質感を左右する重要な要素でありながら、iOSアプリ開発ではあまり馴染みのない概念です。

RealityKitには用途に応じた多様なマテリアルが存在し、それぞれに特性があります。しかし、「どれを選べばよいかわからない」「そもそも何が違うのか」と感じる場面も少なくありません。

本セッションは、RealityKitのマテリアルを網羅的に解説し、どのユースケースでどのようなものが用いることができるかの全体像を把握できるものとなっています。

以下のような観点から解説を行います。

• マテリアルとは？ ：
  光沢、粗さ、透明度など「色」だけでは語れない見た目の要素を分解して解説。
• RealityKitで使える全マテリアルAPIの解説と実例：
  SimpleMaterialでの基本表現、PhysicallyBasedMaterialによるリアルな質感、VideoMaterialでの動画埋め込みなど、現在RealityKitで提供されているAPI全ての特徴とユースケースを紹介。

本セッションを通じて、visionOSで利用可能なRealityKitのマテリアル全体をユースケースと合わせて理解し、空間コンピューティングならではの新しい体験づくりのヒントを得ていただければ幸いです。

UIテスト時にUI要素を特定するための識別子であるAccessibility Identifierですが、SwiftUIのViewにAccessibility Identifierを指定するには各Viewに accessibilityIdentifier Modifierを適用する必要があり、テストケースの増加に伴いModifierの適用が面倒になってくるという課題があります。

Swift 6.0から「SE-0415: Function Body Macros」という、既存の関数の中身を書き換えることができるSwiftマクロが導入されました。本トークでは、Function Body Macrosを使ってSwiftUIのViewにaccessibilityIdentifier Modifierを自動で付与する方法と、実装時に遭遇した落とし穴とその回避策についてご紹介します。

Accessibility Identifierを自動付与することで、accessibilityIdentifier Modifierを各Viewに適用する煩わしさから解放されましょう！

話すこと:

• Function Body Macrosの概要
• Accessibility IdentifierをSwiftUIのViewに自動付与するFunction Body Macrosの実装方法
• マクロ実装時に遭遇した落とし穴とその回避策
• 作成したマクロをアプリ側に導入し、UIテストで自動付与されたAccessibility Identifierを使う