トーク

あなたのアプリは、すべてのユーザーに届いていますか？

VoiceOverユーザーが見落とすボタン、Dynamic Typeに対応しないレイアウト、コントラスト不足で読みにくいテキスト…これらは多くのiOSアプリが抱える課題であり、せっかく開発したアプリが一部のユーザーにとって「存在しない」ものになってしまう原因です。アクセシビリティ対応は、もはや「あればいいもの」ではなく、すべてのiOSエンジニアが取り組むべき「必須要件」です。

このトークでは、手探りのアクセシビリティ対応に終止符を打ちます。AIツールが、VoiceOverの読み上げ順序からDynamic Typeの最適化、さらには複雑なアクセシビリティ問題の検出と改善提案まで、あなたの代わりに「考える」ことで、いかに開発プロセスを劇的に加速させるかを具体的にご紹介します。

AIは、あなたのアシスタントとして、アクセシビリティ機能の実装を強力に支援し、見落としがちな問題を洗い出し、改善策を提示してくれます。もはや専門家でなくとも、誰もが使いやすい、真に「すべてのユーザーに届く」iOSアプリを開発できる時代が到来しました。

アクセシビリティを「特別なタスク」ではなく、「当たり前の開発プロセス」に変革するAIの力を、あなたのアプリ開発に導入しませんか？

こんな経験ありませんか？
C言語ライブラリのエラーコードをSwift.Errorとして扱えたら楽なのに...
C言語関数を使う際に必要なUnsafeMutablePointerを間違えた操作をしてクラッシュしてしまった...

その不満、関数にattribute(属性)を足すだけで、解決できるかもしれません。
上記の例ではエラーコードの宣言箇所にattribute((ns_error_domain(CustomError))を追加するだけでSwiftではErrorに準拠したCustomErrorとしてモダンに扱えます。
また、Xcode26から導入される__counted_byを使えばコンパイラレベルでC言語関数を安全に呼び出せることを保証できるかもしれません。

本トークでは、そんなSwiftの特徴であるモダンな文法やメモリ安全性を、attributeやannotationをたった1行付与することでCファミリーAPIに持ち込むユースケースを解説・紹介します。

実際の現場での導入事例やXcode26で利用できる新たなアノテーション(counted_by)の使い方を紹介しながら、「書き換えゼロのセーフティ向上」と「API が一気に Swifty になる爽快感」をお届けします。

１つ何かをするだけで膨大な再描画処理が行われ、画面が固まってしまうアプリ

ミニプロジェクトを立ち上げて改善しよう！
ここから始まったプロジェクトがまっっったくミニじゃなくなった
・どうして再描画がこんなにも発生しているのか？　→　トリガーがわからない
・永遠に引きずり回されてるデータがあるから不要なのはなくそう　→　数が多すぎて本当にわからない
・テキストを入力してから表示されるまでの流れを見てみよう　→　Viewファイル内で迷子になる
・ちょいちょい意味がわからないコメントが書いてある、伝わるように書いてよ..　→　（数ヶ月後に）最後の気力で残してくれた先人のダイイングメッセージと気づく

→　仮に再描画抑えれたとしても、保守できない。もう作り直すしかないね

こんな感じで大きく流れが変わったプロジェクトの

1. 正しい仕様書がない
2. 既存コードでの問題点/原因（結局把握はしきれなかった）
3. 対策/改善方法
4. 壮絶なリアーキテクチャ
5. こんなところまで良くなったね！本当に頑張った！ ダイイングメッセージもありがとう！

みたいな話

私たちの運用するアプリは、ファーストリリースから8年経ちました。リリース当初はWebViewを主体としたガワネイティブで開発されていました。しかし、ユーザー層の多様化（地下街のレストランや工場で勤務される方、最低限のスペックの社用端末を利用される方など）に伴い、通信環境が不安定な状況でのパフォーマンス課題が顕在化しました。特に、複雑なUIを持つ画面におけるもたつきやカクつきが、ユーザー体験を損ねているという課題に直面しました。

この課題を解決するため、そのような複雑な画面をガワアプリからSwiftUIに移行する計画を開始しました。
本セッションでは、その背景、技術選定、そして実現までの道のりをご紹介します。

• ゴール設定の策定基準について
• 長期間の開発が必要なリプレイスプロジェクトをどう社内に伝えたか
• 仕様やデザインの見直しはどこまで行ったか
• SwiftUIを主軸にすることで得られた開発・UIデザイン上の知見
• WebViewから移行する上で気をつけるべきこと
• 結果、どれだけパフォーマンスが改善されたか

複雑な画面のSwiftUI移行を検討されている方や、そのプロセスに関心のある方にとって実践的な学びとなれば幸いです。

従来、iOSアプリに翻訳機能を組み込む際は、Google翻訳やAmazon Translateなどの外部APIに頼るしかありませんでした。これにより、従量課金・通信依存・オフライン非対応といった課題がつきまとっていました。

そんな中、iOS 17.4以降で登場した「Translationフレームワーク」は、Apple純正のオンデバイス翻訳モデルを活用することで、ネットワーク接続なし・高速・回数制限なしという理想的な翻訳体験を実現できます。

本トークでは、私がこのTranslationフレームワークをAVSpeechSynthesizerと組み合わせて開発した「喋った内容をオフラインでもリアルタイム翻訳するアプリ」を題材に、以下の実践的な実装ノウハウをお話しします。

• translationPresentationによる標準UIの制約と可能性
• SwiftUIのViewに依存するTranslationSessionをロジックに組み込む活用法
• AVSpeechSynthesizerとの組み合わせによる音声認識→翻訳→読み上げのフロー
• 翻訳モデルの自動削除問題と対処法（ストレージ管理）
• App IntentsやWidgetなど、アプリ外での応用可能性

また、実際に開発したアプリのデモを通じて、喋った内容がリアルタイムに翻訳・発話される様子をご覧いただきます。
このトークを通して、「どんな環境であろうとも瞬時に翻訳される体験」の実装方法を学ぶことで、みなさんのアプリにオンデバイス翻訳を導入する選択肢を広げていただければ幸いです。

楽天グループ株式会社が運営する「楽天リーベイツ」のiOSアプリは、2025年で9周年を迎えました。

2020年当時、8年以上にわたり運用されてきたiOSアプリを1人で引き継ぎ、数ヶ月間メンテナンスされていなかったレガシーコードに立ち向かいながら、ビジネス要件への対応、A/Bテストの実施、ユーザー体験の最適化、そしてチーム立ち上げを少しずつ進めてきました。

今回は、Biz やデザインチームの担当者と交渉しながら、iOS開発者としてどう目標を立て、どう改善を進めたか、その考え方をシェアします。最後に、これからの展望もお話しします！

WWDC 2025で発表された 「Liquid Glass」 は、10年ぶりのデザイン大刷新です。本トークでは元UI/UXデザイナー出身のiOSエンジニアが、秋の正式リリース前の今、知っておくべきポイントを、技術とデザインの両面から解き明かします。

• なぜ今Liquid Glassなのか？: 初代iOSのスキューモーフィズムからiOS 7のフラットデザイン、そして今回のLiquid Glassへ。Appleの技術とともに進化してきたデザインの変遷を振り返り、Liquid Glass導入の背景やAppleのビジョンを考察します。
• Liquid Glassとは何か？: Liquid Glassは従来の“ガラス風UI”と何が違うのか？デザインと技術の融合によって生まれたLiquid Glassの本質に迫ります。
• UIコンポーネントの変更点: UIの基本要素が実際にどう変わったのか、アイコン・コントロール・ナビゲーションの変更点を解説します。
• Xcode 26での実装方法: .glassEffect() や .buttonStyle(.glass) などの新APIの具体的なコード例、レガシーUIへの対応手段について紹介します。
• 実際にベータ版を触ってみた印象: 私がベータ版iOS26を実際に使ってみて感じた印象や課題を率直に共有します。
• デザイナーとエンジニアが連携すべきポイント: UI刷新はデザイナーとエンジニアの共同作業なくして実現しません。HIGの読み解き方や、実装側が意識すべき「デザインの意図」についても解説します。

このセッションを通じて、参加者は、今押さえておくべきLiquid Glassの思想や実装方法を学ぶことができ、自アプリへの導入にすぐ活かせる実践知を持ち帰れます。

ターゲット
・アーキテクチャの歴史を復習したい人
・最近iOS,Androidに触れ、昔の歴史を加味してアーキテクチャを理解したい人

概要
参加者の中には最近iOSエンジニアになった方や学生の方々も多いのではないでしょうか。
そんな方々に向けた、今までの歴史を振り返り、アーキテクチャの理解度を上げるためのセッションです。
初期からのアーキテクチャの主要な部分をiOS,Android横断で遡り、現状のTCA,MVVMなどの思想の分かれ方の理解を深めます。

詳細↓

テーマ理由
・宣言的UI普及により、アーキテクチャが転換期であるため
・他の方のセッションで最先端のアーキテクチャ考察があると考え、前提となるセッションがあった方が良いと考えたため。

初期（2008-2012）
iOS
・MVCが標準
・UIViewControllerが中心
・"Massive View Controller"問題の兆候
・デリゲートパターン
Android
・Activity中心
・"God Activity"問題の始まり
・Fragmentという概念の導入

パターンの確立期（2013-2017）
iOS
・MVVMパターンの普及
・ReactiveCocoa/RxSwift
・VIPER
・Swift登場
Android
・MVP推奨
・Architecture Blueprints
・Architecture Components発表
共通
・MVP、MVVM、Clean Architecture、Redux普及

宣言的UI時代（2018-2024）
iOS
・SwiftUI
・Combine
・MVVM
・TCA
Android
・Jetpack Compose
・Single Activity
・Navigation Component

実際の企業の採用状況
・9月時点の情報

iOSアプリ開発者の皆さん、デバッグとパフォーマンス最適化に費やす膨大な時間にうんざりしていませんか？

原因不明のクラッシュ、もたつくUI、そして悪夢のようなメモリリーク。これらは私たちの貴重な開発時間を容赦なく蝕み、リリースを遅らせ、ユーザーエクスペリエンスを低下させます。しかし、もうその苦しみは終わりです。

このトークでは、Xcodeに頼りきりだったデバッグと最適化の常識を覆します。CursorやClaude Codeのような汎用AIツールが、あなたの想像をはるかに超える形で、これらの複雑なタスクをどのように劇的に支援するのか、具体的な事例を交えてご紹介します。

AIは単なるコード補完ツールではありません。まるで熟練のベテランエンジニアのように、エラーの原因を光速で特定し、パフォーマンスのボトルネックをピンポイントで突き止め、手ごわいメモリリークさえも瞬時に検出する力を秘めています。

AIの力を借りて、あなたのiOSアプリ開発を次のレベルへ引き上げましょう。
無駄な時間を減らし、本当にクリエイティブな仕事に集中できる未来が、今、ここにあります。

日常生活の中でスマートスピーカーのように、声だけで家電を操作する体験が当たり前になりつつあります。音声操作体験に求められる期待値も徐々に上がってきています。

iOSではSpeech Frameworkを使うことでリアルタイム音声認識を実現することができ、AVSpeechSynthesizerを使うことで読み上げを実現することができますが、実環境下で運用するためには様々な課題に直面することになります。
例えば、iPadにケースを装着したことによる認識精度の低下、Speech Frameworkが対応していないWake Word検出の実現、読み上げ時の利用可能な音声の制約、OSのバージョンによる制約, プライバシーの考慮などの課題に直面します。

このトークでは、Speech Frameworkを使って音声だけで家電を操作する機能をリリース, 運用した経験をもとに、AVAudioEngine, Speech Framework を使った音声認識の基本から、上述したような実環境下で直面する課題の解決方法までを詳しく解説します。

WWDC25 と同時に映画『F1: The Movie』の予告編「Haptic Trailer」が公開され、 iPhone の Apple TV+ アプリで見ると映像に合わせてデバイスが振動し、まるでF1ドライバーになったかのような感覚を体験できると話題になりました。振動による力強いエンジンの再現には、多くの方が驚かれたことでしょう。

iOSエンジニアの皆さんなら、「この機能はどのように実現されているのか？」と興味を持たれたのではないでしょうか。調査の結果、新しい体験と感じられたこれは、1st PartyであるAppleにしかできない事...ではなく、我々3rd Party開発者にも利用可能な AVFoundation や Core Haptics のAPIで実現できることが分かりました。プラットフォームの能力を理解し、最大限に活用することは、優れたユーザー体験の創造において非常に重要です。紐解いていく過程も含めて詳細を共有しますので、皆さんが動画にプラスアルファをして素晴らしい体験を作るための参考になればと思います。

Claude CodeやCursor、そしてXcode 26 ― iOS開発におけるAIアシストの選択肢は多くありますが、それぞれ一長一短あり、決定版はまだありません。とりわけ基盤をAppleが握るこの領域では、ほかの分野に比べて発展途上な部分がまだ目立ちます。

足りないなら作ろう ― そこで鍵となるのが、AIと外部ツールを連携させるオープンプロトコル MCP です。本セッションでは、私たちiOSエンジニアの日々の「めんどくさい」をショートカットする開発オートメーションをMCPで実現する道筋を示します。まず最小構成のSwift製MCPサーバー実装を通して、プロトコルの基礎を把握。続いてFigma MCPを例にデザイン仕様を自然言語で取得し、Accessibility API経由でXcodeやiOSシミュレーターをAIに遠隔操作させる仕組みを解説します。コード生成だけでなくビルド、テスト、UI遷移確認までを対話形式で一気通貫に繋げることで、開発フローは無限に拡張可能になります。MCPはCLIもGUIもクラウドAPIもJSON-RPCで束ねるため、社内ツールやレガシースクリプトも一関数のように呼び出せ、次世代SDKが登場しても待たずに取り込めます。

MCPは「自分だけのショートカットキー」を対話ベースで実現する仕組みです。AIに「昨日のクラッシュを再現して」「最新デザインに合わせてUIテストを更新して」と頼むだけでスクリプトが自動生成・実行され、結果レポートが返ってきます。ワークフローを設計する楽しさを味わえるのが最大の魅力。聴講後には、あなたのMac上で動く小さなサーバーが巨大な開発環境を操り、自分専用AIアシスタントの成長を実感できるでしょう。

　 ∧,,∧
　(；`・ω・）　　｡･ﾟ･⌒） カレンダー作るよ！！
　/　　 ｏ━ヽニニフ))
　しー-Ｊ

[話すこと]

• UICalendarView/DatePickerの特徴と使いどころ
• SwiftUIのカレンダーライブラリが無い？無いなら自作すればいいじゃない！
• 日本のカレンダーならではの話 〜曜日はどうやって取得する？祝日は？〜
• TabView + GridでカレンダーUI作るよ！！

Live Activity は、ロック画面や Dynamic Island にリアルタイム情報を表示できる機能です。iOS 16 で登場してから毎年改良が進み、対応デバイスも拡大してきました。この機能を使用することで、ロック画面に自由な表示を行うことができるので、うまく活用することができればユーザーの利用率拡大を図ることができます。

Live Activity はリアルタイムに動くシステムのため、考慮する事項はクライアントからバックエンド、通知サーバーに至るまで多岐に渡ります。Live Activity はその考慮事項の多さから、安定的に運用するために様々な対応が必要となります。

Live Activity を最小コストで安全にリリースするために必要な下記のトピックなどを紹介します。

Live Activity の開始方法・更新方法の選択
Live Activity 利用状況の監視
Live Activity を表示している際のアプリライフサイクルの変化

この発表を聞けば皆さんのアプリにも Live Activity を実践的に導入していく方法を学ぶことができます。

SwiftUIのモダンで宣言的なAPIは、UI実装を効率的かつ楽しいものにしてくれます。
一方で、iOSのメジャーバージョンごとの機能差異も多く、今までUIKitで実現されていた複雑なUIを同じように実装するためには工夫が求められる場合もあります。

このセッションでは、約10年にわたって開発されてきたアプリの中の様々なUIをSwiftUIに移行してきた経験から、複雑なUIをどうSwiftUIで実現するか・SwiftUIで実現できないUIの回避方法など、大規模かつ多くの世代のiOSをサポートするアプリで使っている具体的・実践的なノウハウをご紹介します。

• SwiftUIの得意なところ・苦手なところ
• iOS 15やiOS 16など、過去のiOSバージョンもサポートするためのポイント
• UIKitの使いどころ、UIKitとSwiftUIの連携パターン
• ニッチなSwiftUI APIの活用事例

SwiftUIをメインで使っているプロダクトでは、デザイナーやPdMとのやり取りで誰もがこんな経験をしたことがあるのではないでしょうか。

👩‍💼： 「この機能、〇〇アプリみたいなUIにしてください！」
🧑‍💻： 「了解です〜！」
（実装中・・・）
🧑‍💻： 「iOS 15や16だとちょっと上手く動かないんですよね…」
👩‍💼： 「えっ、〇〇アプリではできてますよ？」
🧑‍💻： 「ちょっとやり方変えてみますね…（仕方ない、UIKitを使うか…）」

SwiftUIは年々進化していて、新しい表現力やインタラクションを作り出せる強力なツールです。しかし、多くの有名アプリではまだUIKitが使われており、デザイナーやPdMがそれらを参考にすることも多いです。その結果、SwiftUIだけでは再現が難しいUI表現を求められる場面がよくあります。

開発者は、UIViewRepresentableやUIViewControllerRepresentableを使ってUIKitを取り入れる選択を迫られますが、これによりSwiftUI本来の宣言的なスタイルや一貫した状態管理が崩れ、保守性や可読性に新たな課題が生まれます。

このLTでは、実際に「SwiftUIだけでは実装できなかったUI」や、「UIKitを使わざるを得なかったシーン」を例に挙げつつ、そのときに考えた工夫やトレードオフを共有します。たとえば、カスタムトランジションやインタラクティブなスクロール、特殊なジェスチャー処理など、現場でぶつかったリアルな壁を紹介します。

私たちのチームでは、iOS・Androidモバイルアプリの実装共通化のため、2020年頃からKotlin Multiplatform（KMP）の検証を開始し、段階的に導入を進めてきました。現在では、サービスの中心となるコンテンツを視聴する画面の多くの実装がKMPによって共通化されている状態になっています。

マルチプラットフォーム開発の選択肢としてKMPが注目される一方で、長期にわたり大規模なサービスで運用してきた事例は多くありません。本セッションでは、私たちのチームにおけるKMP導入と運用の約5年間を振り返り、以下のようなトピックについて具体的な事例を赤裸々にご紹介します。

• KMP導入の背景とプロセス、直面した課題
• チームの実装効率は向上した？
• UI、ロジック、通信…どこまで共通化するべき？
• KMPを活用しながら、Swift 6の新機能やSwiftUIの導入をどのように進めたか
• KMPは他のチームや開発者へおすすめできる？

KMPの導入を検討している方・実際に使われている方はもちろん、アプリ開発へのマルチプラットフォーム技術の導入に関心のある全ての方の参考になるように、具体的で実践的な事例をお話しします。

Swift Evolutionを眺めているうちに、「言語ってどうやって作られてるんだろう？」と気になり、試しにSwiftでシンプルな言語を作ってみました。

今はAIがコードを書く時代になってきていますが、依然として言語の仕組みを理解し、自ら構造を設計できる力は変わらず重要だと感じています。

このセッションでは、Swiftで簡易的なプログラミング言語を自作したプロセスを、字句解析、構文解析、意味解析という基本ステップに沿って紹介します。
字句解析では、Swiftのenumを使ってトークンの種類を定義し、文字列を順に読み取って意味のある単位に分解する処理を組み立てました。構文解析では、indirect enumとstructで抽象構文木（AST）を表現し、演算や代入といった構文を再帰的に解析することで実現しました。意味解析では、Dictionaryを活用して変数名と型情報を管理し、スコープごとに構造を持たせながら、型の整合性や未定義変数の検出といったチェックを行う仕組みを構築しました。

発表の最後には、自作したミニ言語も軽くお見せします。素朴な言語ですが、作る過程で得られる学びは深く、きっとコードの書き方や読み方が変わるはずです。

Swift Evolutionは遠く見えて、実は足元から始められるのかもしれません。
一緒にその第一歩を踏み出してみませんか？

日々の開発でデザイナーさんとの会話の中で「HIG的には〜」と口にすることはあっても、果たしてその意味を深く理解できているでしょうか。HIG（Human Interface Guidelines）は、単なるデザインガイドラインではなく、Appleが長年培ってきたユーザー体験への思想と普遍的な原則が凝縮されたものです。

本セッションでは、HIGの核心となる原則に触れ、なぜHIGを遵守すべきなのか、なぜ守ると良いのかということを今一度考えて行きたいと思います。
いくつかの標準コンポーネントを例に、その裏にある意図や思想について触れ、日頃使っているものがどういった思想から形作られたのかを一通り理解した上で遵守することができれば、HIGに対する解像度を一段階上げることができると考えています。

本セッションを通じて、HIGに対する解像度を一段階引き上げ、デザイナーとの円滑な連携はもちろん、自信を持って「ユーザーにとって本当に良い」UI/UXを考えるきっかけになれば幸いです。

アプリを多言語対応する際の最も面倒な作業はみなさんご存知ですか？
もちろんそうです。AppStore用のスクショの作成です！！！

アプリの画面を撮影してFigmaなどで上部に文章を加えるのがよくあるパターンですが、言語ごとにiPhone/iPad用のスクショを作成するのは単調な作業で全く面白くないです。
「でも多言語対応って言っても数言語でしょ？」と思うかもしれませんが、私が個人でリリースしているアプリでは16言語対応しています。
16言語分の各画面のスクショと言語ごとの文章を当てはめるのはただの苦行です。

このLTでは、そんな面倒な16言語分のスクショ作成を加速させた方法を紹介します。

• 各言語/地域ごとの撮影の自動化
• Figmaを活用した言語ごとの文章やスタイル設定の簡略化

実際、対応した言語圏のユーザからのinstall数は多いです。このLTを通じて皆さんの多言語対応の1つの壁を打ち砕きましょう！