トーク

音声でアプリの入力が完結したらとても便利だと思いませんか？

音声入力の代表格である Siri は2011年に iPhone に登場して以来年々進化を遂げ、「声で操作する」という動作は当たり前のものになりました。
音声入力をアプリに組み込む方法としては Speech framework があり、日本語もサポートされており、音声をそのままテキストに変換ができます。
しかしアプリの入力は、テキストだけではありません。
トグルやピッカーなど、テキスト以外のアプリ入力としては Speech framework 柔軟性に欠けていました。

ところが、WWDC25 で発表されたオンデバイスLLM Foundation Modelsを使うと状況が一変します。
@Generableマクロを使うことでプロンプトから任意のSwift型のデータを出力できるようになったのです。
つまり Speech frameworkで音声入力をしてテキストに変換し、Foundation Modelsのプロンプトとして渡せば、アプリの入力を音声で完結できるようになりました。

このトークではSpeech frameworkとFoundation Modelsでアプリの入力を簡便にする方法を発表します。
Todoアプリを例に実装例やオンデバイスLLMでの効果的な利用方法をお話します。

「目次」
・Foundation Modelsとは？対応機種や制限は？
・Speech frameworkと組み合わせる実装例
・効率の良いプロンプト作成方法
・実際のユーザーの評価とフィードバック

あなたのアプリもキーボード中心の UX を“声だけの入力”へアップグレードしてみませんか？

みなさんの開発チームにiOSエンジニアは何人在籍していますか？
中には少数のエンジニアで開発・運用しているケースもあるかと思います。

少人数体制では、チームにかかるリリース作業の負荷が大きくなりやすく、どうしてもリリース間隔が空いてしまい、頻度が低下しがちです。
しかしリリース頻度の減少は、ユーザーからのフィードバックを得る機会 = 仮説検証を通じたサービスの成長・改善機会の減少にもつながるため、可能な限り避けたいものです。

私が開発・運営に携わっているグルメサービス「Retty」のアプリチームは、iOSエンジニア2名を含む全3名という小規模チームながら原則「毎週リリース」を実現し、直近1年間のiOSアプリのリリース回数はのべ50回に達しました。

この継続的かつ高頻度なリリースによって、仮説検証や機能の軌道修正を機動的に行うことができ、ビジネス視点でも大きなメリットを得られていると実感しています。
もちろん、これは気合で成し遂げているわけではなく、開発メンバーの負荷を最小限に抑えながら「楽々」達成できるよう、さまざまな工夫とテクニックを活用しています。

本トークでは、毎週リリース実現のため、我々が実践してきた開発・運用手法や工夫についてわかりやすくご紹介します。
また高頻度リリースを実践するうえでの注意点や、直面した課題・失敗事例についてもお話しいたします。

「たくさんリリースして、たくさん学んで、たくさん成長する」
そんなアプリ開発・運用を目指す方にとって、きっと参考になる内容です。ぜひ本発表をご覧ください。

トーク内容

• 毎週リリースのメリット
• Retty iOSアプリでのリリース実績
• ブランチ・リリース戦略
• アプリ・API設計の工夫
• 自動化・CI/CDの活用
• リリースフローの最適化
• 毎週リリースでの注意点・失敗事例

iOSアプリ開発において、状態監視の実装方法は時代と共に多様化しています。従来のDelegateやKVOから、単純なクロージャ、Combine、AsyncSequence、そしてSwiftUIのObservationに至るまで、現在では開発者には数多くの選択肢が与えられています。

しかし、きちんと仕組みを理解せず「最新技術だから」「手軽に書けそうだから」といった理由で技術選定を行うと、思わぬ罠を踏み、結果としてプロジェクトに不適切な実装を生むことにもなりかねません。加えて、既存の手法を用いる場合でも、Swift Concurrencyへの対応という現代的な課題は避けて通れません。

本発表では、各状態監視手法の特徴や長所・短所を整理し、どのような場面でどの技術を選択すべきか、その実践的な指針を提案します。皆さんが日々の開発で自信を持って技術選定できるよう、その一助となれば幸いです。

APIが新しいSpeechフレームワークでは大きく改善されたことをご存知でしょうか？AppleはSiriやキーボードに音声入力のインターフェイスを統合しています。新しいSpeechフレームワークはこれまで内部にあったAppleの音声入力の機能を公開することで、より高精度の文字起こしが簡単に、手軽に実装できるようになりました。

また、音声入力の価値は、LLMの登場によって再評価されています。ノートアプリや通話アプリでは、ミーティングノートを自動で作成することが次世代の標準機能とされつつあります。さらに、ライブ配信では文字起こしを活用したリアルタイム翻訳が増えてきており、音声入力がアプリのコア機能として位置づけられることが予想されます。

しかし開発者として、音声入力をアプリに持ち込むことを考えた時にどのようにアプリ全体を設計したら良いのか悩むことが多くあります。どのようにまず音声を取得するのか、リアルタイムと録音済みでの考慮する点の違いはあるのか、抽象化の観点はどうすべきか、Speechフレームワーク以外に同様の機能を提供するフレームワークは何があるのか、どのようにLLMと連携すべきなのか、など開発してみないと考えにくい観点がたくさん挙げられます。

本トークではこれらの疑問を解消してアプリに音声入力を持ち込むために必要な知識を包括的に提供します。

1. iOSで音声を扱うための基礎知識であるAVFoundationについて
2. 新しいSpeechフレームワークができること
3. 音声入力のWhisperKitとSpeechフレームワークの比較
4. 実例で学ぶSpeechフレームワークを使った音声入力アプリの実装方法

このトークを通じて、音声入力を活用したアプリの実装に挑戦してみましょう！

アプリ開発では、アプリと別のプロセスで動作する App Extension を開発できます。昔からある仕組みですが、近年特にアプリの機能をOSに渡すことでリッチな動きを実現する Widgets や Apple Intelligence (App Intents) で利用する機会が格段に増えています。この仕組みではアプリ本体とは別プロセスで動作するため、データの一貫性や安全な共有が求められます。しかし、 UserDefaults や FileManager、 Core Data、 Keychain など、共有・永続方法は多岐にわたります。また AppExtension は利用できるメモリにも上限があり、正しく設計しなければクラッシュやデータ破損、一貫性を損なうバグの原因にもなりかねません。

本トークでは、 App Extension を利用する際に安全かつ効率的にデータを扱うための指針について紹介します。基本的な設計に加え、実践的なTipsを幅広く紹介します。たとえば、起動処理で必ず行われるセットアップ処理に関する罠や、 App Extension 特有の制約に伴う DB のマイグレーションの扱い、 App と App Extension 間で発生したイベントをどのように通知しあうか、等です。

App Extension の活用が進む中、「データの正しい共有設計」はますます重要になります。 Widgets や Apple Intelligence にこれから対応しようとしている方にも、すでに導入済みで改善のヒントを得たい方にも役立つ内容です。

visionOS 26 で発表された「Apple Projected Media Profile（APMP）」 は、MP4／MOV ファイルに拡張メタデータを付与し、180°・360°映像を標準映像と同じ操作感で扱えるようにする新しい仕組みです。

高価な専用カメラが必要な「Apple Immersive Video」とは異なり、APMP ならGoProやInsta360など、個人でも手軽に入手できるカメラで撮影した映像を、そのまま Vision Pro の没入空間で再生できます。

本講演では、APMP の基本的な構造を説明し変換手順までを次のトピックで解説します。

• APMP が扱える映像フォーマットの種類
• QuickTime コンテナ内「vexu」ボックスの仕組み
• 標準映像をAPMP対応ファイルへ変換する方法

最後に、個人開発している visionOS 2向け 360°動画アプリをAPMP対応へ移行した際に、どのような修正が必要だったのかを、差分ソースコードを示しながら詳しく解説します。

オープンデータとは、誰もが自由に使えるよう公開されたデータのことです。
気象、人口、交通、選挙など、行政機関が提供するオープンデータには、社会の課題や動きを読み解くヒントが詰まっています。
しかし、多くはCSVや表形式のまま放置され、活用されずに埋もれています。

このセッションでは、iOS 16以降で使える Swift Charts を活用し、こうしたオープンデータをアプリで「伝わる形」に変える方法を紹介します。

実際に気象データや交通データ、選挙・人口統計などを例に、データの取得、整形、そしてインタラクティブなチャート表示までをデモを交えて解説します。
たとえば、気象データを棒グラフで表示したり、通勤手段の変化をエリアチャートで見せたり、投票率を地図上にヒートマップで可視化したり。

「Swift Chartsを使ってみたくなる」「地域や社会のことをアプリで伝えてみたくなる」

そんな感覚を持ち帰っていただけるセッションです。

iOSアプリ開発においても、AIコーディングツールを活用して開発効率を向上させる事例が増えています。日々の業務でもさまざまな開発タスクでAIを活用していますが、私はその中でも特にFigmaのデザインデータをもとにSwiftUIコードを自動生成する取り組みに挑戦しています。

とはいえ、AIに「コードを生成してほしい」と指示を出すだけでは、期待どおりのコードを得ることは難しいのが実情です。特に独自のDesign Systemライブラリを使用しているような場合、適切なコンポーネントを使った狙いどおりのコードを生成させるにはいくつかの工夫が必要です。

このトークでは、安定的に品質の高いSwiftUIコードを生成するために行なった、以下のような試みについてお話しします。

• MCP Serverを用いてFigmaからデザインデータを正確に取得する
• Claude Code を使って既存のコードからSwiftUIとDesign Systemの関連性を学習し、ナレッジとして蓄積させる
• 生成されたSwiftUIのスナップショット画像とFigmaからエクスポートした画像データを比較し、AI自身に誤りを検知させ、自己修正を行わせる
• 自己修正と開発者からのフィードバックをもとにナレッジを自己更新させる
• AIを使ったコード生成における、学習 → 生成 → 検証 → 改善 のループの重要性
• 現時点における限界、理想と現実

AIコーディングツールの進化は非常に速く、追いかけるのが大変ですが、このトークを通じて、AIを活用した開発のヒントやアイデアを得て、日々の作業に取り入れるきっかけになれば幸いです。

本業iOSエンジニア、副業で弓削商船高専の教員の私が、iOS開発経験ゼロの高専生5名と共に全国高等専門学校プログラミングコンテストのテーマ「ICTを活用した環境問題の解決」に挑みます。
開発期間は6月から10月までのわずか4ヶ月。
この無謀にも見える挑戦のリアルタイムな奮闘記をお話しします。

本トークでは、以下の3つの視点から、私たちの挑戦の過程を共有します。

1. 社会課題からiOSアプリ構想へ
   紙の大量消費と個人情報漏洩という2つの社会課題を同時に解決するため、どのようなアイデアを経てiOSアプリの構想に至ったのか。
   そして、4ヶ月で開発を完遂するため、いかに機能を最低限の最低限まで絞り込んだのか、その要件定義のプロセスをお見せします。

2. ほぼオフライン環境のデモンストレーションを乗り越える技術設計
   コンテスト本番は運営側が用意しているインターネット環境は不安定、作品のデモンストレーションに使えるスペースも机一個分という縛りあり。
   そんな環境でも安定したデモンストレーションを実現するため、基本的な機能はローカル（サーバ含め）で完結するアプリ設計に舵を切りました。
   通常のアプリ開発とは一味違う、制約の多い環境下での技術選定やアーキテクチャ設計の勘所を解説します。

3. iOS初心者チームの育成とリアル
   iOS開発を知らない学生たちを、いかにして4ヶ月でiOSアプリを開発できるチームへと導くのか。
   技術コーチとして、PMとして若手育成の壁とそれを乗り越えるための工夫を、リアルな経験談としてお伝えします。

セッション当日は、10月のコンテストに向けて学生は最も修羅場の時期。
開発の最前線で"今"起きているたくさんの「つらみ」や学びを、熱量高くお届けする予定です。

※ なお6月末時点、プロダクトコードは1行も用意できてません。

「Write once, run everywhere」 - それはアプリケーション開発において、多くの開発者が追い求めてきた夢です。
モバイルアプリ開発の世界では、Androidの公式言語であるKotlinも例外ではありません。
Compose Multiplatform for iOSがStableとなり、アプリケーションの大部分をKotlinだけで開発する選択肢が現実的な視野に入ってきました。

しかし、過去の歴史が示すように、マルチプラットフォーム技術は常に諸刃の剣です。
技術選定とは、輝かしい未来を選ぶだけの行為ではないのです。チーム体制、事業フェーズ、プロダクトの性質によって、いつかその技術から「撤退」する日が来るかもしれません。
使用されていた技術の影響により部分的撤退が叶わなかったアプリも見受けられます。
本セッションでは、この予期せぬ「撤退戦」までを考慮に入れることの重要性を提起します。

本セッションではKotlin Multiplatformを主軸に、この「撤退戦略」を深掘りします。
まず、なぜKotlin NativeがネイティブAPIを直接呼び出し、ネイティブらしい振る舞いを実現できるのか解説します。そして、この特性が撤退時にどう活きるのかを明らかにします。
最後に、プラットフォームの専門家が変化の時代で自らの強みを最大限に発揮するための技術選定の指針を考察します。

トーク内容

• マルチプラットフォームにおける「共通化」の功罪
• なぜ技術選定で「撤退戦」を考慮すべきなのか？
• Compose MultiplatformとKotlin Multiplatformの現在地
• 撤退シナリオから見る、Kotlin Nativeの真価 Kotlin+UIKitの組み合わせ
• 変化の時代における、プラットフォーム専門家が活きる技術選択の指針

Swift TestingはWWDC2024でアナウンスされたテストフレームワークです。マクロを活用したAPIで、記述量を抑えつつ、parameterized testsやテストの並行実行もサポートされるものです。XCTestからのマイグレーションドキュメントも公式に準備されており、プロジェクトをSwift 6にさえできていれば、デメリット小さく良いテスト体験を享受できます。

一方で、課題になるのは「既存のテストをどう書き換えていくか」ではないでしょうか？プロジェクトによってはXCTestで記載されたもののみでなく、Nimbleのようなライブラリを用いて記載されたテストもあるでしょう。
これらの既存のテスト資産を効率よく、そしてより効果的なテストに変換することを皆さんは意識できていますか？マイグレーションドキュメントはXCTestとの対応表に過ぎず、「どう書き換えるか？」については焦点を当てていません。また、数個の単体テストを書き換えても、テスト実行時間の削減には大きな影響はなく、書き換える事自体のモチベーションが下がり、Swift Testingに置き換える事自体が後回しになっていないでしょうか？

そんな後回しになってしまう課題について、このトークではMCP ServerとこれをコントロールするAI Agentを導入することで、無駄な後戻りを小さくおおよそ自動でテストのマイグレーションを実行したケーススタディを紹介します。既存のswift-testing-revolutionaryやSwiftFormatのpreferSwiftTestingといったツールをそのまま使うのではなく、MCP Serverとして提供することのメリットについても触れ、Swift Testingに移行するモチベーションを上げる具体的なアクションの一つを皆さんと共有できればと思います。

10年前に誕生したUIKitアプリは、さまざまな課題を抱え保守性が悪い状態になっていました。状態管理のenumやフラグを抱えコードの見通しが悪くなったFat ViewController、ロジックを分離したが機能が積み上がるにつれて責務が混在したManager──そんなレガシーなアプリが生み出すバグと格闘する日々が続いていました。

本セッションでは、レガシーアプリを改善するためにアプリに生じるバグの傾向を分析し、「コードの見通しの悪さ」を生む構造的な原因に向き合う中で、SSOT(Single Source of Truth)を実現するための Store、状態管理であることを明確にするための ViewState など、iOSDC2023で紹介された「SVVSアーキテクチャ(Store・ViewState・View)」に辿り着くまでの過程をお話しします。

Fat ViewControllerからの段階的な分離、SwiftUI移行を見据えた土台作り──SVVSをスモールステップで導入するプロセスと、それによって得られた改善効果についてお話しします。

• レガシーUIKit MVC アプリが抱える課題
• アプリで頻出するバグの傾向分析
• 取り組む課題と実現したいことの整理
• Fat ViewController を段階的に改善した作戦
• SVVS になった後の SwiftUI 導入

位置情報を活用したアプリは便利である一方、権限ハンドリングやバッテリー消費といった数多くの課題が存在します。本セッションでは、実際のプロダクト開発で遭遇した問題とその解決策を具体的なコード例とともに紹介します。これにより、参加者が安全かつ効率的に CoreLocation を活用できるスキルを身につけることを目指します。

【話すこと】

• 位置情報のステータスの違いとリクエスト方法
• 位置情報変更時の効果的なデバッグ方法
• 位置情報によるアプリ起動のライフサイクル管理
• 移動経路取得のための実現方法と注意点
• バッテリー消費を抑えるための実践的手段

【対象者】
位置情報機能を実装予定の開発者、既存アプリの改善を考えている方、CoreLocationの課題に直面した経験を持つ開発者

CoreLocationに潜む課題を理解し、安心して位置情報を活用したアプリを開発できるスキルを身につけましょう！

AIエージェントの発展により、プログラミングの敷居は大幅に下がりました。プロンプトを書けばコードが生成され、どんどん実装を進めることができます。しかし、開発速度を上げることだけがAIエージェントの利点でしょうか？

AIエージェントを使えば未知の領域のプログラミングも十分な品質で実装が可能になります。
それまでは諦めていた不慣れな分野のプログラミングもアプリに取り込み、結果としてユーザー体験をよりよいものにできるでしょう。

私は7年間個人開発として風水アプリを開発を続けています。
このトークではその風水アプリにCursorを使って国際標準地球磁場 (IGRF-14)をSwiftへ実装し、MapKitを利用した偏角計算画面により風水アプリのUXを劇的に改善したプロセスを紹介します。
AIエージェントとの対話によって、IGRF-14モデルのPythonコードの理解からSwiftへのリファクタリングまでを一気通貫で実現し、リリースまで漕ぎ着けた一連の取り組みを解説します 。

「目次」
・地磁気モデル（IGRF）とは？
・IGRFモデルによる偏角の計算プログラムをCursorでSwiftへの変換
・生成されたコードの品質担保戦略
・OSSの公開とアプリ設計、Swiftらしいコードへのリファクタリング
・AIエージェント利用時の課題と解決策

AIエージェントの利用を考えている方へ具体的な事例を示し、Vibe codingの先にある、やりたいことをやり切る方法を具体的にお伝えします。

Pull-Requestのレビューを依頼された際、レビューのために手元で作業中の内容を一旦スタッシュし、レビュー対象のブランチをpullして、Xcodeでプロジェクトをビルドするような経験はありませんか？

頻繁にブランチを切り替え、動作確認のためのビルドを行うと、数えきれないほどの時間がレビューのために使われることになります。

この課題解決のために動作確認用のTestflight版アプリを用意することも多いと思いますが、その場合もアプリのArchiveとアップロード、Testflight上で配信可能になるまで時間がかかります。
Testflight側のレートリミットも存在するため、Pull-Requestの内容が更新されるたびにTestflightにバイナリをアップロードするといったワークフローは組みづらいでしょう。

私たちのチームではこの課題に対して、手元でビルドすることなく、Testflightで配布可能になるのを待つことなく、Pull-Request上にコメントされたリンクをクリックするだけで動作確認できるワークフローを用いて大幅に時間と手間を削減しています。

本トークでは、私たちのチームで導入している動作確認を簡単に行えるようになるワークフローを他のチームでも導入できるように、以下の内容について紹介します。

• iOSにおけるビルド成果物の種類について
• 動作確認用のテストアプリの準備方法について
• Shopify製のツール「Tophat」を用いて、App Bundleを用いたシミュレーター上での動作確認方法について
• 検証したい対象と、それに応じたテスト版配布方法のプラクティスについて

このセッションを通して、Pull-Requestのレビュー体験を改善し、チーム全体の開発効率を飛躍的に向上させるヒントを得ていただければ幸いです。

現代のServer-Sideにおいて、Observability（可観測性）は必須の存在です。マイクロサービスやCQRSなどの分散システム、サーバーレスモデルでは、ログ・メトリクス・トレースを集約して観測できることが運用上必須となっています。
Server-Side Swiftを採用する際、主軸として使う場合でもマイクロサービスの一部として導入する場合でも、OpenTelemetryなどの業界標準との連携は避けて通れません。
本トークでは、Apple公式のswift-log、swift-metrics、swift-distributed-tracingの役割と連携方法を解説し、OpenTelemetryを通じて様々な監視サービスと接続する方法を紹介します。

実践的なライブデモ
Vapor + AWS Lambdaを使用したCQRS/Event Sourcingシステムの実装を通じて、AWS CloudWatchとX-Rayによる分散システムの監視を実演します：

• 分散トレースによるリクエストの流れの可視化
• Lambda関数間の呼び出し追跡
• イベント処理の監視
• 処理速度のボトルネック特定

SwiftはiOSアプリ開発で培った型安全性と高いパフォーマンスをサーバーサイドでも活用できます。CQRS・Event Sourcing・Serverlessのような複雑な分散システムこそ、Swiftの強力な型システムとApple公式の監視ツールが真価を発揮します。
Server-Side Swiftの導入を検討している方、本格的な運用に向けて準備したい方に、実践的な監視システムの実装方法を提供します。一緒にServer-Side Swiftで本番環境に耐えうるシステムを構築する一歩を踏み出しましょう。

「アクセシビリティ機能を使用してこのコンピュータを制御することを求めています。」

macOSでアプリを初めて開いた際、このような許可ダイアログが表示されたことはないでしょうか。
ダイアログの内容からはどのような許可を求めているのか理解しずらいですよね。

実はこれ、かなり強力なコンピュータ制御の権限を得ようとしていることをご存知でしょうか。
この権限を使えばキーロガーや画面監視アプリなんて簡単に作れてしまいます。

そんなことを知らずに何気なく許可していた方は、本トークでmacOSのセキュリティリスクを再確認することができます。
アクセシビリティの許可をすることでどのような処理ができるのかをコードベースで理解し、そこからどのような危険性があるかを説明していきます。
ただし、危険とは言いつつも開発者としては非常に面白い機能も使えるようになるため、技術面でも興味深い内容となっています。

AIによって自動化が急速に進化する今だからこそ、コンピュータの制御を可能にするアクセシビリティの許可は正しく理解しておく価値があります。
きっとみなさんのMacにもアクセシビリティ許可をしているアプリがあるはずです。

ぜひご覧ください！

Apple Style Guide は、Apple 製品に関する用語や表現のガイドラインです。UI やドキュメントでどのような言葉、どのような表現を使うべきかが記載されています。

Apple のガイドラインといえば、Human Interface Guidelines があります。これは iOS アプリ開発者に必読のガイドラインとして知られています。一方 Apple Style Guide のほうは、よく知らない開発者も多いのではないでしょうか。しかし実はこれも知っておくべきガイドラインです。このガイドラインに従うことで、ユーザーの混乱を防止できます。

たとえば、「Apple ID」ではなく「Apple Account」が正しい表記です。Apple Style Guide を読めばこのような適切な表記がわかります。不正確な表記は、アプリやドキュメントの信頼感を損ねます。

また、「クラッシュ」という表現は UI やドキュメントでは避けるべきです。読者によっては、ハードウェアやソフトウェアの損傷を連想するかもしれません。代わりに「予期せず終了する」「応答しない」などの表現を使います。こうしたことも Apple Style Guide に記載されています。

Apple Style Guide は他にも、インクルーシブな記述、数値や単位の表記、コードなどの技術的な表現、国際的スタイルでの表記について書かれています。多くのユーザーにアプリやドキュメントを利用してもらうために、重要な内容です。

本トークでは Apple Style Guide から、iOS アプリ開発のために知っておきたい内容をピックアップして解説します。正確な表記やよりよい表現を知り、アプリの信頼性を向上させましょう。

ウォンテッドリーのモバイルアプリでは、Kotlin Multiplatform（KMP）を使ってビジネスロジックを共通化しています。
一方で、iOSエンジニアにとってKotlinは馴染みが薄く、不安を感じる方も多いのではないでしょうか。
私自身、Swift中心の開発を続けながら、1年間KMPを導入したプロジェクトに関わってきて、「iOSエンジニアとしてKMPとどう向き合うべきか」を日々模索してきました。

本セッションでは、私自身がこの1年で得た、iOSエンジニアとしてKMPと関わるうえでの学びと工夫を、以下の3つの観点から共有します。

1. 設計の重要性
   ウォンテッドリーではビジネスロジックを担うReactorの設計書を書いてチーム内でレビューをしてから実装を行います。丁寧に設計を行うことで、出戻りや仕様のズレを防ぐことができ、KMPとiOS側の開発がスムーズに連携できるようになります。

2. Preview駆動開発との相性
   ロジックとUIの責務を明確に分けることで、Previewによる効率的な開発が可能となり、KMPの共通ロジックとも無理なく共存させることができます。

3. AI活用によるKotlinのキャッチアップ
   Kotlinに不慣れな立場でもAIを活用することで、レビューや仕様理解がしやすくなり、日々の開発に必要な知識を実践の中で補うことができます。

このセッションが、KMPの導入に不安を感じているiOSエンジニアや、導入を検討しているチームの方々にとって、実践的なヒントや前向きな視点とともに、成長の機会になると思えるきっかけになれば幸いです。

RxSwiftのコードを読んでいくと、Observerパターンやイベント伝播の考え方など、「プログラミングの基礎」に立ち返る瞬間があります。本LTでは、RxSwiftの代表的な要素（Observable, Observer, Subscribe, Dispose）を題材に、実際のソースコードを一部追いながら、そこにある基本的な仕組みを解説します。
たとえば、イベントの購読処理はどう保持され、どこで通知が発火するのか？この流れを理解することで、RxSwiftが単なるライブラリではなく、基礎的な設計原則に沿って構築されていることが分かります。
また、こうした理解は、CombineやSwiftUI（@State, @Publishedなど）の仕組みを学ぶ上でも大きな助けとなります。
リアクティブなコードに苦手意識を持つ方や、ライブラリの「中身」を通じてプログラミングを深く学びたい方に向けて、基礎を見直すきっかけとなるLTです。