トーク

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 との比較）まで深掘りします。

アプリ開発において、ユーザーの操作を極力減らし、よりスムーズで摩擦の少ない体験を提供したいと考えたことはありませんか？

UWB（Ultra-Wide Band）は、ナノ秒単位で到達時間を計測することにより、高精度で距離と方向を取得することが可能です。
iOSでは、Nearby Interactionフレームワークを利用してこれらのデータにアクセスできます。この技術により、以下のようなタップレス操作が可能になります。

• デバイスが近づいただけでチェックインを開始
• 画面に触れずにデバイスを操作
  など、まるで魔法のようなタップレス操作が実現可能です。

しかし、DiscoveryTokenの共有方法やセッションの開始・維持など、通常のアプリ開発ではあまり馴染みのない実装が多く、これがハードルと感じるかもしれません。

本セッションでは、UWBの基本的な知識から、Nearby Interactionを用いた具体的な実装方法をデモを交えて紹介します。
さらに、実装時のハードルを下げるためのTipsもご紹介いたします。

このセッションを通じて、“タップレスなアプリ開発” の第一歩としてNearby Interactionフレームワークの可能性を探ってみませんか？

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の最適化に取り組んでいる方に特におすすめのセッションです。

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を統合する側」へと進むための実践的な知識と視点をお届けします。

WebPは、画像に対する高品質な可逆圧縮と非可逆圧縮を実現する、モダンな画像形式です。
WebP画像形式は同品質のPNG画像より約23〜26%小さく、非可逆圧縮の場合はJPEG画像より25〜34%小さくできるため人気の画像形式です。

iOS 14から標準でWebP画像の読み込みがサポートされ、UIImageで直接WebP画像を扱えるようになりました。

では、今から新しくWebP画像を扱うライブラリを作るということは無意味でしょうか？いいえ、そんなことはありません。自分で作るという行為は動作の原理や仕組みを学ぶことに非常に優れた手法です。

学習だけでなく実用の面でも、自作の場合は特定のユースケースに処理を最適化してパフォーマンスを発揮したり、標準のライブラリで発生する問題を回避できます。特にiOS 18では標準の方法では特定のケースでパフォーマンスが大きく悪化する問題があることがわかっています。

この講演ではWebPファイルフォーマットの基本仕様と構造、Swiftで構造を解析する方法、画像を圧縮する技術の原理と仕組みをステップバイステップで実際のコードを用いて解説します。

WebPのコーデックを実装することは「画像圧縮の理論」「ビット操作の職人技」「高速化・安全化の実務」を一気に学べる実践的な場です。特にSwiftで実装する場合は安全なメモリ管理と低レベルの最適化の両立というノウハウまで得られます。

普段のプログラミングとは一味違う、低レイヤーの実装を楽しんでみませんか？

エッジ 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 の活用

本セッションでは、位置情報アプリを開発しているアプリエンジニア、または位置情報技術に興味を持つ方を対象とし、位置情報の「精度」や「時刻の取り扱い」について解説します。
スマートフォンで取得できる位置情報は、地図アプリ、交通サービス、IoT、防災など、日常生活を支える多くのアプリで活用されています。しかし、その位置情報がどのような仕組みで得られているのか、特に時刻情報がどのように関わっているのかについては、普段意識することが少ないかもしれません。

本セッションではまず、古代より人類がどのように時刻を求めてきたかを述べ、位置と時刻を求める人類の挑戦として、18世紀イギリスで制定された「経度法」と、それにより始まった経度問題の解決に向けた競争、そしてジョン・ハリソンによる海洋クロノメーターの開発を振り返ります。次に、電波を使った測位方法の歴史と、GPSをはじめとするGNSS（全地球測位システム）の基本原理を解説し、衛星信号を用いて端末の位置を特定する仕組みを解説します。

さらに、GNSSの生データを取得・解析するための専用ツール「GNSS Logger」と「GNSS Analysis」を活用し、端末が捕捉している衛星の数や種類、方向、信号強度といったデータを可視化します。これにより、都市環境でのマルチパス反射、大気遅延（電離層・対流圏）、衛星の配置や補足数不足といった精度劣化要因が、どのようにデータに現れるのかを具体的に解説します。

最後に、センチメートル級の高精度測位の仕組みと、それがもたらす未来の可能性についての展望を語ります。
聴講後には、位置情報と時刻情報の本質的な関係を理解し、位置特定にまつわる歴史と技術の知識が身につきます。

多言語対応をしていると、いつかはRTL（Right To Left）言語、つまり右から左に書く言語への対応が必要になる場面に出会います。私が担当しているiOSアプリでもその対応が求められました。

ではRTL言語対応って具体的に何をすべきかご存知でしょうか？iOSでは、OSやフレームワークによってある程度「自動対応」がされます。しかし、UIの崩れ、画像の反転、レイアウトの意図しない挙動など、エンジニアが「手動対応」しなければいけない場面も存在します。

このトークでは次のような観点から、私が調査、実装をしたRTL言語対応の知見を共有します。

• そもそもRTL言語対応とはどんなものか
• RTL言語対応に関するAppleの公式情報をおさらいしてみる
• OS、フレームワーク側が「自動で」してくれるRTL言語対応
• エンジニアが「手動で」頑張るRTL言語対応
  • レイアウト修正
  • 画像修正
  • その他思わぬ落とし穴
• 対応状況をどのように確認するか

このトークを聞けば、初めてRTL言語対応に取り組む方でも迷わず対応できるでしょう。逆向きUIの世界、覗いてみませんか？

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も共有します。

iOSアプリにおいて Bluetooth 接続のレシートプリンターで印刷するにあたって、私は各メーカーのSDKに頼らず、 Foundation Framework に含まれる Stream API を使用したアプローチを採用しています。
複数メーカー製プリンターを共通の仕組みでサポートするためのプロトコルを定義し、 OutputStream に印刷データを書き込むことでレシート印刷を実現しました。

この方法は、各メーカーSDKの仕様変更や機能差異に左右されにくいという大きなメリットがあります。
一方で、 Stream API の仕組みや Bluetooth を使用したiOSアプリとレシートプリンター間通信の特徴を正しく理解していないと、私が実際に経験したように「印刷が途中で止まってしまう不具合」に遭遇することもあります。

本トークでは、レシートプリンターとの通信に必要な Stream API の基本知識を整理しつつ、複数メーカー製プリンターを共通の仕組みで制御する方法、そして印刷が途中で止まってしまう不具合の対処法について具体的に紹介します。

トーク内容
・Stream API でバイナリデータを送受信する方法
・レシートプリンターの特徴と Bluetooth 接続方法
・レシート印刷に必要な技術的な構成
・複数メーカー製プリンターをサポートする仕組み
・印刷が途中で止まる不具合と Stream.Event を用いた対処法

本トークは、iOSアプリでレシート印刷をしたことがない方はもちろん、これから実装したいと考えている方にも楽しんでもらえる内容です。
本トークのテーマであるレシート印刷の内容を通してバイナリデータ通信全般に応用できる技術知見をお届けします！