トーク

私自身がこの数年主務としてきた領域はAndroidアプリ開発です。
「Androidアプリ開発のことなら設計からパフォーマンス改善まで何でもござれ！」と言える自負はある程度あれど、iOS開発の議論となると借りてきた猫のようにしおらしくせざるを得ないという場面も多々あります。
そんな私に、iOSアプリ開発者が多数を占めるチームでモバイルアプリ開発のテックリードを務めることはできるのでしょうか？iOS開発未経験というハンディキャップを背負いながら、いかにしてこの重要な役割を果たしていったのか、そのリアルな奮闘と学びを共有します。

テックリードという立場は、多岐にわたる技術課題に対しメンバーと共に立ち向かう深い知識が求められる職能だと解釈しています。このセッションでは開発環境やビルドシステムの違い、Jetpack Composeとは異なるUIKit/SwiftUIの思想など、Androidエンジニアにとって大きなギャップとなる具体的なポイントに焦点を当てます。 そして、私がどのようにこれらのギャップを効率的にキャッチアップし、チームメンバーと効果的なコミュニケーションを図り、さらには技術的な意思決定を行うための知識を身につけたか、そのリアルな体験談をお伝えします。

iOS開発にこれから入門しようというAndroidエンジニアの皆さんにとってはプラットフォーム間の技術的なギャップをいかに乗り越えるかのヒントを、
そしてiOS開発者の皆さんにはAndroidエンジニアから見た世界を知っていただき、ご自身の開発スタイルを客観的に見つめ直すきっかけや、Androidエンジニアとの協業における相互理解を深める視点を提供できるようなセッションを目指します。

visionOS 26 では、iPhone／iPad のホーム画面でおなじみのウィジェットを、壁に貼る置き時計のように、机に置く写真立てのように、現実空間へ自在に配置できます。

本講演では、既存の iOSウィジェットを visionOS 26 へ移植する際の注意点と移行手順を、ソースコードと合わせて詳しく解説します。

まず visionOS におけるウィジェットの基礎を整理し、インタラクション対応の WidgetKit、壁掛け（elevated）／埋め込み（recessed）という二つのマウントスタイルの違いを説明します。
更に、WWDC 25の発表時に気になった「ウィジェットはいくつまで配置できるのか？」「どれほど現実世界に自然に溶け込むのか？」といった疑問についても、調査結果をデモ動画を交えて紹介します。

既存のiOSウィジェットをvisionOSに拡張する際に、利用可能なウィジェット種別の制限や背景色を変更した場合の影響、シミュレーターと実機での挙動の差異など、開発時に押さえておくべきポイントを解説します。
Apple Vision Pro を持っていなくても実践可能な内容となっています。

メルカリでは過去、ネイティブからReact Native、Flutterに至るまで、多岐にわたる方針でモバイルアプリ開発を行ってきました。それらの経験も踏まえ、今回の新規アプリ開発では、既存リポジトリをモノレポとして再定義し、その中で新たなネイティブアプリを開発する戦略を採用しました。

大規模な単一レポジトリ環境で複数のモバイルアプリを開発・運用することは、コードの一元管理、実装の再利用による開発速度の向上、ビルドシステムや周辺ツールの統一といった様々なメリットを享受できます。一方で、複数アプリでの利用を前提としたモジュール再設計の必要性や、各モジュールの影響範囲の拡大、技術的・組織的な依存関係がボトルネック化するといった問題も存在します。

もちろん、こういったメリット・デメリットは、既存のコードベース、目標の時間軸、組織構造、メンバー構成といった様々な変数によって、その性質や度合いは変化します。本トークでは、この点を踏まえつつ、モノレポへの移行からその後のアプリ開発に至るまでの実態を、事例と共に紹介します。主なトピックは以下の通りです。

• 既存のリポジトリ環境から移行するまでの具体的なステップ、Bazelを用いた設計、その過程で直面した課題
• 再利用性と独立性を両立させるモジュール設計の勘所と、実際の再設計事例
• アーキテクチャや個々の実装パターン、技術の選定方針と判断基準（例: swiftui-atom-properties, gRPC, etc.）
• 開発体制および組織面におけるチャレンジ

私たちの戦略と意思決定の過程を一つの実践例として共有します。

Vibe Cooking は、"ノリで料理する" がコンセプトのアプリです。ユーザーが複数のレシピを選ぶと、AI がそれらを組み合わせて一つの新しいレシピを提案し、料理初心者でも効率的に複数の料理を作れるようにサポートします。

これまで Vibe Cooking のレシピ構築機能は、サードパーティ製の LLM を利用して実現していました。今回は、WWDC25 で発表された Foundation Models Framework を活用し、この機能をオンデバイスで実現することに挑戦します。

このトークでは、その挑戦の過程をみなさまと共有し、Foundation Models Framework を用いてどこまで実用的な機能が実現できるのか、具体的な事例を通してその可能性と限界を探ります。Foundation Models Framework の実際の活用イメージを深め、皆様の iOS アプリ開発における選択肢を広げる一助となれば幸いです。

このトークでお話しすること

• Vibe Cooking の概要と従来のレシピ構築方法: コンセプトと、これまでの実装について説明します。
• Foundation Models Framework の基礎: 基本的な概念や、オンデバイスでのモデル実行のメリットについて解説します。
• Foundation Models Framework を用いたレシピ構築の実装: どのようにフレームワークを組み込み、レシピ構築を実現したのか、具体的なコード例や工夫を交えて紹介します。
• サードパーティ製 LLM との比較: 気づいた違い、パフォーマンス、制約、そしてそれぞれの利点と欠点について深掘りします。

複数のiOSアプリを複数人で運用する組織では、共通機能の管理、状態の一貫性、チーム間の開発効率が重要な課題となります。本セッションでは、The Composable Architecture（TCA）を用いた 大規模開発の実例を通じて、これらの課題を体系的に解決する手法を紹介します。

紹介する主要技術パターン：

• 階層的Routerアーキテクチャ → 複雑なナビゲーションを型安全に管理し、画面遷移のバグを大幅削減
• RequestReducerパターン → 非同期処理のボイラープレートを90%削減し、開発効率を向上
• Sharing API活用 → アプリ間の状態共有を一元化し、データ不整合を防止
• リアルタイムデータ統合 → TCA Effectsとの連携により、複雑な状態更新を予測可能に制御

これらの技術が相互に連携することで、従来は困難だった大規模アプリの状態管理が劇的に改善されます。
実際のコード例、包括的なテスト戦略、運用で得られた具体的な成果指標も共有し、TCAの実用性を実証します。

TCA で大規模開発の課題を解決したい方必見のセッションです。

想定視聴者: TCAの基礎知識があり、実際のプロダクション導入を検討している中級〜iOSエンジニア、複数アプリの状態管理課題を抱えるチーム

Gunosyでは、複数のモバイルアプリを少人数のチームで開発・運用しています。
以前はアプリごとに専任を置く体制を取っていましたが、事業やチームのフェーズが進むにつれて、リソース調整や意思決定の硬直化、属人化のリスクといった課題が顕在化してきました。

たとえば、共通モジュールに対する責任範囲が曖昧であったり、特定のプロダクトに負荷が集中しても他のメンバーが支援しにくかったり、類似の施策を各プロダクトで個別に設計・実装することで、二重のコストが発生するような場面も増えていきました。
こうした課題に対応するため、私たちはチーム体制を柔軟かつ安定的に回し続けられるものへと整えていく必要がありました。

プロダクト横断で関与できる「ゆるい主担当・副担当制」、レビューや仕様共有の仕組み、会議体の統合、そしてマネージャーが進行役から支援役へと変わることによる構造的な変化など、一つひとつの現実的な試行錯誤の積み重ねが、いまのチームを支えています。

本トークでは、こうした取り組みのプロセスと背景を、等身大の視点でご紹介します。

「複数アプリ × 少人数チーム」という制約の中で、運用のしなやかさや持続性を模索している方にとって、共感と具体的なヒントをお持ち帰りいただける内容です。
マネージャーに限らず、チームの一員として仕様共有や体制づくりに関わるすべての方にとって、有用な視点をお届けします。

地図アプリのユーザーエクスペリエンス（UX）は、リアルタイムでのインタラクティブな操作、例えばピンの操作や動的な図形描画により大きく向上します。
しかし、その裏側には複雑なロジックの扱いや幾何学的な計算が不可欠であり、パフォーマンスとの両立は開発者を悩ませる課題です。

ここで活きるのが、生成AIと数学分野のアルゴリズム実装の相性の良さです。
生成AIは、その高い実装コストからこれまで試行錯誤が難しかった複雑なアルゴリズムを、AIの補助を受けて手軽に試行できる環境を提供します。

本セッションでは、生成AIを活用した新たな地図アプリケーションの幾何学アルゴリズムの開発手法を紹介し、パフォーマンスを維持しつつリッチなUXを実現する具体的な事例を解説します。
具体的には、インタラクティブなピンの押し出し制御や、動的なポリゴン合成などの実装を取り上げます。

• 地図外のViewへのオーバーレイ描画: 地図上の座標を画面上の座標へ正確に写像変換する技術
• 禁止領域からのインタラクティブなピンの押し出し: ポリゴン上の最近傍点を効率的に導出し、ピンを領域外へ配置するアルゴリズム
• 動的なポリゴン合成: Graham's scanを用いたConvex Hull（凸包）の計算による、複雑な図形の単純化と合成

また、これらのユースケースの解説に加え、生成AIを活用して高速に幾何学アルゴリズムを実装し、選定、比較、そしてパフォーマンスチューニングを行う具体的なアプローチを採用を見送った幾何学アルゴリズムや、その理由とともに紹介します。

このセッションを通じて、地図アプリケーション開発における幾何学アルゴリズム探求の手法と、生成AIがもたらす開発効率の向上、
そしてこだわり抜いた滑らかな地図UX実現のための実践的な知見を持ち帰ることができます！

Metal は Apple が提供する高性能・低レベルなグラフィックス API です。
開発者が GPU を直接制御し、複雑な描画処理を柔軟に実装できるのが大きな特徴ですが、「シェーダー言語や GPU の仕組みを知らないと使えないのでは？」と感じる方も多いかもしれません。実際、Metal は専門的で難しそうという印象を持たれがちです。

近年では SwiftUI でも簡単にシェーダー効果を利用できるようになってきており、Metal は以前より身近な存在になりつつあります。とはいえ、GPU が実際にどう動作し、どんな流れで画面が描かれているのかを理解せずに、なんとなく「雰囲気」で使ってしまっているケースも少なくありません。

このセッションでは、Metal に苦手意識を持っている開発者の方々に向けて、Metal がもはや「一部の専門家だけのツール」ではなく、iOS や macOS アプリでも実践的に使える現実的なレンダリング手段であることをお伝えします。

Metal の基本的なレンダリングパイプラインの流れを丁寧に解説し、最新の Metal 4 を活用した効率的な設計方法についても学んでいきます

セッション構成

1. Metalとは
2. 非ゲームアプリで Metal はどのように活用できるか？
3. レンダリングのための Metal パイプラインを理解する
4. 最新の Metal 4 に基づく効率的なレンダリングパイプラインの構築方法

「またCIが落ちた...」「テスト完了まであと25分...」このような経験はありませんか？私たちのiOSチームでは、ちょっとしたUIの修正でも全テストスイートの実行に30分以上かかり、開発者の集中力とモチベーションを奪っていました。1日に何度もPRを出すアクティブな開発では、この待ち時間が積み重なり、チーム全体の生産性を大きく損なっていたのです。

この課題を解決するため、私たちは「Selective Test」という仕組みを使いました、「変更した部分に関係するテストだけを実行する」というアプローチです。たとえば、ログイン画面のボタンの色を変更した場合、決済機能のテストまで実行する必要はありません。

仕組みはこうです。まず、プロジェクト内のすべてのファイルの「つながり」を把握します。AというファイルがBを使い、BがCを使っているという関係性を地図のように可視化。次に、変更されたファイルから、その地図をたどって影響を受ける部分を特定し、関連するテストだけを選び出します。

実装では壁にぶつかりました。最大の課題は、Swiftの「見えない依存関係」でした。プロトコルやextensionを多用するiOS開発では、静的解析だけでは不十分で、必要なテストが実行されない「見
逃し」が発生しました。私たちは実行時の情報も組み合わせることで、この問題を解決しました。

本セッションは、日々のCI待ち時間にフラストレーションを感じているiOSエンジニア、チームの開発効率を改善したいテックリード、大規模プロジェクトでのテスト戦略に悩んでいる方々に向けた内容です。セッション終了後、あなたは自分のプロジェクトでSelective Testを導入するための具体的な手順と、避けるべき落とし穴を理解し、明日から実践できる知識を持ち帰ることができます。

iOSDC Japan 2023で私たちが発表した「SVVS」。あれから2年、Swiftが大きく進化する中で、私たちの実装もまた大きな進化を遂げました。

本セッションではその続編として、最新のSwiftを活用した「SVVS実装戦略」をお届けします。その進化の過程で、私たちは以下の課題と向き合ってきました。

• アプリ全体で有効なものと、ログイン中にのみ有効なもののライフサイクル設計
• CombineからObservationへの移行とその影響
• DIを用いたUIロジックの単体テスト手法

これらの課題に対する私たちのアプローチを、具体的なコードの変遷と共にお見せします。

近年、セキュリティインシデントの報道が増加し、ユーザーのセキュリティ意識はかつてなく高まっています。特にリスト型攻撃の脅威から、メールアドレスとパスワードの組み合わせに依存しない認証手段は、今や当たり前に求められるようになりました。そして、万が一の流出やアカウント乗っ取りが発生した際の最終防衛線として、多要素認証（MFA）の重要性が再認識されています。

Firebase Authenticationが公式に提供する電話番号(SMS)によるMFAは強力ですが、SMS認証の運用コスト、ユーザーの電話番号提供への抵抗感、UX低下といった課題感を完全に解決しません。
本セッションでは、この課題を乗り越えるため、Firebaseの複数認証方法を「2要素目」として組み合わせ、柔軟なMFAを実装する手法を解説します。これにより、ユーザーは認証方法を自由に選択でき、開発者はコストを抑えつつ高いUXを提供できます。

この実装には、ドキュメントにない挙動や落とし穴が多く存在します。本セッションでは、私が検証・解明したFirebase Authの複雑な内部挙動と未公開仕様を紐解き、具体的な解決策をコードと共に提示します。

• 認証解除後も、なぜか認証が成功するケース
• 特定の認証情報更新時に起こる強制ログアウトとその対策
• メールアドレス変更時に、ユーザーに最大3回の認証を強いる挙動の解決

対象聴衆

• Firebase Authentication利用者/検討中のiOS開発者
• セキュリティ強化やUXバランスに悩む方
• 実践的な活用法を求める方

本セッションを通じ、皆さんのアプリに「ユーザー中心」の堅牢な認証システムを自信を持って導入できるようになることを目指します。

iOS 10でSFSpeechRecognizerが登場して9年。
従来の音声認識技術は、短時間音声処理に限られ、サーバー依存による遅延や言語設定の煩雑さなど、本格的なアプリ開発には多くの制約がありました。

iOS 26で登場するSpeechAnalyzerは、その制約を根本から解決する革新的なAPIです。
長時間音声や遠距離録音に対応し、完全オンデバイス処理により瞬時の応答を実現。
リアルタイム転写機能により、ユーザーが話すそばからテキストが表示される魔法のような体験を提供します。

本セッションでは、従来技術の限界を振り返りながら、SpeechAnalyzerの革新ポイントを解説。
非同期処理によりUI操作を妨げない設計、音声の時刻情報を活用した正確なテキスト同期、そして自動モデル管理により開発者の負担を大幅軽減する仕組みなど、実装者が知るべき技術的メリットをお伝えします。
デモでは、絵本読み聞かせアプリを題材に、転写設定・モデル準備・結果処理の3ステップセットアップから、CMTimeRangeを活用した音声再生と同期するテキストハイライト機能まで実演。
Apple Intelligence連携による自動タイトル生成も披露します。
オンデバイス処理により、会議録音は通信環境を気にせず、講義録音は長時間でも安定動作、ライブ配信では遅延なく字幕生成が可能となり、これまで諦めていたアイデアが現実のものとなる開発手法をご紹介します。

WWDC25 で公開された Foundation Models framework により、ついに iOS 公式のオンデバイス LLM へ直接アクセスできる時代が到来しました 。
本セッションでは Apple​純正モデル（Apple Intelligence 3B）と、MLX-Swift／MLC-LLM／llama.cpp など OSS ベースの手段を横並びで比較し、iPhone 16 Pro 相当の端末で “どこまで動くか・どう組み込むか” を具体的に解説します。

「オフライン AI チャット」「リアルタイム文章要約」「リアルタイム文章校正」 を ひとつの SwiftUI アプリに統合しながら、３つのオンデバイス LLM を 同じプロンプト・同じ iPhone でベンチマークします。

比較軸は下記 5 点です。

1. 導入工数とビルド手順（Swift Package／Core ML 変換／モデル配布方法）
2. モデルサイズ／RAM 使用量
3. 推論レイテンシ
4. バッテリー消費
5. ライセンスと運用

Apple Intelligence 3B がもたらす省電力性と高レベル API の手軽さ、
llama.cpp-Swift の自由度と暗黙の落とし穴、
MLC-LLM の柔軟性と量子化チューニングの難しさ――
それぞれを可視化し、実装方法も併せて紹介します。

オフラインでも瞬時に動き、個人情報をクラウドへ送らず、運用コストを抑えられる オンデバイス LLM は iOS アプリの新たな武器になりつつあります。

本セッションを通じて、より実用的なオンデバイス LLM を活用した iOS アプリ開発 のイメージを掴めます。具体的なユースケースと実装手順を知ることで、新規アプリの着想や既存アプリ進化のきっかけとなることを目指します。

我が家には2歳の猫がいます。とても可愛く、ときに予測不能で愛くるしい動きをします。そんな一瞬を撮影するのは至難の業ですが、DockKitがこれを可能にします。

DockKitは、iPhoneカメラとDockKit対応デバイスを連携させて被写体を自動追尾するAppleのフレームワークです。WWDC 2023で発表され、昨年対応デバイスが発売されました。iPhone標準搭載のカメラアプリもDockKitに対応しており、DockKit対応デバイスとiPhoneを連携することで人物を自動で検出しトラッキングすることが可能ですが、標準では人物のみに限定されます。

しかし、DockKitには豊富なAPIがあり、Vision frameworkとの相性も抜群です。VNRecognizeAnimalsRequestで猫を識別し、Core MLと連携することで、人物以外の高精度なトラッキングが実現できます！

本セッションでは、Vision frameworkで猫の特徴を捉え、DockKitと連携させる具体的な実装方法と、DockKitをより高度に使いこなすテクニックについて解説します。デモでは我が家の猫が出演する動作映像をお見せし、iOSDC史上最高の癒しも提供予定です。

本セッションを通じて、これらのフレームワークをみなさんのアプリ開発や身近な課題の解決にも活かせるようになるかもしれません。

本セッションでは、Swift-DocCとAI agentの活用によって、ドキュメントを設計・実装・運用の全プロセスの中心に据え、より柔軟で再現性の高い開発体験を実現する“ドキュメント駆動開発”のアプローチを共有します。

これまでドキュメントは、実装の後に作成される補足資料や説明書として捉えられることが多く、設計意図や仕様の認識ズレ、保守コストの増加など、さまざまな課題がありました。しかし、Swift-DocCの普及により、ソースコードと設計情報が密接に結びつき、チーム全体で設計や仕様を共通言語として扱える基盤が生まれています。さらにAI agentの登場によって、DocCを起点とした情報が実装・テスト・レビュー・運用まで幅広く自動化・補完される時代が始まっています。

このセッションでは、

• DocCによる設計・仕様の明文化
• 仕様整理・設計段階でDocCを作成（ドライバー部分は人間、実装はAI）
• AI agentによるコードやテスト、ドキュメント自動生成・補完
• CI/CDやプレビュー環境による継続的な品質維持と自動チェック

という“ドキュメント中心”のワークフローが、どのように現場を変えるかを解説します。

ドキュメントは従来、「保守やリリース直前になってようやく整備される存在」となってしまうことが少なくありませんでした。

これからは、ドキュメントを「設計・実装・運用すべてをつなぐ開発の核」として活用するための実践的な視点を、iOSエンジニアの皆さんと共有したいと考えています。

Webブラウザ操作の自動化ツール代表的なものの一つとしてSeleniumが挙げられます。
SeleniumはJava、JavaScript、Python、Ruby、.NET、Rustといった言語をサポートしており、高い汎用性を誇ります。
しかし、何かが足りません。そう、Swiftです。

本トークではSeleniumとそれが動かすWebDriverの仕組みについて解説し、SwiftでWebDriverを動かしてブラウザ操作を実現することを目指します。

Swiftでもブラウザ自動化の可能性を切り拓いていきましょう。

我々が作る iOS アプリと OS や他アプリの連携を実現するために App extensions という仕組みが Apple から提供されています
ですが多くのサービスでは iOS アプリと同時に Android アプリを提供しているケースが多く、アプリ内の UI 一つとっても「これはAndroid はどうやったら提供できるだろう？」という疑問を持つことも多いでしょう
App extensions を使った機能を提供する際も Android で似た機能はないのか、サービスとして OS が違ったとしても統一性のある UX を提供出来るかどうかを考えることになるでしょう
勿論似た機能が提供されていることも多く、例えば Siri との連携を提供する Intents に対し Android には Google アシスタント連携を提供する App Actions が存在します

そこで今回は iOS で提供できる AppExtension を振り返りつつ、 併せて Android においてそれと近しい機能がないか、どのような違いがあるのかについて話そうと思います
中でも特に Intents など AI アシスタント絡みで直近の注目度が高そうなもの、 Widget など iOS では比較的新し目だが Android では昔からあったものに着目して行こうと思います
Widget の更新思想一つとっても、明確に時間間隔が指定可能な Android と、バジェットで管理されるため厳密には指定不可能な iOS という違いがあり、出来る出来ないの差分がありえます
この「差分」を理解することこそが、両プラットフォームで一貫したUXを提供するための鍵となります

このトークを通じて、単なる機能比較に留まらないサービス全体の価値を最大化するための OS 横断的な設計についてお話できればと思います

▼ 概要
私たちは「あたらしい旅行を、デザインする。」をミッションに旅行アプリ「NEWT」を日々開発しています。
NEWTはリリースから3年が経ちました。今回は海外旅行に必ず必要な「航空券」に着目してみます。
国内外問わず移動手段として考えられる飛行機移動ですが、チケット忘れやデジタルチケットを当日にサイトにアクセスして焦ったりしたご経験はないでしょうか？
そんな中で航空券データをPassKitを用いてWalletに追加することでより一層トラブル回避の手段とできるのではないかと考えました。
また、航空券だけでなくPassKitをうまく利用することでさまざまな種別のカードやチケットをWalletに追加することができるので他の種別についても併せてご紹介します。

▼ 内容

• PassKitってなに？どんな種類があるの？
• 航空券を扱う場合に実装する内容
  • 証明書設定からpass.jsonの設定について
  • 実際に動かしてみた内容について
  • NFCを付加できる条件
• 実際に開発・運用する/しないを決める時の意思決定について

音声配信アプリのE2E自動テストでは、UIだけでは判断しづらい“聴く体験”をどう守るかという、他のアプリとは一味違った難しさがあります。
・音声が再生されていることを確認する方法
・今月の放送を指定する方法

音声配信アプリにおいて、リスナーに「聴く体験」を提供し続けるためには、どのようにテストを行うべきでしょうか？

本セッションでは、ノーコードでE2Eテストを実装できるMagicPodを用いて、音声再生の検証や動的なコンテンツ選択に取り組んだ事例をご紹介します。

再生ボタンの状態変化から“音が出たこと”を間接的に確認する方法や、「今月の放送」のように固定文言やIDに頼れない場面での要素特定の工夫など、音声配信アプリならではの課題とその突破法をお話しします。

このセッションを通して、以下のことを学ぶことができます。
・音声配信アプリにおけるE2E自動テストの特有の課題
・MagicPodの強みとその実践的な利用法
・MagicPodの限界とそれを補完する方法

Swift Concurrencyにおいても、非同期処理を同期制御したいケースがあります。たとえば非同期に複数のリクエストが同時に走るが、実行すべき処理は一度きりでよいという状況です。しかし、Swift ConcurrencyにはDispatchSemaphoreに相当する同期制御機能が用意されておらず、このような要件を満たすにはちょっとした工夫が求められます。

このトークではアクセストークンの更新処理をユースケースに取り上げて、複数の非同期リクエストが同時に更新を要求しても初回の更新処理だけAPIを呼び出し、またそのレスポンスを後続の処理に再利用して使い回す方法を解説します。具体的にはwithCheckedContinuationを用いて非同期処理を同期制御する手法と、Actorを活用して取得したレスポンスを安全に共有・管理する手法を組み合わせることで、無駄なAPI呼び出しの抑制や共有データの競合を回避の実現が可能です。

このトークを通じて、実務でそのまま応用できるSwift Concurrencyの効果的な使い方を習得しましょう。