トーク

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アシスタントの成長を実感できるでしょう。

Live Activity はリアルタイムの情報を、ロック画面や Dynamic Island に表示できる機能です。iOS 16で登場して以来、毎年改良が進み、Apple の様々なデバイスに対応するようになりました。

Live Activity はリアルタイムに動くシステムのため、考慮する事項はクライアントからバックエンド、通知サーバーに至るまで多岐に渡ります。特に、多数のユーザーに向けて Live Activity を配信する際には、サーバーへの負荷が懸念されます。Live Activity はその考慮事項の多さから、安定的に運用するために様々な対応が必要となります。

Live Activity を大規模に利用するための SDK の改善が毎年行われています。その改善により、Live Activity の開始方法や、更新方法には複数の選択肢が存在するようになりました。特にスケールを意識した場合、トークン方式による個別更新、チャンネルを使用したブロードキャストの更新の使い分けが重要となります。本セッションでは、実体験を交えながら Live Activity の現在の仕組みを深掘りし、大規模アプリでのベストプラクティスを共有します。

導入を検討する際、手元で動作を試すのにはいくつか壁がありました。また、Dynamic Island に表示できる View には制約があるため、レイアウトの組み方にも工夫が必要でした。ドキュメントを読むだけでは気づけなかった、実際に遭遇した罠にはどのようなものがあったのか、そして安定して運用するためにどういった対策を行ったのかを紹介していきたいと思います。

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

2023年の Swift 5.9 で導入された Observation は、Swift のエコシステムにおける比較的新しい値の監視の仕組みです。

従来の値の監視で用いられてきた Key-Value Observing（KVO）には Objective-C のランタイム（NSObject）への依存や型安全性の課題があり、Swift 製の Combine フレームワークには ObservableObject で @Published を何度も記述する必要があったり、非効率な更新が発生したりすることがありました。Observation は Swift に同梱されて提供され、格納プロパティが自動的に監視対象となり、プロパティ単位での効率的な更新が行われるようになっています。

このトークでは Observation の導入の経緯やピッチ段階でのアイディア、最終的に導入された Swift マクロによって展開される値の監視の仕組みについて解説し、動作原理について理解します。また、Apple が提供しているフレームワークにおける Observation の活用例についても触れます。さらに、Swift 6.2 では Observation に新たに AsyncSequence インターフェイスが追加され、iOS 26 では UIKit との連携が強化されています。これらの新機能についても、実際のアプリのコード例とともに詳しく紹介します。

Observation が登場してから約2年、iOS 17 から使えるこの仕組みは、今があなたのアプリに取り入れるちょうど良いタイミングです。Swift の特徴である堅牢さ、型安全性、高パフォーマンスを備えたこの値の監視の仕組みを理解し、普段のアプリ開発に活用してみましょう。

2014年から運用しているアプリをSwiftUIとThe Composable Architecture(以降TCA)でリニューアルを開始してからおよそ2年経過しました。
今ではほとんどの画面を移行し終わり、SwiftUIとTCAを使ったiOS開発は生産性は大幅に向上させました。
しかし、これらの優れた技術を使っていても使い方を間違えると「アプリが重い」「スクロールがカクつく」「メモリ使用量が多い」といった問題に直面することがあります。私自身もこれらの問題に直面し、解決に取り組んでいる最中です。

本セッションでは、50以上のSwift Packageモジュールで構成される実際のアプリを題材に、SwiftUI+TCAの利点を活かしながらも発生しがちなパフォーマンス問題と、その解決方法を実例を交えて紹介します。

このセッションでは以下のような内容を話す予定です

• SwiftUI+TCAの基礎とメリットと導入の背景
• TCAの陥りがちなパフォーマンス課題
• SwiftUIの陥りがちなパフォーマンス課題
• それらのパフォーマンス課題にどう向き合ったか

ゲームディレクター・デザイナーが「軽量」「摩擦少」「最小人数」でプロトタイピングできるかどうかが、斬新なコンセプトの成功や事業実装に直結するのです。Cursorを使えば、新しい体験のプロトタイプをプログラム的に生成することは以前より格段に容易になりました。try Swift 東京 2025でも、iOSアプリのゲーミフィケーションを強化するツール群を紹介しました。
youtube.com/watch?v=7LSKcNOm_HE

なお、現在のネックはコンテンツです。

世界観に合うアートスタイルのキャラクター生成には、単なる画像APIでは不十分。
特定のカラースキームを持つUIを構築するには、プロンプトだけでは質感や見た目のクオリティが担保できない。
初期段階でも「説得力ある動的生成コンテンツ」（ストーリー、対話、NPCの行動・性格・反応）でユーザーを驚かせる必要がある。
任天堂やスクエニのような秘密主義の企業ほど、GPT 等へのプロンプト送信を避け、ローカルだけ完結させたいという要件が強い。また、画像生成の往復の待ち時間をエンドユーザーが容認しない場合も多いでしょう。

本セッションでは、
Foundation Models や ビジョン フレームワークを活用する部分、
Create ML でトレーニングする部分、
Huggingface からLoRAによるファインチューニング／MLX経由で変換する部分（Image Playgroundは実用的？）
などを、iOSアプリ上—限られたメモリ環境内—でローカル完結しつつ、外部APIに頼る世界とどう折衷すべきかを具体的に比較・解説します。

最後には、MLX + Swift を使った独自ファインチューニングパイプラインを解説し、注意点・落とし穴・ベンチマーク手法（gpt‑image や Gemini との比較）まで深掘りします。

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

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

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

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

SwiftではSwift RegexとNSRegularExpressionという二つの正規表現エンジンが利用できます。しかし、SwiftUIとUIKitの関係と同じく、新しい方が常に正解ではありません。サポートする機能が異なるので、単純な置き換えはできません。パフォーマンスの観点からはSwift Regexの方が多くのケースで遅いことも分かっています。

しかし、この２つの正規表現エンジンはどちらもバックトラック型の実行方式のため、仕組み上、正規表現の書き方がパフォーマンスに大きく影響します。どちらを利用するかを適切に選択するには、単純なベンチマークで決まるものではなく、正規表現エンジンが文字列をマッチする原理と仕組みの理解が重要です。

Swift Regexはオープンソースなので、ソースコードを読むことも可能ですが、一般的なアプリケーションコードとは大きく異なるため読み解くことは容易ではありません。（NSRegularExpressionも実装はICUなのでソースコードは読めます。）

また、Swift Regexは更新頻度が落ちており、SE-0448など承認済みの改善であってもいまだ未実装の機能が存在するため、自ら改善に貢献したいという人も多いでしょう。

そこで本講演ではSwift Regexとまったく同じ構成で、機能だけを「連接・選択・繰り返し」の基本三演算に限定した最小の正規表現エンジンをゼロから実装します。限定版といっても、正規表現は基本三演算さえ実装すれば理論上はフル機能の正規表現と同じ表現力を持つので、実用性は変わりません。

自分で実装することは動作の原理や仕組みを学ぶための最適な手法です。正規表現が動作する仕組みを理解することで、技術選択に確信が持てます。また、公式の実装を読み解き、機能の拡張へ貢献するための第一歩となります。

iOSDC2023で紹介されたScipioは2年間の時を経て、さまざまな進化を遂げました。
私はそのScipioの開発に現在携わっています。
Scipioとは、XCFrameworkの生成・キャッシュを行うツールです。生成したいXCFrameworkをPackage.swiftに依存として追加し, それを元に依存解決をSwift Package Managerで行い、その依存関係からXCFrameworkを生成しています。

Scipioでは、内部的にSwift Buildを使用してXCFrameworkの生成を行っています。しかし調査の結果、マクロターゲットを含むパッケージは Swift Build ではビルドできないという問題に突き当たりました。本トークでは、その問題に対してどのような方法でマクロターゲットをビルドすることにしたのか、解説します。

具体的には、以下の点についてお話しします：

• Scipioのビルドフローの全体像
• SwiftPMやSwift Build、それを仲介するPIF (The Project Interchange Format)の関係や制約
• マクロの詳しい動作原理
• Scipioでマクロターゲットをビルドする場合にどのような手法を取ったのか

本トークは、マクロを含むライブラリをXCFrameworkとして利用したい方や、Scipioのビルドフローの全体像、マクロの動作原理を理解したい方にとって、有益なトークです。

UIKitとAppKitの中でも飛び抜けて複雑なViewであるテキストビューにはユーザーが標準で使える機能が数多く存在します。
本トークではそれらの機能を一望し、開発者がそうした標準機能を制御する方法や、また制御することでユーザーに提供できる機能についても紹介します。 例えばコピー・カット・ペースト、翻訳機能といった一般的な機能から、テキストをダブルタップ / ダブルクリックで選択したとき単語が選択されるのは何故なのかといった細かな挙動まで。 さらに、それらはUIKitやAppKitの公開クラスとして利用できたりもします。
UITextView / NSTextViewについて隅々まで知ることで、ユーザーとして日々のiOS / macOS上のテキスト入力が少し便利になったり、アプリ開発者としてちょっとしたユーザー体験の改善ができるようになります。

• テキストビューとは何か
• UITextViewで暗黙的に利用できる機能たち
• NSTextViewで暗黙的に利用できる機能たち
• コンテキストメニュー
• UIKitとAppKitのclassの対応関係（UITextChecker / NSSpellCheckerなど）
• UITextViewにおけるUIInteractionの重要性とテキスト選択
• NSTextView (macOS) と縦書き
• TextKit 2と縦書き
• UITextInput / NSTextInputClientについて
• Writing Toolsの登場、そして26へ

「長時間の会議や講義を正確に転写できるアプリを作りたい」多くのiOS開発者が抱いてきたこの夢が、iOS 26のSpeechAnalyzerでついに現実となります。
従来のSFSpeechRecognizerは短時間音声処理に限られ、サーバー依存による遅延や複雑な言語設定が開発の障壁となっていました。
これらは技術的制約というより、当時の設計思想によるものでした。

SpeechAnalyzerは、これらの制約を根本から見直した革命的なAPIです。
完全オンデバイス処理により瞬時の応答を実現し、長時間音声にも対応。二段階処理（即座の仮結果と最終確定結果）により、リアルタイムでテキスト化される驚きの体験を提供します。

本セッションでは、従来技術の限界を踏まえながら、モジュール式設計による柔軟性、非同期処理でUI処理を妨げない仕組み、音声時刻情報による正確な同期技術など、SpeechAnalyzerの設計思想を深掘り。
専門用語を実装メリットと共に分かりやすく解説します。

実装デモでは、絵本読み聞かせアプリを題材に、転写設定・モデル確認・結果処理の3ステップから、CMTimeRangeを活用したテキストと音声の完全同期まで段階的に実演。
Apple Intelligence連携による自動要約機能も披露し、従来不可能だった高度な機能実装を具体的にお見せします。

オンデバイス処理により通信制約から解放され、これまで諦めていた音声認識アプリのアイデアが現実のものとなる開発手法をお伝えします。

スマートフォンの性能向上により、AIをクラウドではなく端末上で実行するエッジAIの重要性が高まっています。iOSでは、Core MLを中心にオンデバイス機械学習のための強力なエコシステムが整備されていますが、実際に導入しようとすると、思わぬ壁や選択の難しさに直面することも少なくありません。

私自身、自作アプリにAIを導入しようとしたときにも、

• 既存のAPIや提供モデルによる目的達成の可否の見極め
• Python製モデルの変換や最適化における、サードパーティ製含むツール選定と運用の難しさ
• ライセンスや配布制限のような非技術的制約

といった多くの課題にぶつかり、Apple公式資料だけではカバーしきれない範囲の大きさを実感しました。

本セッションでは、このような試行錯誤や失敗経験を交えながら、以下のトピックについて実践的に解説します：

• AIおよびエッジAIの基本概念と進化の歴史
• iOSにおけるAI基盤技術・Core MLの役割と仕組み
• VisionやNatural LanguageなどのApple純正フレームワーク
• Create MLやcoremltoolsなど、Core MLを支える周辺ツール
• ExecuTorchやLiteRTといったサードパーティ製推論ツール
• ライセンスや配布制限など、非技術的な落とし穴

WWDC25では、Apple Intelligenceの強化や新しいFoundation Modelsフレームワークが発表され、iOS上でのエッジAI活用は新たなフェーズに突入しました。このセッションを通じて、エッジAI技術への理解を深めるとともに、「AIを使う側」から「AIを統合する側」へと進むための実践的な知識と視点をお届けします。

エッジ AI とは、スマートフォンなどのエッジデバイス上で行う AI 関連処理のことです。

近年のハードウェア (特に GPU や Neural Engine) の進化により、アプリでより高性能なエッジ AI を実現できるようになりました。

iOS をはじめとする Apple プラットフォームも例外ではなく、 Core ML というエッジデバイスに最適化された AI フレームワークを提供してきました。近年では、 Apple Intelligence や WWDC 2025 で発表されたばかりの Foundation Models により、学習済みモデルを用意せずともアプリにエッジ AI 機能を搭載できるようになる未来も見えてきました。

また、 Apple だけでなく PyTorch といった有名な AI フレームワークも、エッジ AI 関連のサポートを強化しており、著名な学習済みモデルのアプリへの組み込みについても可能性が広がってきました。

AI 関連技術が世界的に注目を浴びる中、本トークではエッジ AI をキーワードにスマホアプリとエッジ AI の可能性について、実機での動作検証結果を交えてご紹介します。

アジェンダ

• エッジ AI とは 〜 エッジ AI とクラウド AI
• エッジ AI の活用事例 〜 自動運転やスマホアプリでの活用
• CoreML 〜 エッジ AI に最適化された機械学習フレームワーク
• サードパーティ製ライブラリのエッジ AI 用フレームワーク 〜 PyTorch と ExecuTorch
• Apple プラットフォームにおけるエッジ AI の今後 〜 アプリでの Apple Intelligence と Foundation Models の活用

SwiftUIでテキストに意味や見た目の属性を与える「修飾」には、
Modifierを重ねる従来の手法、
iOS15以降のAttributedStringでの部分的なスタイル指定、
さらにiOS17以降のMarkdown記法の活用と、さまざまな選択肢が増えています。

しかし実際には、

• 差分更新の仕組み
• アニメーションとの相性
• Unicode結合文字や多言語での動作
• 複雑なハイライトや部分スタイルの表現力

など、見た目だけでは分からないハマりどころが多く、
どの方法を選ぶべきか迷うことも少なくありません。

このトークでは、SwiftUIのレンダリング仕様（Viewツリーの構造や再評価のタイミング）や、
状態管理との連携（State/Bindingと修飾の適用順序の関係）といった基礎を踏まえながら、
Modifier・AttributedString・Markdownという3つの修飾手段を深く比較し、
それぞれの得意・不得意を整理していきます。

さらに「一文中の一部だけ色を変える」「異なるフォントの混在」「多言語テキストの表示」など
実践的なユースケースをデモで比較し、
保守性やパフォーマンスの違いを体感していただきます。

SwiftUIのText修飾を極め、効率的で実用的なUI構築の知見をお持ち帰りください。

内容：

• SwiftUIにおけるText修飾の基礎と進化
• Modifier・AttributedString・Markdownの仕様と特徴
• Unicode結合文字・多言語・複雑ハイライトの落とし穴
• 「部分装飾」「複数フォント」「Markdown混在」の比較デモ
• 差分更新・保守性・パフォーマンスの観点での比較
• 最適な選択をするための判断基準とTips

Swiftが大好きなあなたに語りかけています…
SwiftUIのようなシンタックスでウェブサイトを構築できたら、最高だと思いませんか？
さらに、iOSなどのネイティブアプリとロジックやリソースをシームレスに共有できたら、ウェブサイト開発に対するイメージが180度変わるはずです。

そんな理想を実現するのが、Swift製の静的サイトジェネレータ“Ignite”です。
このセッションでは、Igniteを使ったウェブサイト開発を題材に、Result BuildersやString Catalogs、XCAssetsの扱い方を通じて、Swiftの言語仕様やXcodeの仕組みに踏み込みます。再利用可能な設計と実装のコツを、豊富な実例とともに紹介します。

⸻

宣言的UIの正体に迫る

SwiftUIやIgniteで使われている「宣言的UI」についてResult Buildersの仕組みから紹介します。
これによって、Igniteがサポートしていないコンポーネントの追加はもちろん、SwiftUIでの柔軟なカスタムコンポーネント設計にも応用できるスキルが身につきます。

String Catalogsを読み解く

ウェブサイトをローカライズする過程で得た、String Catalogsの内部仕様やビルド後の挙動に迫ります。
GUIに隠れた“裏の挙動”を知ることで、アプリでの予期せぬ不具合にも迅速に対応できるスキルが身につきます。

アプリとのロジック＆リソース共有

ネイティブアプリで使っているコードやアセット（XCAssetsやローカライズ文字列）をウェブサイトでも再利用する方法を紹介します。
SwiftPMをまたいでBundleを扱うテクニックや、LinuxとmacOSビルドの差異など、マルチモジュール設計に役立つ実践的なTipsも共有します。

Apple Vision Pro 向けのコンテンツ開発は、大きく分けて2つのアプローチがあります。1つは Apple 標準の Xcode を使って Swift で開発する方法、もう1つはゲームエンジンを使用する方法です。特にゲームエンジンには Unity、Unreal Engine、Godot Engine などの選択肢があります。

iOSDC Japan の参加者の多くは Xcode で Swift を用いた開発に精通していると思われますが、Apple Vision Pro の登場以前から、XR 領域でのコンテンツ開発にはゲームエンジン、特に Unity が多く用いられてきました。Apple はこの Unity と連携し、「PolySpatial」という Unity 用のソリューションを提供しています。これは、Apple Vision Pro 向けのコンテンツ開発を支援するものです。

このトークでは、Unity の PolySpatial を用いて Apple Vision Pro アプリを実際に開発している数名の開発者と一緒に、Unity を使用した Apple Vision Pro 向けアプリ開発の現実と課題について、Xcode で Swift を用いる方法と比較しながら、一問一答形式でお届けします。具体的には、PolySpatial の基本的な概要から、その利点と欠点について詳しく掘り下げます。

「ふつうのアプリ」とは何でしょうか。
ソーシャルネットワークMastodonのアプリを作る過程で、この問いと深く向き合うことになりました。

Mastodonは少し特殊なSNSです。サーバーの概念や公開範囲の複雑さ、サーバーごとの固有機能など、それらの仕様は直感的なものではありません。
実際にアプリをリリースしてみると、ユーザーが求めていたのはMastodonの機能を完璧に扱えるアプリなのではなく、直感的に使える「ふつう」のSNSアプリなのでした。
TwitterやInstagramのような既存のSNSで慣れ親しんだUIパターンを期待していたのです。

ここから学んだのは「ふつう」を実現することの難しさです。開発者にとって当たり前の操作でも、一般ユーザーにとっては全く理解できない可能性があります。
開発者やデザイナーは独創的なUIを作りたがりますが、ユーザーは慣れ親しんだパターンを求めています。重要なのは、新しい概念を既存のメンタルモデルに合わせることです。
これらは、もちろんMastodonのアプリに限った話ではありません。

このトークでは、アプリのUIデザインを考察した上で発見した「ふつう」の見つけ方、既存UIパターンの評価方法、そしてそれらを妥協せずに実装するための実践的なテクニックを紹介します。

Apple Vision Proが登場し、私達はついに空間コンピューティングへのチケットを手にしました。
3次元の形状を、ディスプレイに投影された平面的なものではなく空間的に体感できるようになったのです。

RealityKitのMeshResourceでは、直方体(Box)、平面(Plane)、球(Sphere)、円錐(Cone)、円柱(Cylinder)、そして文字(Text)といった基本的な形状を簡単に作成できます。
また、Reality Composer Proではカプセル(Capsule)も配置できます。

しかし、これら以外の3次元形状を作成したい場合、どのようにすれば良いのでしょう？
もちろんメッシュの頂点を指定すれば好きな形状が作成できますが、大量の頂点をコード上で逐一指定するのはあまり現実的な方法ではありません。

そこで、パラメトリック曲面と呼ばれる概念を取り入れます。
この手法はすべての頂点を指定する変わりに、2次元のパラメータを指定することで曲面上の座標を表現し、メッシュの頂点を計算させる方法です。

例えば代表的なものとして、多くのベクターイメージ編集ソフトなどでお馴染みの「ベジエ曲線」を拡張した「ベジエ曲面」があります。
これはベジエ曲線と同様に、制御点を動かすことで曲面の形状を直感的に定義することが可能です。

本セッションでは一般的なパラメトリック曲面の解説とベジエ曲面の解説を行い、曲面を直感的に変更できるところをお見せします。
また、ベジエ曲面の性質や限界、実装上の注意点などについてお話します。

学習管理アプリStudyplusでは、「スマホを隔離して集中して勉強したいけど、勉強の記録もしたい」というユーザーの声が多数寄せられていました。これらの声に対してStudyplusでは、FlutterアプリとApple Watchを連携して、Apple Watchでも記録がつけられるようにすることでユーザーの要望に応えることができました。
この対応にはFlutter、iOS、Apple Watchの3つの環境をまたいだ実装が必要となり、それぞれの連携方法を理解することが重要になります。
本セッションでは、Studyplusでの実際の対応事例をもとに、設計から実装、そして得られた価値まで包括的に解説します。

具体的な内容

• ユーザーの要望の分析や提供したい価値の決定
• どの機能をApple Watchに切り出すかの仕様決定
• Flutter・iOS・watchOS間の実装設計と技術選択
  • WCSessionを使ったiOS・watchOS間のデータ通信・監視
  • Method Channel、Pigeonパッケージを使ったクロスプラットフォーム連携
  • Apple Watchの制約を考慮したUI/UX設計
• 対応によってユーザーに提供できた価値

Apple Watch対応を通じて実際のサービス開発で得られた知見を余すことなく共有し、すぐに活用できる実践的な内容をお届けします。

対象者

• Apple Watch対応を検討中のアプリ開発者
• iOS・watchOSアプリ開発者
• クロスプラットフォーム開発でのネイティブ実装を学びたい開発者

紙のマップは古くから多くの人々に利用されてきました。そして、スマートフォンの登場によりいつでもどこでもマップを確認できるようになっています。

マップに関する機能は、MapKitなど開発者向けのフレームワークとして公開されています。このフレームワークを用いて、マップを活用したアプリケーションが数多く登場しています。特にモビリティ関連のアプリケーションでは、マップによる位置情報の表示が中心的な機能となっており、今や欠かせない存在となっています。

マップを活用したアプリケーションを実装するには、マップの表示技術や緯度経度といった座標に関する知識が不可欠です。このようなマップに関する基礎知識が不足している状態でアプリを実装すると、誤った位置に場所を表示したり、地図上に情報を表示するまでに時間がかかったりするなど、ユーザー体験を損なう原因となります。しかし、これらの知識は開発者用のドキュメントにはあまり記載されておらず、基礎知識がない状態で実装してしまう場合が多いです。

このセッションでは、マップを扱う上で必要な知識を共有しながら、MapKitを使ってマップを活用したスマホアプリの実装例を紹介します。

このセッションで話すこと:

• マップを扱う上で必要な基礎知識
  • どのようにアプリは地図を表示しているのか
  • 座標・緯度経度とはなにか
  • マップで場所を表現するのに必要な要素
  • マップの表示領域と位置情報を表示する量について
• MapKitでアノテーションなどの独自の位置情報を表現して表示する
• MapKitを使った場所検索やルート検索機能の実装

現代のiOS開発において、パフォーマンス向上のために並行処理は不可欠です。
Swift Concurrencyは、async/awaitによる非同期処理の記述を簡潔にするだけでなく、Actorや構造化された並行処理によって、これまで開発者を悩ませてきたデータ競合という危険なバグから、コンパイル時という開発の早い段階で私たちを解放してくれます。
これは、これまでの並行処理技術にはなかった画期的な「コンパイラによる安全保証」という大きな特徴を持っています。

では、Swift Concurrency以前はどうでしょう？
例えばGCDやOperationQueue、さらにはNSThreadといった技術はどれほど簡潔ではなく安全ではなかったのでしょうか？
これらの技術は、スレッド管理を抽象化したり、排他制御の基礎機能を提供したりはしましたが、その安全性は常に開発者自身の厳密な規律に依存していました。
一つでも排他制御を忘れると、予期せぬクラッシュやデータの破壊を引き起こすリスクに常に晒されていたのです。

このトークでは、この並行処理の歴史を、現代のSwift ConcurrencyからNSThreadへと遡りながら、その安全性の進化を比較・解説します。
シンプルなカウンタからファイルダウンローダーを例にSwift Concurrency、OperationQueue、GCD、NSThreadの実装例をお見せします。

Swift Concurrencyが目指している安全性を歴史から学び、自信を持ってコードが書ける一助になれば幸いです。