トーク

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

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

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

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

メソッドの命名は、処理の内容を語るものでなければならない──それは世の中に広く浸透し、誰もが当然のように従ってきた原則だった。
実際その教えは、長い間開発の秩序を保ち、プロジェクトの明瞭な設計へと導いてきた。

だがある時、この教えに一つの問いを投げかける者がいた。「ViewModelは、他の層と同じ命名規則では語りきれない存在ではないか。」と。
それは異端とされた。責務をわかりづらくし、統一性をなくし、抽象的で、実装を曖昧にするものだとされた。
それでも、複雑なUIと入り組んだ状態遷移の中で、その考え方は静かに、しかし確かに広がっていった。

これは、かつて正統派とされた命名に意を唱え、新たな視点を持ち込もうとした者たちの物語である。

本発表では、ViewModelの「UIとロジックの境界である」「Viewの抽象化である」という特性を踏まえ、そのメソッドの最適な命名について探っていきます。
また、一般的にメソッド名において是とされる「saveProfile」「fetchItems」のような処理内容中心の命名と比較し、UIイベントに即した「onSaveTapped」「onRetryRequested」といったイベント中心の命名が、どのような設計上の価値をもたらすかを検討します。

命名という小さな選択が、設計にどのような影響を与えるのか。
5分間で一緒に考えてみませんか？

多くのユーザーはアプリを使用する際に「直感的に操作できること」を期待しています。１ユーザーとしてさまざまなアプリを触っていると、「こう思っていたのになんでこうなるんだ？」という違和感を覚えることがあると思います。
おそらくその違和感はアプリの設計の段階で、UI/UXの考慮が抜けてしまっていることが原因で生じているものだと考えられます。
もちろん、技術的な制約や実装上の理由から、理想的なUI/UXを実現するのが難しい場合もあります。
ですが、ユーザーは自分の期待通りにアプリが動作することを期待しています。想定と違うとユーザーは困惑してしまい、求めていた情報に辿りつかなかったり、嫌悪感を抱いて離脱してしまう、そんなことにつながってしまう可能性もあります。
たった一つのボタンの動きやアニメーションだけでせっかくのUIも台無しになる可能性さえあります。

こうした背景から、どのようなUI/UXの抜けがあってユーザーに違和感があるのか、それをどうしたら改善できるのかを考えたいと思いました。

このトークでは、どのようなUI/UXの欠落がユーザーに違和感を与えるのかを具体的に分析し、それをどのように改善できるのかを考察します。具体的には、以下のポイントを中心にお話しする予定です。

・失敗例（実例ではなくサンプルをお示しします）
・失敗をどのように改善できるかについての提案

つまりのところ言いたいこと：UIがいいだけじゃダメですか？→ダメです

概要:
「Apple Walletって何ができるの？」「どんな工程でカードが追加されるの？」「自分のアプリに使えるかな？」
そんな疑問を5分で一気に解決してみせましょう！
このLTでは、PassKitの全体像を爆速でキャッチアップできるよう、要点を絞ってお話しします！

やること:

• Apple Walletへのカード追加フロー解説
• こんなこと、できるんだよ！の紹介

やらないこと:

• 実装の詳細説明（時間の都合上、概要のみ）
• WWDC 25のNDA対象内容

こんな方におすすめ

Apple Wallet未経験で「何ができるか知りたい」方
導入検討中で「うちのアプリに合うか」判断したい方
キャッチアップ時間を短縮したい忙しい開発者

5分後、あなたはPassKitを「知らない技術」から「できるきがするぞぉぉぉぉぉおおお！」に変えられます！
キャッチアップ時間の激減を体感してください！
PassKitの可能性にワクワクしましょう！

Swift File数1700超のSansan iOSアプリでは、コーディングスタイルの乱れが開発効率を阻害する大きな要因となっていました。
この課題を解決するために、Sansanではフォーマッターによる数万行単位の大規模なフォーマットを不具合を発生させることなく完了し、今も一貫したスタイルが守られ続けています。
この取り組みから得られた、デグレのリスクを抑えて安全にフォーマットを進める方法を共有します。

トーク内容
1: スタイルの乱れが生産性に与える影響や統一することによる具体的な生産性向上効果の説明
2: フォーマットによって処理が変わってしまう具体的な事例や危険性の紹介
3: 数万行の差分をデグレリスクを抑えて安全に取り込むための戦略的アプローチ

対象となる方
・ チームの生産性向上に取り組んでいる中堅・リードエンジニアの方
・ コードフォーマットツールの導入を検討している方

iOS 26ではSpeechAnalyzerという革新的な文字起こしAIが登場し、プライバシーを守りながら高精度な音声認識をすることが可能になりました。
この技術は、Appleの音声技術やApple Intelligenceに支えられた強力なライブラリです。

このトークでは、以下の内容に焦点を当てます。
1: SpeechAnalyzerによる文字起こしの仕組みやアーキテクチャについての簡単な説明

• SpeechAnalyzer, SpeechTranscriber, AssetInventoryなどの構成技術と、音声データがテキストに変換される流れを解説します。
  2: iOS 10以降で使用可能だったSFSpeechRecognizerと比較を通じて、どれほど性能が向上したかを解説
• 音声認識の精度や処理速度だけでなく、長い音声データや距離のある音源への対応、オンデバイスでの動作など、できることの幅も大きく広がりました。

トークの対象
・ Apple IntelligenceやAppleの最新技術に興味がある方

*NDAに配慮し、公開されたWWDCや公式ドキュメントなどの情報を元にトークを展開する予定です。

Gemini APIによる動画解析とScreen Time APIを組み合わせ、「腕立て100回が自然に続けるアプリ」を開発しました。
筋トレ継続の課題は、「習慣化の難しさ」と「記録の面倒さ」。
これを解決するため、カメラで撮影した筋トレ動画から回数を自動カウントするAIと、アプリを自動制限するScreen Time APIの融合でこの課題に挑戦しました。

特に注力したのが、プロンプトエンジアリングによるAI精度の改善。
以下の6ステップでプロンプト実装を進めていきました。

① 期待アウトプットの定義
② シンプルなプロンプト作成
③ 単一映像での検証
④ ズレの特定と修正
⑤ 別映像での汎化確認
⑥ 複数プロンプトの統合

この手法により検出精度が40％から95％へ飛躍的に向上し、動画内に音声を含めることでさらなる改善を実現しました。

また、Screen Time API（DeviceActivity, ManagedSettings, FamilyControls）を組み合わせ、目標未達成時に娯楽アプリを自動ブロックする機能を実装。
ユーザーの意志力に頼らず、強制力のある習慣化を実現しました。

本LTでは、AIの利活用に役立つ
プロンプトエンジアリングの実践的アプローチと、Screen Time APIのリアルな活用知見を実際にリリースしたアプリを元にお話しします。

「生成AI 」で新しいユーザー体験を作りたい方に、具体的なヒントを持ち帰っていただける内容です！

「皆さん、もうMCPデビューしましたか？」
LLM活用の真価は、私たちの開発環境が持つ「コンテキスト」をいかに伝えるかにかかっています。
本セッションでは、その答えとなる「Model Context Protocol (MCP)」が、いかにしてiOS開発を根底から変革するかを、具体的な実践例と共にお話しします。

Figma MCPの連携より、デザインデータそのものをコンテキストとしてLLMに渡すことで、面倒な手作業による実装は過去のものとなり、デザインから実コードへの変換がシームレスに実現します。

ローカルMCPサーバーを実装し、あなたのMacをAIの忠実な"手下"に変える方法を解説します。
自然言語で指示を出すだけで、AIがgit操作、ビルド、UIテストといった定型作業を自律的に実行。あなたは創造的な作業にのみ集中すればよいのです。

MCPの可能性は無限大です。将来的にはGitHubのような外部サービスや、社内の内部管理画面ともMCPで連携し、開発に関わるあらゆる情報を繋ぎこんでいきます。

「世界をMCPで繋げる」

みなさまが抱えるプロダクトはもうSwift6へのマイグレーションは済んでいますか？
中には鋭意対応中の開発チームもいるかと思われます。
そんなあなたに「Take your time」と伝えたい...。

Swift 6.2では、Swift Concurrencyの機能が大幅に改善され、これまでのスレッドセーフなプログラミングの考え方がより簡潔になります。
このセッションでは、WWDC25の基調講演と実際の開発現場でのマイグレーション経験をもとに、従来のSwift 6対応がSwift 6.2によってどのように変わるのかを詳しく解説します。

QA依頼、面倒だと思ったことはありませんか？

私たちのチームでは、PRごとにQA依頼を行っており、従来のフローは「ビルドの設定・配信」と「SlackでのQA依頼作成」という、手間の多い作業が分断された状態でした。しかも、どちらにも同じような情報を手動で入力する必要があり、非効率でミスも少なくありませんでした。

そこで私は、このフローをスクリプトとXcode Cloudを組み合わせて自動化することにしました。今では、スクリプトへ最低限の入力をするだけで、ビルド配信からSlackへのQA依頼投稿までが一気通貫で完了するようになり、手間もミスも激減しました。

ここに至るまでの経緯を失敗したパターンも含め紹介します。Xcode Cloudの導入を検討している方にとっても「どのくらいのことができるのか」「どこでつまずくか」などのリアルな参考になる内容をお届けできればと思います。

本トークでは、Kotlin Multiplatform (KMP) を利用したアプリ開発で、AndroidとiOS共通のビジネスロジックにおける状態管理とデータベース（DB）設計を、GitHub Copilotで効率化する方法を紹介します。

KMPはコード共通化の利点がある一方で、KotlinコードがiOSエンジニアには分かりづらく、状態やデータの流れが複雑になりがちです。また、ローカルDB導入時には、テーブル間のリレーションや各カラムの役割が不明瞭になる課題も多くのプロジェクトで直面します。

そこで本LTでは、Copilotを活用した2つのアプローチを提案します。

まず、Copilotを活用したDBのリレーションとカラムの役割の可視化について。既存のSQLスキーマやKMPデータクラスから、Copilotがどうリレーションを推論し、カラムの役割を可視化するのかを具体的なプロンプト例を交えて示します。これにより、複雑なDB構造を把握し、設計のボトルネックを早期に発見できます。

次に、Copilotによる既存の状態の可視化に焦点を当てます。KMPアプリの状態管理は様々ですが、時間の経過で状態遷移や依存関係が複雑化しがちです。Copilotが既存Kotlinコードから状態を解析し、状態遷移図や関連イベントの流れを提案・可視化する方法を探ります。これもCopilotへのプロンプト例を通じて、アプリの内部状態理解と予測可能な状態管理構築のヒントを提供します。

本LTでは、単体テストのフレームワークをXCTestからSwift Testingへ移行したいと考えている方向けに、具体的にどのようにSwift Testingへ移行するのかを経験談を交えて紹介します。

WWDC24で新たに紹介されたテストフレームワークであるSwift Testingも、紹介されてから1年以上経ち導入事例も増えてきていると思います。
そのような情勢もあり、まだXCTestで単体テストを行なっているチームでも、Swift Testingへ移行していきたいというモチベーションが高まっているところも多いでしょう。
しかし、実際にSwift Testingへ移行するときにどのように移行するのが良いのか、どれぐらい大変なのかが掴めないとなかなか踏み出しづらいです。

本トークでは、実際に担当しているiOSアプリプロジェクトの単体テストをXCTestからSwift Testingへ移行した経験をもとに、以下内容についてお話しします。

• 実際の単体テストをXCTestからSwift Testingへ移行した手順
• 移行時の工数感
• 移行時に困ったこと

新しいフレームワークを導入するにあたって、メンバーを巻き込んでいく必要がありますが、実際にどのように説得して、導入まで漕ぎ着けたかというところまでお話しします。

実際に移行した経験からSwift Testing移行のよりリアルな知見を共有できると思います！
Swift Testing移行を考えている開発者にとっては、移行を検討する上で大きなヒントになるはずです！

プログラマーの資本と聞いて、あなたは何を思い浮かべるでしょうか？

これまで読んだ技術書の厚み？
経歴書に書ける経験の長さ？
チーム開発でうまくやっていけるソフトスキル？

いいえ、違います。

腰です。
それも健康な、腰です。

プログラマーの真の敵は刻々と変わりゆく仕様ではなく、集中力を阻害する腰痛です。
そんなわけで、健康な腰の維持のために職場や自宅で昇降式デスクを使われている方も多いかと思いますが、本当に「昇」してますか？
スタンディングデスクなのに最後にスタンダップしたのがいつだったか思い出せない人も多いでしょう。
いいえ、あなたを責めているわけではありません。
人間の意志とは実に弱いもので、楽な方に流れていってしまいます。

しかし、ご安心ください。
立つことが億劫になってしまうのなら、スタンディングデスクに一定時間毎に自動で上昇する機能をつけて、仕組みで解決してしまいましょう。
本LTでは、昇降デスク FlexiSpot、コントローラーとなる M5Stack、サーバーとなる Raspberry Pi, スマートホームを実現するOSSのHomeAssistantとを組み合わせて、FlexiSpotをスマホやパソコンから操作したり、時刻やアクションをトリガーに自動で昇降する機能を実現する方法をご紹介します。

本LTでは、テストでHealthCareデータの登録が必要だけど毎回面倒と思っている方に向けて、データの登録を簡易に行うアプローチを紹介します。

HealthKitを用いたiOSアプリでは、テストの際にHealthCareデータの登録が必要になるはずです。
しかし、テスト用にHealthCareデータの登録を簡易に行うためのツールはAppleから公式には出ておらず、手動で登録を行うケースも少なくないでしょう。
手動での登録は、テストごとに煩雑な操作を伴うため、特にE2Eテストの自動化においては大きな障害となり、結果的にテストの工数が増加する要因となります。
私の所属するチームでもその課題に直面したため、試行錯誤の末、CLIコマンド一つで指定の端末に必要なデータを自動登録するツールを作成しました。

本トークでは、実際にデータ登録自動化ツールを作成したことと、それを業務で運用してみた経験から、次のような内容についてお話しします。

• CLIでHelthCareデータを登録する仕組み
• CLIでHelthCareデータ登録を実現するときにハマったこと
• 業務で実運用してみての感想

ツールの実装は単なるシェルスクリプトではなく、XCTestやシェルスクリプトを組み合わせて行いました。具体的な実装方法について、ソースコードを交えながら詳しく説明します。

HealthKitを使った開発をしている、もしくはこれからしようとしている開発者にとっては、テストの工数を短縮する上で大きなヒントになる知見を共有します！

本トークでは、Appleが公開した研究向け機械学習ライブラリMLXのSwift向けバインディング「MLX Swift」を用いて、任意のモデルをローカルLLMとして動かす手順を解説します。

具体的には、Hugging Faceで公開されている軽量モデルの選定、モデルへのプロンプト送信と応答の取得方法、そして実際にモデルとの対話を行った際の挙動や、処理速度・メモリ使用量など実用面で見えてきた課題や使い所について共有します。

【話すこと】

• MLXとMLX Swiftの概要
• MLX Swiftを用いたローカルLLMの構築と実行までの実装ステップ
• 実際に動かして見えてきた課題とオンデバイスAIの可能性について

AIツールをコードレビューに導入してみたものの、期待していたほどの効果を感じられない...そんな経験はありませんか？

CursorやGitHub Copilotなど最新のAIツールを組み合わせることで、ようやく「AIが本当に役立つレビュー環境」を構築できました。重要だったのは、AIに全てを任せるのではなく、AIと人間の得意分野を明確に分けることでした。

このLTでは、実際のiOSプロジェクトのPRを使って、複数のAIツールを連携させたレビューフローを実演します。AIがコードの詳細チェックやパターン検出を担当している間に、人間はアーキテクチャやUX観点での判断に集中する。

この役割分担により、レビュー時間の短縮と品質向上を同時に実現した事例をご紹介します！

SwiftUIは年々進化し続け、これまでUIKitに頼らざるを得なかった複雑な挙動も、SwiftUIだけで完結できるようになりつつあります。
例えばScrollView一つとっても、iOS 17では特定のビューへ自在にスクロールできるようになり、iOS 18でスクロール位置の変化を取得し、任意の処理を実行できるようになりました。さらにiOS 26ではLazyStackと組み合わせた際のパフォーマンスが数倍に向上したようです。

しかしプロダクトとしてユーザーのことを考えた時、4年前に登場したiOS 15でも今すぐサポートを終了するのはそう容易ではありません。

このLTでは、OSバージョンによるSwiftUIの機能差やiOS・iPadOS間のプラットフォームの違いに起因する挙動の違い、そしてそもそもSwiftUIでは実現できないことを基に、SwiftUIを諦めてUIKitに頼るべきタイミングを10個ご紹介します！

Swift OpenAPI Generatorは、Appleがオープンソースで開発を主導するOpenAPIから関連コードを自動生成するツールです。このテクノロジーの魅力は、既存のツールと比べてよりSwiftらしい型による安全な表現が実現できる点にあります。
しかしながらSwift OpenAPI Generatorへの移行は必ずしも円滑に進むとは限りません。
APIにリクエストしてからレスポンスを受け取り、それをエンティティオブジェクトにマップするまでの間に、複数のポイントでエラーと向き合う必要があります。

本発表では、その中でも特に多様なエラーをどのように整理し、アプリで統一的に扱うか、その一つの実践的なアプローチをご紹介します。
具体的にはHTTPエラーレスポンス, ネットワークエラー, 特定のオペレーションを実行中に発生するエラーなどから必要な情報を取り出してアプリ固有のエラーに変換する方法、そうしたエラーハンドリングをアプリで画一的に実施する方法、それらの実装の正当性を検証するテストのスマートな書き方をご共有します。

AppleからリリースされたTN3187: Migrating to the UIKit scene-based life cycleにて、全アプリでUIKit based life-cycleからScene-based life-cycleへの移行が必須になることが発表されました。
また、こちらのドキュメントにはScene-based life-cycleに移行しないとアプリが起動しなくなるということも明記されているので、一定数移行作業を行わなければならないプロジェクトが多く存在するのではないでしょうか？

しかしながら、アプリの心臓とも言うべきライフサイクルは、アプリの要件としてイベントの送信やDeepLink周りのハンドリングなど色々な考慮が求められます。
また、当然無事故で移行することが求められ、アプリのデリバリーはブロックしないように実行しないといけない、慎重さとスムーズさを求められるプロジェクトになると考えられます。
このようにScene-based life-cycleへの移行のようにドラスティックな変更が必要になった背景やどのような対策を行わなければならないのか、時間が許せば移行に関するtipなども交えた実践的な内容をお話ししたいと思います。

Apple Vision Proの登場などにより、3Dの空間表現は身近なものになってきました。RealityKitをはじめとしたフレームワークのおかげで、Swiftで3Dコンテンツを扱うことも簡単になっています。
では、ここからさらに"次元をひとつ上げる"ことはできないでしょうか？

今回はSwiftを使って3Dのその先、4D空間のオブジェクトを描いてみるという、ちょっと変わった挑戦をしてみました。
RealityKitで直接扱えるのは当然3Dまで。そこで数学の力を借りることで、4Dのオブジェクトを無理やり3Dに落とし込んで描画します。
このLTではRealityKitでの3Dレンダリングの基本をおさらいして、そこから次元を上げて4Dレンダリングを実現する方法を紹介したいと思います。
さらに、ドラッグなどのジェスチャー操作で4Dオブジェクトをぐりぐりと動かすインタラクションも実装しました。4D空間を見るだけでなく、触って体感できるデモをお見せします！

難しい理屈は置いておいて、なんだか不思議で見ているだけで面白い。そんな4Dの世界を一緒に体験してみませんか？