プロポーザル

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

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

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

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

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

iOSアプリの配布方法というと「AppStoreで公開」か「社内配布（MDMやTestFlight）」の二択だと思っていませんか？ 実はAppleは、企業や団体向けに「Custom App（カスタムApp）」という第三の配布形態を提供しています。 この配布方法は、App Storeを利用しながら、あらかじめ指定した対象者のみにアプリを安全に届けることができる仕組みです。 業務アプリやパートナー限定アプリなどに非常に適していますが、認知度はまだ高くありません。

本セッションでは、AppStoreの配布方法の進化を振り返りつつ、Appleが提供する「パブリック」、「社内配布」、「プライベート（Custom App）」という3つの主要な配布手段の違いや選定基準、審査プロセス上の違い、組織的な利点や制約をわかりやすく整理します。 私が実際に全国約400店舗に向けた業務アプリの配布をCustom Appを用いて行ったので、それにまつわる経緯や運用方法を交えつつお話しできたらと考えています。

「社内用アプリだけどAppStore配信もしたい」「審査が不安」「配布先を限りたい」──そんな悩みを持つiOSエンジニアやIT管理者にとって、“Custom App”は強力な武器になります。あまり語られることのないこの配布手法の実際を、現場の視点でお届けします。

本トークでは、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を使った開発をしている、もしくはこれからしようとしている開発者にとっては、テストの工数を短縮する上で大きなヒントになる知見を共有します！

Swift Package Manager 5.6から登場した Build Tool Plugin。
ビルド時にコードやリソースを生成できる強力な機能として、登場から3年が経ち、多くのプロジェクトで利用が進んでいます。

そんな Build Tool Plugin、便利さの裏で「あること」を見落としていませんか？

Derived Data に出力される成果物。
それがどこまでアプリに影響を与えるか、普段どこまで意識してビルドしていますか？

今回の発表では、Build Tool Plugin を通して気づいた“とある落とし穴”と、それにまつわる 実体験からの学びを共有します。
思わず「ヒヤッ」としたその出来事、Derived Dataの奥底から灼熱の有明にお届けします。

本トークでは、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の世界を一緒に体験してみませんか？

私たちが日常でよく目にするバーコード。その裏には、見た目ではわからない微妙な規格の違いが潜んでいることをご存知ですか？

本 LT では、 STORES レジアプリの開発中に直面した「Vision フレームワークが 12 桁のバーコードを 13 桁として認識してしまう」という現象をきっかけに掘り下げた、バーコードの規格と Vision フレームワークの仕様について紹介します！

この現象により、 12 桁のバーコードで登録されている商品をスキャンしても、ヒットしないという問題が発生しました。
Apple の公式ドキュメントでは明示されていない現象で、「なんでや！」と言いたいところですが、バーコードの規格をよく見ると、Vision フレームワークはその規格の性質を利用して、認識していたことがわかりました。
(Google の API はちゃんと認識できるんだけどな…)

本 LT では、以下の内容について話します。

• UPC-A (12 桁) と EAN-13 (13 桁) バーコードの仕様
• Vision フレームワークの認識ロジック
• 正確なバーコードかどうかを判定するロジック
• 回避方法と実装テクニック

1 桁の違いがオペレーションを止めてしまう、現実世界とアプリを繋ぐアプリならではの知見を共有します！
皆さんもバーコードマスターになりましょう！

去年 WKWebView 関連の開発をするとき、どうしても解決できない問題を発見しました。

当時作った issue： https://bugs.webkit.org/show_bug.cgi?id=274818 （クリックがランダムで反応しなくなる問題。）

それを頑張って調べて、WebKit のバグだと確認し、WebKit の Bugzilla に提出しました。
WebKit の開発者から、それはすでに別の PR で解決されていると言われ、でも再現できませんでした。

色々試した結果、それは WebKit のテスト用スクリプトに問題があると判明しました。
このスクリプトは、ローカルでコンパイルした WebKit を既存のアプリに取り込んで実行するスクリプトです。
実行する際、必要な環境変数の設定に失敗して、アプリは古い WebKit のままで実行されます。
このバグは将来 WebKit の修正に取り組む皆に影響するので、私は新しい Issue を作って、PR を出して、マージされました。

https://bugs.webkit.org/show_bug.cgi?id=275207
（SIP環境でDYLD_FRAMEWORK_PATHが設定できない問題）
https://github.com/WebKit/WebKit/pull/29578

この LT は、この問題発見から PR を出した流れとその中の面白いところを話します。

はじめてSNSアプリを作るとき、多くの開発者が直面する最大の壁。それがApp Storeの審査(App Review)です。

SNSアプリをApp Storeにリリースするには、他ジャンルのアプリ以上に厳しいApp Reviewの壁が立ちはだかります。
特に、ユーザー生成コンテンツ（UGC）を扱うアプリは、ユーザー保護の観点から求められる機能は多岐にわたり、設計段階から審査基準を意識していないと、何度もリジェクトされてしまうことも珍しくありません。

このLTでは、個人で開発したSNSアプリが何度もリジェクトされながらも、最終的にApp Storeに掲載されるまでの実体験をベースに、以下のような具体的なノウハウを共有します。

LTで話すこと：

• 実際にAppleにリジェクトされた理由と、それにどう対応したか
• App Reviewガイドラインに則った設計・実装で気をつけるべきポイント
• ガイドラインには明記されていないが、対応すべきこと

「はじめてのSNSアプリ開発」でつまずかないための実践的な知見を、リアルな失敗談とともにお伝えします。
今後、UGCを扱うアプリを作成する方の、少しでも力になれたら幸いです。

いつでもどこでもキャンプができたらいいな。そう思ったことはありませんか？
visionOSアプリで、現実では難しい「理想のキャンプ体験」を仮想空間で実現することができます。

本LTでは、Reality Composer Proを用いてvisionOSアプリに「春夏秋冬」の季節感を演出するパーティクルを作成・実装する方法をご紹介します。
春には桜の花びら、夏にはホタルの舞、秋には紅葉の舞い散り、冬にはしんしんと降る雪。それぞれ異なる自然の動きを再現するために、表現や動きの調整に多くの工夫が必要でした。そんな自然の表現が、visionOSでどのように再現できるのかをハッカソンのチームで開発したキャンプアプリの実例を交えて話します。

LTで話すこと：

• Reality Composer Proとは
• 春夏秋冬の異なるパーティクルの作成方法
• visionOSアプリでのパーティクルの活用実例