トーク

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 を実践的に導入していく方法を学ぶことができます。

Swift Evolutionで提案される新機能を見ているうちに、自分でも言語の基礎を理解したいと思い、簡単な言語をSwiftで作成することに挑戦しました

このLTでは、プログラミング言語の開発フローにおいて、構文解析フェーズにおける構文木（AST）の設計と実装に焦点を当てて紹介します。
構文木（AST：Abstract Syntax Tree）は、ソースコードの文法的な構造や意味を階層的に表したもので、言語処理において重要な役割を担っています。

Swiftのenumのパターンマッチやassociated value、structによる明確なデータ構造を活かすことで、構文の意味を型として表現したASTを実装しました。

発表では、構文解析のプロセスをステップバイステップで解説し、具体的なコード例を通じてASTの構築方法を紹介します。
必要最小限の機能ですが、言語設計における本質的な考え方に触れられると思います。

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

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 の特徴である堅牢さ、型安全性、高パフォーマンスを備えたこの値の監視の仕組みを理解し、普段のアプリ開発に活用してみましょう。

運用中のプロダクトでデータ基盤を大幅に変更する必要が生じたとき、どのようにリスクを最小化しながら移行を進めますか？
本トークでは、月間アクティブユーザー数万人規模のiOSアプリで実際に行ったFirestoreからの大規模データ基盤移行プロジェクトの実践事例をお話しします。

特に以下の課題にフォーカスして解決策を紹介します：

• 新機能開発を止めずに基盤移行を並行実施する方法
• ユーザーへの影響を最小化しながら段階的に切り替える仕組み
• 移行中の不具合を早期発見・切り戻しできる安全装置の設計

技術的なポイント：

• Feature Flagによる動的なデータソース切り替えアーキテクチャ
• 旧新システムの型安全な分離

このトークを聞くことで、大規模な基盤変更プロジェクトを安全に進めるための具体的な手法と、実際の運用で直面した課題とその解決策を紹介します。特に、チーム開発やプロダクト成長を止めることなく技術的負債を解消したいiOS開発者の方に役立つ内容です。

「とりあえずTaskで囲んでみたけど、これで本当に良いんだろう？」
「@MainActorを付けたらエラーは消えた。でも、なぜ？」
Swift Concurrencyを学び始めた頃、私はそんな"なんとなく"の不安でいっぱいでした。その一行に、確かな「なぜ」を答えられますか？ このトークは、過去の私と同じように非同期処理の前に立つあなたのためのセッションです。新卒2年目の私だからこそ、ベテランが通り過ぎてしまう初学者の「なぜ？」に光を当て、"なんとなく"を"確かな意図"に変える旅にご案内します。

このセッションでは、よくある"なんとなく"なコードが、なぜ問題なのか、そしてどうすれば「意図を持った」コードになるのかを、具体的なシナリオと共に解き明かします。

• async/awaitの価値: "コールバック地獄"から、上から下へ読める素直なコードへの変革
• Taskの責任: "野良タスク"の危険性と、TaskGroupによる責任ある並行処理
• Actorという金庫: Data Raceから共有データを安全に守る具体的な方法
• Sendableという通行証: 意味不明なエラーから読み解く、コンパイラの意図
• @MainActorという誓約: "お守り"ではない、UI更新の掟を守るための神聖なルール

このトークが終わる頃、あなたは「"なんとなく"」書いていたコードに、確かな「意図」を込められるようになっています。明日からのプロジェクトで即実践できる非同期処理の書き方を身につけましょう。

「痩せたい！」と考えている方々へ、シンプルで効果的なカロリートラッキングアプリを自作してみませんか？
多くの市販アプリはアカウント登録やサブスクリプションが必要ですが、自分のニーズに合わせたアプリを作ることも可能です。

このトークでは、SwiftDataとCloudKitを活用して、バックエンドの負担や費用を気にせず、Appleアカウントで簡単にデータを同期させる方法をご紹介します。

• SwiftDataとCloudKitのセットアップ手順
• SwiftData/CloudKitを使用する際の注意点と選択時に知っておくべきポイント

このセッションを通じて、あなたのアプリ開発を一歩前進させましょう。

「Human Interface Guidelines (HIG)、重要だとわかってはいるけれど、全部読むのは大変…」
多くのiOS開発者が一度は抱えるこの悩み。私たちのチームも例外ではなく、UI実装の際に「これで本当に良いんだっけ？」と自信が持てなかったり、他職種とのコミュニケーションで認識の齟齬が生まれたりする課題を抱えていました。

iOSエンジニアとして、イケてるアプリを作るにはプラットフォームへの深い理解が不可欠です。
そこで、私たちはiOSメンバー全員でHIGの輪読会を始めることにしました。

本セッションでは、この輪読会を企画・運営した経験を元に、チームでHIGを学び、開発に活かすための具体的なノウハウをお伝えします。

【本セッションでお話しする内容】

• HIG輪読会を開催するに至った背景・目的
• HIG輪読会を無理なく進めるための運営方法
• HIG輪読会の成果とメリット
• 「実はHIGにこんなことが書かれている！」興味深いトピックの紹介
• HIG輪読会ならではの課題点と改善策

このセッションを通じて、「自分のチームでもやってみたい！」と思っていただけるような、輪読会を始めるための具体的なノウハウとモチベーションを持ち帰っていただければ幸いです。

App Intents フレームワークは、Shortcuts、Spotlight、Siri、Control Center、Widgets など、iOS 全体とアプリをつなぐ「共通言語」としての役割を担う存在となっています。
WWDC 2025 でもアップデートがあり、さらに Apple Intelligence でも活用可能になることが発表された今、App Intents を理解し、活用方法を学んでおくことは非常に重要です。その重要性は多くの開発者が感じていると思いますが、実際には、気になってはいたけどあまり触れられていないという方も多いのではないでしょうか？
App Intents を活用することで、アプリが起動していなくてもユーザーとつながることができる仕組みを実現できます。アプリが開いている状態に依存しない価値提供が当たり前になる中で、App Intents を取り入れたアーキテクチャは、AI 連携を含む今後の拡張性とも自然に結びつくと感じています。
本トークでは、Shortcuts、Control Center、Widgets など実際に対応してみた中で得られた知見をもとに、 App Intents の設計や使いどころを実装例を交えながら、お話しします。

• App Intents の基本的な実装方法と構成要素
• 開発中に直面したはまりポイントとその回避法
• App Intents をアプリ開発においてどう位置づけるか？
• 複数の機能間で再利用しやすい App Intents 設計の考え方
• Apple Intelligence 時代に向けて今やっておくべきこと

このセッションを通じて、実務にすぐ活かせる具体的な設計のヒントと、Apple の目指す未来に対応するための考え方をお持ち帰りいただければと思います。

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

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

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

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

アプリ内課金は、アプリの中でユーザーに商品を購入してもらう仕組みです。アプリ外のウェブサイトなどで行う課金に比べて、ユーザーがシームレスに課金できるため、アプリにとって重要な収益源となることが多いです。

iOS のアプリ内課金の実装には、Apple が提供する StoreKit ライブラリを使用します。iOS 18 からは original StoreKit API が非推奨になることが発表され、StoreKit 2 への対応を進めた方も多いのではないでしょうか。StoreKit 2 では毎年新たな機能やAPIが追加されています。

本トークでは、WWDC 2024 以降に発表されたアプリ内課金の最新アップデートについて解説します。例えば、
・Win-back などオファーの多様化
・テスト機能の拡充
・購入したアイテムを別の Apple Account に移行
などです。私自身が開発中に気付いた変更点や挙動についても共有します。

このトークを通じて、参加者の皆さんは最新のアプリ内課金機能を理解し、新しいオファーを使った企画やテストの実施に役立てることができるようになります。

2025年、私にとっての大きな転機が訪れました。キャリアのほぼ全てをAndroidアプリに捧げていましたが、この度 iOSアプリエンジニアに転身しました！

私の所属するプロダクトでは、Android版・iOS版の両方でアプリを提供しています。
Androidチームにジョインしてすぐ、当時のPMからのiOSにも興味ありませんか？というほぼ冗談みたいな問いに対して、「挑戦できる機会があればいつでも！」と前向きな回答をしましたが、まさかの数年越しにiOSチームへの転身が実現してしまいました。やったことがないことは基本やりたいというスタンスで生きてきましたが、こんな事態になるとは思ってませんでした。

さて、iOSアプリエンジニアに転身したのは今年ですが、同じ年に目覚ましい発展を遂げた技術としてLLMが挙がるかと思います。
LLMを活用することで、Androidアプリの知識をからiOSではどう実現できるかの情報を紐づけることができたり、iOSアプリエンジニアならではのカルチャーを知ることができる貴重な情報源となりました。時にはXcodeの難解なエラーコードの解読をしてくれたり、コードを渡せばリファクタリングコードを提案してくれたりと非常に心強い味方です。
しかし、初学者のうちは精度の高い回答を引き出し切ることはできません。これに固執せず、Androidアプリ開発を含めた今までの経験を武器に、iOSチームメンバと協力し課題解決に挑むことがとても大切です。

このセッションでは、LLMを活用しながら、Androidアプリ開発の経験をどのようにiOS開発に応用しているかについてお話しします。私の経験が、「AndroidエンジニアがiOSへの挑戦に踏み出す勇気づけ」や「iOSエンジニアが自身の開発を見直すきっかけ」になれば幸いです。

ゲームディレクター・デザイナーが「軽量」「摩擦少」「最小人数」でプロトタイピングできるかどうかが、斬新なコンセプトの成功や事業実装に直結するのです。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 との比較）まで深掘りします。

ーーー時は令和7年、そこには決して負けられない戦いがあったーーー

SwiftUIが初登場して2年後に出たiOS15。かなり使いやすくなったかと思いきや、サポートするにはまだ不便な部分も多く、数多の検証を繰り返しながらようやくサポートすることができました。

とはいえ、現時点でなんとXcode26 Beta2 Release Notesに、「The Xcode 26 beta 2 release supports on-device debugging in iOS 16 and later」と書かれています。

お疲れ様の気持ちを込めて、時にUIKitの力を借り、時にデザインの調整を行い、時に妥協案を考えながら、iOS15をサポートするために実践した泥くさい戦いの軌跡について語ります。

チーム開発において、一貫性はとても大切です。
一方でルールを運用していくのは大変で、生産性を悪化させるリスクもあります。

そのバランスのため、多くのチームでLinter, Formatterなどを使って一貫性を担保していると思います。
しかし、インデントやimport順といった一般的なルールは簡単に適用できても、
ドメイン依存など、凝ったルールを導入したいケースでは工夫が必要です。

shellなどのカスタムスクリプトによって実現しているチームも多いと思いますが、
AIの流行もあり自動化ツールの実装コストも大幅に下がってきているため、
より凝ったツールを作る時代が来ています。

かつてxcodeprojのコンフリクトに困らされた我々は、XcodeGenによる生成に助けられました。
今そのコンフリクトはなくなったものの、Package.swiftは依存やターゲットを手動更新せねばなりません。
そのため追加忘れ・削除忘れ・重複をはじめ、並び順やグルーピング、推移的依存をどこまで書くかなど、
linterでは対応しきれない揺れや負債が多く生まれます。

弊社のiOSチームではgo modulesに学び、swift-syntaxを活用したスクリプトによって、Package.swiftを自動で更新しています！
完全ではないのですが、Swiftファイルを記述するだけでターゲットやその依存関係が自動的に追記・削除されるようになっています。

とっつきにくいイメージのswift-syntaxですが実装にも触れつつ、このスクリプトのアイデア・実装例をご紹介いたします。

「誰もやらないなら、自分がやる。」
大学生活の中で感じた不便さを解決するため、学内情報を一元化するiOSアプリ「トクメモ＋」を開発しました。これは、ログインのたびにID・パスワードを何度も入力させられ、講義、レポート、図書館など、バラバラに存在する大学の情報を“毎日使いたいもの”としてまとめあげたアプリです。

結果としてこのアプリは、学部生の60%以上（月間3500MAU）に使われる学内最大のアプリとなり、自分の手を離れることが決まりました。
しかし、そこに至るまでには数えきれないほどの失敗と学びがありました。

このセッションでは、個人開発からチーム運営、そして譲渡に至るまでの過程で直面した3つの失敗談と、その乗り越え方をお話しします。

① 大学からのサポートがないからこその落とし穴
ログイン処理が無限ループする致命的なバグや「URLをまとめれば便利」と思った設計が、唐突な仕様変更で崩壊。
仕様が不明な環境で、何を頼りに設計すればよかったのか？ 実例をもとに振り返ります。

② 学生開発チームならではの壁
広報と開発を分担した11人の学生団体は、いつしか“熱意はあるけど動かない”チームに。やがて団体は解散し再び立ち上げたのは、「やってほしいこと」ではなく、「やりたいこと・できること」を尊重する体制でした。 学生開発チームを動かすために必要だった視点をお話しします。

③ 属人化が生んだ“引き継げないアプリ”
コードが複雑化しすぎて、「開発したい初学者がいても触れない」と気づいたとき、iOSアプリを作り直す決断をしました。Keychainやオンボーディングなど技術面の引き継ぎ課題に対して何を諦めたか。引き継ぎの“壁”と“選択”の話をします。

順調な成功談ではなく、「ちゃんと失敗した話」から得たリアルな知見を、学生・個人開発者・引き継ぎに悩む方々へお届けします。

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

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

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

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

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

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

WAVファイルのバイナリフォーマットを知り、Swiftを使ってゼロからWAVファイルをつくってみましょう。

iOSで録音される音声データを調査する中で、WAVファイルに触れる機会がありました。
音声データを数値に変換し、ひとつひとつの音を決まったフォーマットで組み立ててWAVファイルを完成させるまでの過程をご説明します。

このセッションは以下のような内容を含む予定です。
・音声データとリニアPCM
・WAVファイルのバイナリフォーマット
・エンディアン
・SwiftのDataからファイルを構成する
・WAVファイルをリアルタイムで組み立てる
・波形を確認する

トークを通じてバイナリデータに親しむことで、いつも扱っているファイルをより自由にいじれるようになりましょう！

モバイルアプリ開発において、ユーザー行動を把握し改善に繋げる上でイベント計測は不可欠です。
しかし、その恩恵を最大限に受けるためには、イベント名やパラメータ名をアプリコードに正確に実装する必要があります。
この「実装」のプロセスが、いかに退屈で、手作業によるミスが生まれやすく、そして長期的なメンテナンスにおいて多大なコストを要するか、多くの開発者が経験しているのではないでしょうか。

私達はこの長年の課題を解決するために、イベント定義（イベント名、パラメータ名）を記述したCSVファイルから、Swiftのenumコードを自動生成する社内ライブラリを作りました。
まず、スプレッドシートやエクセルでイベント定義を書き、それをCSV形式で出力します。そのCSVをツールに渡すだけで、イベント定義がSwiftのコードに反映されます。
手作業での文字列定義やタイプミスから解放され、イベント実装の速度と正確性を飛躍的に向上させることができるのです。

【話すこと】

• イベント実装を手作業で行う退屈さ・リスク
• ツールでできること・できないこと
• ツールの技術的解説
  • CSVパースからenumコード生成までのプロセス
  • Packageとしての実装のポイント
• ツール導入により得られた結果（コードの安全性向上、新機能追加時のイベント定義・実装コスト削減など）

このセッションを通じて、イベント定義・実装にまつわる退屈な作業から解放され、より本質的な開発に時間を費やしたいと考えるiOS開発者の皆様に、具体的な解決策と新たな視点を提供できれば幸いです。

ネイティブアプリ開発において、ユーザーが「迷わず」「快適に」「自然に」操作できるUXを実現することは重要です。

しかし、なぜユーザーは特定のUIでつまずくのか、なぜこのデザインが使いやすいのか、その背後にある心理メカニズムを理解していますか？
本セッションでは、認知心理学の基本と、ユーザーの脳や行動の仕組みを活用した実践的UIデザインテクニックを解説します。

特に、体験全体の印象操作、モチベーション維持 、ボタン配置の最適化など、アプリUI/UXの具体例を交えながら、明日から実践できる「ツボ」を伝授します。

これらの原則は、ユーザーの認知負荷を軽減し、直感的な操作感を高める上で非常に強力です。
セッションのゴールは、参加者の皆さんが、自身の開発アプリのUI/UXをユーザーの認知プロセスに基づいて見直し、より魅力的でストレスの少ない体験へと改善するための具体的な思考フレームワークとヒントを持ち帰ることです。

さあ、認知心理学の知見で、あなたのアプリを「ユーザーに愛されるアプリ」へと一歩進化させましょう！

AppleのWWDCをはじめ、世界にはiOS開発者向けの国際カンファレンスがたくさんあります。今年4月には、私自身も英語トークが推奨される「try! Swift Tokyo 2025」に登壇する機会を得ました。

私はいわゆる「英語初心者」で、登壇準備では発音練習、原稿作成、スライド構成にかなり苦戦しました。しかし、同時に大きな成長と達成感があり、「もっと挑戦したい！」と思える経験になりました。

現在では、AIをはじめ英語学習の方法も大きく変わってきています。

このLTでは、以下のような私が実際に使った英語登壇のためのTIPSを紹介します。

• 短いセンテンスで原稿を作るコツ
• 発音練習の方法
• AIや音声生成ツールの活用法
• 英語学習にオススメのポッドキャストチャンネル
• オンライン英会話レッスンの利用方法

英語登壇に興味があるけれど「英語だから無理」と思っている方へ。「完璧じゃなくてもいいから、一歩踏み出してみる」そんな勇気を持ってもらえる5分にしたいと思います。

私もまだまた挑戦中ですが、一緒に一歩を踏み出してみましょう！