トーク

デジタルプロダクトの成功には、ユーザー体験の最適化が欠かせません。そこでよく用いられる手法の一つに A/B テストがあります。
A/B テストは、Webサイトやアプリなどで、異なるバージョン（バージョン A と B）をユーザーにランダムに表示し、どちらのパターンがより効果的かを検証する手法です。新しい機能や、既存の機能を削除した時の影響を定量的に評価することができます。

一見簡単そうに思える A/B テストですが、適切に実施することは難しく、様々な罠が潜んでいます。例えば、ユーザーに表示するバージョンをサーバーから取得できない時、どちらかのバージョンにフォールバックしてそのログを送信してしまうと、結果にバイアスがかかってしまいます。このように、アプリ側の実装によって A/B テストが失敗してしまうことがあります。

本トークでは、A/B テストの基本的な考え方と、アプリでの実装・実施時に気をつけた方が良い点を、実体験を交えながらお話します。A/B テスト結果の具体的な分析方法についてはお話しません。
参加者はこのトークを聞くことによって、A/B テストの設計とアプリ実装時の注意点を学ぶことができます。

私たちのiPadアプリはリリースから約15年が経過し、長年の機能開発の結果、技術的負債を抱えるに至りました。
具体的には、

• 肥大化した "Fat ViewController" が多数存在し、改修時の影響範囲の特定を困難にしています。
  • シングルトンやAppDelegateへの過度な依存が、クラス間の密結合を生み出しています。
  • 上記の結果として、ユニットテストを書くことが極めて難しい、あるいは不可能なコードベースとなっています。

また、コードの大部分は歴史的経緯からObjective-Cで書かれており、今後の採用観点からSwift化への置き換えとこれらの負債を解消しながらが大きな課題です。
本セッションでは、これらの技術的負債に対し、日々の機能開発を止めることなく、いかにして立ち向かっているか、そのアプローチを共有します。

主にお話しする内容：
Fat ViewControllerの分割戦略: 巨大なViewControllerの責務を、Presenter/ViewModel//UseCaseといった単位へ安全に分割していくか、具体的なリファクタリング手法をコードと共に解説します。
依存関係の解消プロセス: DI（依存性注入）の考え方を導入し、AppDelegateやシングルトンへの直接参照をどのように剥がしていくか、その段階的なプロセスを共有します。
テスト可能なコードへの改善: 既存のコードにユニットテストを追加するための、インターフェース導入や副作用の分離といった具体的な手法を紹介します。

このセッションを通じて、同様の課題を抱える開発者の皆さんが、明日から自身のプロダクトで試せる具体的な一歩を踏み出すための、現実的な選択肢と知見を持ち帰っていただくことを目指します。

2ヶ月ほど前Swift Forumsに投稿された Xtool: cross-platform Xcode replacement. Build iOS apps on Linux and more! という投稿をご存知でしょうか。

Linux上でネイティブのiOSアプリ開発をビルドするためのXcodeに成り変わるツールを開発したという内容で、これは私にとってとても衝撃的でした。

iOSアプリ開発といえばmacOSが必要というのは多くの人に知られていると思います。IDEであるXcodeを始め、プロジェクトをビルドするための xcodebuild や署名用の codesign など、多くのツールがmacOS上でしか提供されていないためです。

それではこのXToolというツールはどのようにmacOS外でのiOSアプリビルドを可能にしたのでしょうか。それにはSwiftのビルド技術の進化が大きく関わっています。

このトークで話さないこと

• XToolの使い方

このトークで話すこと

• SE-0387によって仕様策定されたクロスコンパイルのための仕組みについて
• XTool作者によって実証用に用意されたswift-sdk-darwinについて

私たちは普段Swiftのコードを通じて、画面に美しいUIを表示したり、スピーカーから音を鳴らしたり、ユーザーのタップを受け取ったり、ネットワーク越しにデータを送受信したりしています。

しかし、Swiftで書かれたプログラムが、どうやってiPhoneやMacで実行されるのか、考えたことはありますか？

コンピューターはどのような仕組みで動いているのでしょうか。コンピューターの頭脳とも言えるCPUからは、世界がどのように見えているのでしょうか。

Swiftのプログラムではなかなか見えてこないコンピューターの世界が、OSを介さずに動くEmbedded Swiftだと少し見えてきます。
　
このトークでは、Embedded Swiftを活用してプログラムが動く仕組みを解き明かしていきます。

プログラムがどうやってコンピューターで実行されるのか、メモリや入出力装置とどのようにコミュニケーションするのか、知識だけでなくコードとデモを交えて解説します。

普段のアプリ開発では見えない、低レイヤーの世界を一緒に覗いてみましょう！

Apple Watchのようなリソース制約が厳しいデバイスで、音・振動・UIアニメーションをリアルタイムに動かし続けるにはどうすればいいのか？
watchOSを使った開発では、シミュレーターでは軽快に動いても実機では長時間安定して動作しないことが多々あります。

私がwatchOS向けのメトロノームアプリを開発した時はwatchOSでリアルタイムな処理を安定させるための設計が欠かせませんでした。

本発表では、watchOSで高負荷な処理を安定して動かすための設計とパフォーマンスチューニングの実践知見を、背景から具体的な施策事例まで解説します。

具体的には

• AVAudioEngineの基礎知識とwatchOS実機での注意点
• watchOSにおける触覚フィードバック(WKHapticType、SensoryFeedback)の概要
• 音・振動・UIアニメーションを同時に動かすタイミング制御の実装
• 実機で発生しやすい処理落ち・中断のパターンと防止策
• AVAudioEngineをwatchOS上で効率良く動かすためのパフォーマンス改善施策

について詳細に話します。

また、実用に耐えるようにチューニングが成功した証としてメトロノームアプリで練習した作品をチューバで実演奏します。

Apple Watchで高負荷なリアルタイム処理に挑む方へ向けて役立つノウハウをお伝えできれば幸いです。

Apple WatchでUIアニメーションと一緒に音や振動を鳴らし続けるにはどうすればいいのか？

watchOSには厳しいリソース制約があり、シミュレーターでは軽快に動いても実機では長時間安定して動作しないことが多々あります。
私がwatchOS向けのメトロノームアプリを開発した時はwatchOSでリアルタイムな処理を安定させるための設計が欠かせませんでした。

本発表では、watchOSで高負荷な動作を安定化させるために実際に効いたパフォーマンスチューニングのエッセンスを共有します。

具体的には

• AVAudioEngineのタイミング管理で触覚フィードバックやSwiftUIアニメーションを同期させる構成
• AVAudioEngineをwatchOS上で効率良く動かすためのパフォーマンス改善施策

について話します。

また、実用に耐えるようにチューニングが成功した証としてメトロノームアプリで練習した作品(ショートver.)をチューバで実演奏します。

watchOSでリアルタイム処理に挑む方の参考になれば幸いです。

「出品って、正直めんどくさい」——そんなユーザーの声から始まった、Yahoo!フリマの生成AI機能「らくらくAI出品」。
本セッションでは、UX視点で“かんたんな出品体験”を実現するために試行錯誤したらくらくAI出品のUI/UX設計の工夫と、実装面で直面した課題とその解決策を紹介します。
生成AIは万能ではありません。だからこそ、ユーザーに過度な期待をさせず、でも手間を減らし、迷いを最小化する。
生成AIとユーザーの自然な関わり方をどう設計し、“使いたくなる体験”を生んだのか。失敗と発見に満ちた機能開発の舞台裏の"リアル"にお届けします。

Apple Vision Proを活用し、自分の発した声や楽器の音程を空間上に可視化する機能を実装しました。

単に周波数を表示するのではなく、「今の音が目的の音程に対して高いか・低いか」を3D空間に直感的に表示し、自分の音感をリアルタイムで補正できる仕組みを構築。
実際にこのアプリを使って練習を継続した結果、ピッチのズレ補正が体感でき、音感トレーニングとしての実用性が期待できそうです。

本セッションでは、空間UIによる音程フィードバック設計、Vision Pro上での周波数検出と3Dビジュアライズ手法、日々の改善プロセスまで、実装から習熟までの過程を具体的に解説します。

空間コンピューティングの新しい応用例や、感覚の可視化×習得支援に興味のある方にとって、技術面・UX面の学びを持ち帰っていただける内容です。

私は2019年にiOSエンジニアからマネージャーに転向し、それ以来、iOS開発の現場から離れていました。
しかし、現在はエンジニアリングマネージャー（EM）としてマネジメントを主務としながらも、小規模な機能の開発や技術的な判断を行っています。

このトークでは、私がどのようにして5年分の技術ギャップを埋めつつ、業務を遂行しているのかについてお話しします。
具体的な事例として、AIの活用方法や最新技術への適応プロセスを2025年の視点から共有します。
技術的なキャッチアップのヒントや、EMとしての役割を維持しながら開発に関与する方法についても詳しく説明します。

iPhone・iPadアプリにおいて、マルチウィンドウ機能を活用しようとしても、画面サイズの制約によりその利用には限界がありました。
しかしvisionOSでは、周囲の空間全体を表現の領域として活用できるため、複数ウィンドウを互いに干渉せず同時に配置することが容易になり、macOSを超える表現力を実現しています。

これはRealityKitを用いたXR機能に匹敵する、空間コンピューティングの大きな強みだと考えています。

このLTでは、一般的にiOS・iPadOSで提供されるようなアプリをvisionOSで提供する際にvisionOSの性能を引き出す方法を、マルチウィンドウ機能に焦点を当ててご紹介します！

• マルチウィンドウを使った魅力的なアプリ表現の具体例
• visionOSでのマルチウィンドウの実装方法

iPadは、iOS 9でマルチウィンドウ機能が導入されて以来、複数のアプリを同時に利用できるよう段階的に進化してきました。そして、今年登場予定のiPadOS 26ではその機能がさらに進化し、各ウィンドウのサイズを自由に変更したり、複数のアプリを重ねて表示したりと、macOSのような、より自由度の高いマルチタスク環境が実現します。

この変化は、私たちiOSエンジニアにとって、単なるUI表現のバリエーションの追加にとどまらず、アプリの設計思想そのものに影響を与える可能性があります。

もちろん、macOSでさえマルチウィンドウの活用が自然に馴染むのは一部のアプリに限られており、すべてのアプリで多ウィンドウ対応が最適解になるわけではありません。しかし、特定の用途、例えばドキュメント編集やクリエイティブツール、情報集約型のアプリにおいては、ユーザー体験を大きく向上させる可能性を秘めています。

本トークでは、iPadOS 26における新しいマルチウィンドウ環境を最大限に活かすために、どのようなアプリ表現が可能になるのかを具体例とともに紹介しつつ、その実装方法を解説します。

想定視聴者:
マルチウィンドウ対応に関心があるiPadOSやvisionOSのアプリエンジニア

話す内容:
・ マルチウィンドウだからこそ実現できるアプリの表現例
・ マルチウィンドウ環境におけるUISceneのライフサイクルの要点
・ 具体的なマルチウィンドウの実装方法
・ マルチウィンドウでできること・できないこと
・ 既存アプリのiPadOS 26への移行で押さえるべき注意点

Apple Vision Pro上で180°立体動画を体験できるViewerをSwiftネイティブで実装し、100名以上に実際に体験いただきました。
その事例をベースに、Apple Vision Proを初めて体験する方でも楽しめるアプリを作るための数多くの工夫を解説します。

40を超える具体的改善ポイントがありました。
そこから、操作ミスや混乱を生まないための徹底したUIのシンプル化、カルーセル形式のコンテンツ選択UI、空間上で押しやすくしたカスタムボタンの設計などをソースコードとデモを交えて紹介。
Vision Pro上での空間コンピューティングUIを実装する上で得た知見と、ブラッシュアップを余すことなくお伝えします。

このViewer実装では、体験者のフィードバックから得た改善点の反映を数ヶ月に渡って行いました。
多くの時間を使って得た知見を皆に共有することがこのセッションの目的です。

このセッションを見ることで、visionOSでカスタムUIコンポーネントを作る際の要素が整理でき、Apple Vision Pro未体験者でも使えるアプリを作成する知見が得られます。

Vision Proアプリ開発の実例に興味がある方、立体動画や空間UIの最適化に取り組んでいる方に特におすすめのセッションです。

Swiftでバックエンドも開発できたら、便利だと感じたことがある方は多いのではないでしょうか？
フロントエンドとバックエンドで異なる言語を使い分ける必要がなく、一つの言語でアプリケーション開発を完結できれば、開発効率は格段に向上します。
Server-Side Swiftは、開発者がフロントエンドとバックエンドをSwiftで統一できる選択肢を提供します。
本LTではSwiftをサーバーサイドでも活用する利点と、複数あるServer-Side Swiftのフレームワークの中でも、特にVaporに焦点を当てます。

【本LTで得られること】

• iOSアプリ開発者がすでに持つSwiftの知識をサーバー開発にも活かせる具体的なメリット
• PerfectやKituraなどのフレームワークと比較した時のVaporの特徴や優位性
• 短時間で始められるVaporの環境構築手順
• クライアントに返すJSONレスポンスの実装と、Codableを活用したデータ連携方法

Vaporは型安全性、Swift Concurrencyのサポートなど、Swiftの強みを最大限に活かしたフレームワークです。
本LTでは、まずSwift Package Managerを使用した環境構築手順を説明し、その後、基本的なルーティング設定とミドルウェア構築について解説します。続いて、async/awaitを活用した非同期処理を実際のコードで示します。さらに、Codableプロトコルを活用したモデル定義とJSONレスポンスの実装を通して、iOSアプリとサーバー間でのスムーズなデータ連携方法を示します。

今日からすぐに試せる具体的な知識と実装テクニックを5分間でお届けします。

Embedded Swiftの登場により、Swiftで組み込み機器向けのプログラミングが可能になりました。

AppleがSecure Enclaveの開発でEmbedded Swiftを使っていたり、去年のiOSDC JapanでもRaspberry Pi PicoやPlaydate、ゲームボーイアドバンスをEmbedded Swiftでプログラミングをするトークがあったりと、とても注目の領域です。

私もそれに触発されてゲームボーイアドバンスのプログラミングをはじめました。しかし、"Safe"が売りのSwiftで、組み込みプログラミングに特有の"Unsafe"な手続きをどう実装したらいいか、かなり試行錯誤しました。

C言語やObjective-Cを使えば簡単なのはわかっています。でも、私はなるべくSwiftだけでプログラミングしたい！ なぜならSwiftが好きだから！

このトークでは、ゲームボーイアドバンスでのプログラミング例と共に、「アドレス指定のメモリアクセス」「レジスタ操作」「関数ポインタによる割り込み処理」「＿attribute＿の利用」「インラインアセンブラ」に挑戦した結果を紹介します。

Embedded Swiftの可能性と「危なさ」を体感してください！

Apple Vision Proの登場で注目される空間写真や空間ビデオなどの3Dコンテンツ。しかし、Appleやサードパーティのアプリで提供されるコンテンツはクオリティが高いものの、それだけでは物足りなさを感じている方も多いのではないでしょうか。

そんな方におすすめしたいのが、自分で撮影したオリジナルコンテンツです。思い出や特別な瞬間を切り取った自作のコンテンツは、プロが作った作品とは一味違う、特別な価値をもたらしてくれます。

先日のWWDC25では、時期OSに向けてVR撮影機器との連携を強化する発表もされました。iPhoneで撮影しても手軽に楽しめますが、様々な専用の機材で撮影して活用する土壌も整えられつつあります。

本発表では、比較的安価で手を出しやすいミラーレスカメラを使い空間写真や空間ビデオを撮影する方法と、その魅力についてご紹介します。Apple Vision Proの新たな可能性を、自らの手で引き出してみませんか？

iOS 26の登場により、App Intentの重要性が劇的に高まりました！
もはや「あったら便利」な機能ではなく、Appleエコシステムでユーザーの期待に応え、競合と差別化するための必修技術です。
あなたのアプリはこんな状況ではありませんか？「Siriに話しかけても反応してくれない」「Spotlightに表示されるのは競合アプリばかり」「OSの最新機能の恩恵を受けられず、ユーザーエンゲージメントが低下している」。本セッションでは、これらの課題をApp Intentで解決し、プロダクションレベルで活用するための全知識を提供します。

App Intentは、アプリの機能をシステムに公開する役割を持ちます。
SiriやSpotlight連携の基本に加え、iOS 26で加わった新機能「Interactive Snippets」や「画面上のエンティティ連携」により高度なユーザー体験を実現するテクニックをお伝えします。

単なる機能紹介に留まらず、実装時の「ハマりポイント」やトラブルシューティング、App Intentがもたらす「アプリを開かないUX」による利便性の向上とそのビジネス的価値を力説し、最新のiOS開発を勝ち抜くための即戦力スキルを提供します。

明日からあなたのアプリをAppleエコシステムの中核に据え、競合に差をつけ、より多くのユーザーに愛されるアプリへと進化させましょう！

SwiftとRustは互いに影響を与えながら発展した言語と言われることがあります。実際、他の言語に比べ、多くの類似点見つけられるでしょう。しかし、その類似性にも拘らず、Swiftを書くノリでRustを書くと思わぬ落とし穴にハマってしまいます。

例えば、Swiftのprotocolがオブジェクトの振舞いを保証するインターフェースと考えられるのに対し、Rustのtraitはポリモーフィズムのための制約と考えられます。そのため、Swiftではダウンキャストやprotocolによる型チェックを行えますが、Rustでこれを再現するためにはAny traitを用いた煩雑なプログラムを組まなければなりません。

また、Swift 5.9で導入されたnoncopyableはRustのownershipによく似ています。しかし、noncopyableが適宜使い分けられる仕様であるのに対し、ownershipは常に意識しなければならない言語の中核となる仕様です。そのため、Swiftでは参照型と複合してプログラムを組めますが、Rustでこれを再現するためにはRefCellを用いた冗長なコードを書かなければなりません。

このような言語仕様の違いによる落とし穴は言語の指向性の違いに由来します。本トークでは、その言語の指向性を紐解くことで、なぜ上記のような似て非なる言語仕様になったか考えます。

近年、GitHub CopilotやClaude CodeといったAIツールがコードレビューの分野に進出してきています。
これにより、AIがコードを評価することが一般的になりつつあります。

本LTでは、実際にAIレビューで起きた珍事件・失敗例を5つ紹介します。存在しないAPIを提案する、過剰な最適化を求める、テストコードにマジックナンバー回避を強要する、急に英語に切り替わってまくしたてる、絵文字に気を取られる...など、思わず「それは違うだろ！」とツッコミたくなる事例ばかり。

私：「こういうことってよくあるんですか？」
AI:「はい。よくあります。」

これが現実です。

しかし、AIレビューを否定するのが目的ではありません。これらの失敗から学んだ「AIレビューとの正しい付き合い方」として実際にプロジェクトに導入できる具体的なルール化手法をお見せします。

AIは優秀なアシスタントですが、適切なガードレールがあってこそ真価を発揮します。
AIツールを使い始めた方、導入を検討している方に、共感と今日から使える実践的な知見をお届けする5分間です。

サブスクリプションの機能をアプリに導入する際に、ペイウォール（サブスクリプションの登録を促す画面）のデザイン、文言、表示タイミングで悩んだことはありませんか？Human Interface Guidelinesにはアプリ内課金についてのドキュメントがあり、自動更新サブスクリプションに関してはデベロッパー向けのドキュメントがあります。ペイウォールをガイドラインに沿って設計することは、サブスクリプションの機能をリリースするための前提です。しかし、そのことと、ペイウォールが効果的であることは別の事象です。ガイドラインに沿っていたとしても、ペイウォールを前にしたユーザが好意的に受け取るとは限りません。

では、効果的なペイウォールとはどのようなものでしょうか？世界中のアプリの中から、サブスクリプションの機能があり、かつ売上も十分に立っている人気アプリを、リージョンとカテゴリを分散させて100個ピックアップし、実際のペイウォールを気合いと根性で分析しました。

本セッションでは、まず前提であるアプリ内課金が従うべきHuman Interface Guidelinesに軽く触れます。次に100個のアプリのペイウォールを以下の7つの観点から分析した結果とその考察を共有します。そして、それらを踏まえて実際のアプリに適用して得られた結果をお伝えします。最後に、ペイウォールを設計する際に重要となる心得および今日から使えるTips集を紹介します。

分析の7つの観点
（1） UIの構成要素
（2） 情報量・情報強度およびレイアウト
（3） コピーライティング
（4） 訴求ポイント
（5） 価格とプランの構成
（6） ペイウォールを表示するタイミング
（7） 無料の機能群と有料の機能群の比率

自転車のタイヤがパンクしたら、あなたはどうしますか？自転車屋に持っていって修理してもらうか、あるいは自分で直してしまうかもしれません。まさか自転車ごと買い替えるなんてことはしないですよね。では、iPhoneの画面が割れたら？あれ、買い替えるかも…？

こう考えてしまうのには訳があります。私たち消費者を修理から遠ざける要因が、ハードウェアの設計やソフトウェアの制限、知的財産権、さらにはマーケティングメッセージにまで、至るところに潜んでいるのです。例えば、AirPodsのネジがない設計は、修理の第一ステップである「デバイスを開ける」ことをほぼ不可能にしています。

修理の疎遠化は企業に大きな利益をもたらす一方で、消費者には経済的負担を、地球には環境負荷を与えています。こうした状況を打破するために、「修理する権利」を求める運動が、欧米やヨーロッパを中心に世界中で広がっています。もちろんAppleも例外ではありません。

本セッションでは、次のような内容をお話しします。

• なぜ修理が重要なのか？
• Apple製品から修理を遠ざけている要因たち
• 「修理する権利」を求める運動と、それを受けてAppleが変えたこと
• 日本で「修理する権利」を阻む壁: 技適
• 私たちiOSエンジニアにできること: Minimum deployment targetを再考する

修理がもたらすのは、金銭的・環境的価値だけではありません。修理は、デバイスの仕組みをより深く理解することに役立ち、自分が所有するモノを最大限に使いこなすことを可能にします。Appleプラットフォームでサービスを提供する者として、「修理する権利」について一緒に考えましょう。