トーク

Live Activity は、ロック画面や Dynamic Island にリアルタイム情報を表示できる機能です。iOS 16 で登場してから毎年改良が進み、対応デバイスも拡大してきました。この機能を使用することで、ロック画面に自由な表示を行うことができるので、うまく活用することができればユーザーの利用率拡大を図ることができます。

Live Activity はリアルタイムに動くシステムのため、考慮する事項はクライアントからバックエンド、通知サーバーに至るまで多岐に渡ります。Live Activity はその考慮事項の多さから、安定的に運用するために様々な対応が必要となります。

Live Activity を最小コストで安全にリリースするために必要な下記のトピックなどを紹介します。

Live Activity の開始方法・更新方法の選択
Live Activity 利用状況の監視
Live Activity を表示している際のアプリライフサイクルの変化

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

SwiftUIのモダンで宣言的なAPIは、UI実装を効率的かつ楽しいものにしてくれます。
一方で、iOSのメジャーバージョンごとの機能差異も多く、今までUIKitで実現されていた複雑なUIを同じように実装するためには工夫が求められる場合もあります。

このセッションでは、約10年にわたって開発されてきたアプリの中の様々なUIをSwiftUIに移行してきた経験から、複雑なUIをどうSwiftUIで実現するか・SwiftUIで実現できないUIの回避方法など、大規模かつ多くの世代のiOSをサポートするアプリで使っている具体的・実践的なノウハウをご紹介します。

• SwiftUIの得意なところ・苦手なところ
• iOS 15やiOS 16など、過去のiOSバージョンもサポートするためのポイント
• UIKitの使いどころ、UIKitとSwiftUIの連携パターン
• ニッチなSwiftUI APIの活用事例

私たちのチームでは、iOS・Androidモバイルアプリの実装共通化のため、2020年頃からKotlin Multiplatform（KMP）の検証を開始し、段階的に導入を進めてきました。現在では、サービスの中心となるコンテンツを視聴する画面の多くの実装がKMPによって共通化されている状態になっています。

マルチプラットフォーム開発の選択肢としてKMPが注目される一方で、長期にわたり大規模なサービスで運用してきた事例は多くありません。本セッションでは、私たちのチームにおけるKMP導入と運用の約5年間を振り返り、以下のようなトピックについて具体的な事例を赤裸々にご紹介します。

• KMP導入の背景とプロセス、直面した課題
• チームの実装効率は向上した？
• UI、ロジック、通信…どこまで共通化するべき？
• KMPを活用しながら、Swift 6の新機能やSwiftUIの導入をどのように進めたか
• KMPは他のチームや開発者へおすすめできる？

KMPの導入を検討している方・実際に使われている方はもちろん、アプリ開発へのマルチプラットフォーム技術の導入に関心のある全ての方の参考になるように、具体的で実践的な事例をお話しします。

Swift Evolutionを眺めているうちに、「言語ってどうやって作られてるんだろう？」と気になり、試しにSwiftでシンプルな言語を作ってみました。

今はAIがコードを書く時代になってきていますが、依然として言語の仕組みを理解し、自ら構造を設計できる力は変わらず重要だと感じています。

このセッションでは、Swiftで簡易的なプログラミング言語を自作したプロセスを、字句解析、構文解析、意味解析という基本ステップに沿って紹介します。
字句解析では、Swiftのenumを使ってトークンの種類を定義し、文字列を順に読み取って意味のある単位に分解する処理を組み立てました。構文解析では、indirect enumとstructで抽象構文木（AST）を表現し、演算や代入といった構文を再帰的に解析することで実現しました。意味解析では、Dictionaryを活用して変数名と型情報を管理し、スコープごとに構造を持たせながら、型の整合性や未定義変数の検出といったチェックを行う仕組みを構築しました。

発表の最後には、自作したミニ言語も軽くお見せします。素朴な言語ですが、作る過程で得られる学びは深く、きっとコードの書き方や読み方が変わるはずです。

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

日々の開発でデザイナーさんとの会話の中で「HIG的には〜」と口にすることはあっても、果たしてその意味を深く理解できているでしょうか。HIG（Human Interface Guidelines）は、単なるデザインガイドラインではなく、Appleが長年培ってきたユーザー体験への思想と普遍的な原則が凝縮されたものです。

本セッションでは、HIGの核心となる原則に触れ、なぜHIGを遵守すべきなのか、なぜ守ると良いのかということを今一度考えて行きたいと思います。
いくつかの標準コンポーネントを例に、その裏にある意図や思想について触れ、日頃使っているものがどういった思想から形作られたのかを一通り理解した上で遵守することができれば、HIGに対する解像度を一段階上げることができると考えています。

本セッションを通じて、HIGに対する解像度を一段階引き上げ、デザイナーとの円滑な連携はもちろん、自信を持って「ユーザーにとって本当に良い」UI/UXを考えるきっかけになれば幸いです。

皆さんは Swift ちゃんと仲良く日々を過ごしていますか?

エディタで真っ赤なエラーを何回も吐かれたり、 Swift Concurrency に苦しめられたり… ギスギスしている方もいらっしゃるかもしれません。
そんな時は、 Swift ちゃんのことをもっと知ってあげましょう！

本トークでは、「Swift を使う」から一歩踏み出して、「Swift という言語そのもの」に注目します。
普段から Swift のコードを書いていても、内部構造やコンパイラの仕組みは「ブラックボックス」と感じがちですが、内部構造をざっくり理解しながら、Swift にコントリビュートする方法をステップ • バイ • ステップでご紹介します。

気に入らないエラー文を改善するもよし、既存の Issue から興味のあるものを選ぶもよし、敷居が高く見えてもコントリビュートする上では色々切り口があります。
OSS に初挑戦してみたい方や、Swift をもっと知りたい中級者に向けて、「Swift ちゃん」との距離を縮めるための第一歩をお届けします。

本トークでは、以下の内容についてお話します。

• Swift の中はどうなってるの？
• ローカル環境セットアップの手順
• エラーメッセージを実際に変えてみる
• Swift へのコントリビュートの始め方
• 簡単な実装を通じて得た感想と学び

WWDC25で発表されたAppleのFoundation Modelsフレームワークにより、iOSアプリにおけるオンデバイスLLMの利用が現実的な選択肢となりました。
さらに、llama.cppやMLX、ONNX Runtimeなどのオープンソースプロジェクトの進化により、iOS上でのローカルLLMの可能性はますます広がっています。
iOSアプリエンジニアにとって、今がまさにLLMについて理解を深める絶好のタイミングです。

そこでこのトークでは、ローカルLLMに関して以下のトピックを中心に解説します。

•Foundation Modelsフレームワークを用いたローカルLLMの活用
•LLMのコア技術であるTransformerの仕組みと、それがチャット、マルチモーダル、ツール呼び出しといった機能をどのように実現しているか
•llama.cppやMLX等の仕組み、モデルフォーマット、量子化、最適化手法などの解説
•各技術のパフォーマンスや互換性の比較と、技術選定の指針の共有

LLMの仕組みや主要フレームワークの特徴を理解し、適切な技術選定や設計をすることで、
より優れたユーザー体験を実現しましょう！

iOS18で搭載されたApple Intelligenceの作文ツール(Writing Tools)やWWDC25で発表されたFoundation Models Frameworkなど、iPhoneにはAIによって作文や要約、公正をすることができる機能・方法が存在します。
これらの機能・方法は基本的にはオフラインで動作することで、ユーザーはプライバシーを守りながら文章力を劇的に向上させることができる強力なものです。
ですが、強力な機能であるにも関わらず作文ツールへの導線はユーザーへは伝わりづらかったり、Foundation Models Frameworkで自前実装をすべきなのか悩ましいのではないでしょうか？

本セッションでは、iPhoneで利用することができる作文関連のAIについて、

• 各機能・実現方法の紹介
• 特徴や制約の解説
• 各機能・実現方法の比較

をお話しします。
このセッションを通じて、あなたが作文ツールをよりユーザーに利用していただきやすくなるようにアプリへ組み込んだり、Foundation Models Frameworkを用いて補完的に実装を行うべきかの検討ができるようになることを目指します

あなたのアプリユーザーのAI作文体験を向上させましょう！

近年よく「成長機会」「開発者体験」「イノベーション」などのワードを耳にすることがあると思いますが、あなたの組織ではこれらに対して取り組むことができているでしょうか？

私の所属している株式会社kubellのiOSアプリ開発グループでは、今年から「学びラボ」という新たな取り組みを開始しました。
『学びラボ』とは「通常業務とは離れて興味のある内容を自由に学ぶことができる日」を新設し、iOSメンバーの成長機会創出や、学習したことや得たアイデアなどによる業務への貢献、学びの発信による採用ブランディングなどを期待した取り組みです。
この取り組みにより、iOSエンジニアが作成したプロトタイプの機能が実際のプロダクトへ取り込まれたり、学んだことを外部登壇で発信したりといったような成果が出ています。

本セッションでは『学びラボ』について

• きっかけや立ち上げ
• 運用方法や取り組みの様子
• 実際に取り組まれた内容・テーマ
• 得られた効果(事例や定量的な計測結果、他職種とのコラボレーション)
  などについてお話しします。

組織として成長機会の創出や開発者体験向上、業務改善を推進したい方は必見です！

運用中のプロダクトでデータ基盤を大幅に変更する必要が生じたとき、どのようにリスクを最小化しながら移行を進めますか？
本トークでは、月間アクティブユーザー数万人規模の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 の目指す未来に対応するための考え方をお持ち帰りいただければと思います。

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

そのバランスのため、多くのチームで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やオンボーディングなど技術面の引き継ぎ課題に対して何を諦めたか。引き継ぎの“壁”と“選択”の話をします。

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

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

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

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

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

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

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

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

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

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

デジタルプロダクトの成功には、ユーザー体験の最適化が欠かせません。そこでよく用いられる手法の一つに A/B テストがあります。
A/B テストは、Webサイトやアプリなどで、異なるバージョン（バージョン A と B）をユーザーにランダムに表示し、どちらのパターンがより効果的かを検証する手法です。新しい機能や、既存の機能を削除した時の影響を定量的に評価することができます。

一見簡単そうに思える A/B テストですが、適切に実施することは難しく、様々な罠が潜んでいます。例えば、ユーザーに表示するバージョンをサーバーから取得できない時、どちらかのバージョンにフォールバックしてそのログを送信してしまうと、結果にバイアスがかかってしまいます。このように、アプリ側の実装によって A/B テストが失敗してしまうことがあります。

本トークでは、A/B テストの基本的な考え方と、アプリでの実装・実施時に気をつけた方が良い点を、実体験を交えながらお話します。A/B テスト結果の具体的な分析方法についてはお話しません。
参加者はこのトークを聞くことによって、A/B テストの設計とアプリ実装時の注意点を学ぶことができます。

私たちのiPadアプリはリリースから約15年が経過し、長年の機能開発の結果、技術的負債を抱えるに至りました。
具体的には、

• 肥大化した "Fat ViewController" が多数存在し、改修時の影響範囲の特定を困難にしています。
  • シングルトンやAppDelegateへの過度な依存が、クラス間の密結合を生み出しています。
  • 上記の結果として、ユニットテストを書くことが極めて難しい、あるいは不可能なコードベースとなっています。

また、コードの大部分は歴史的経緯からObjective-Cで書かれており、今後の採用観点からSwift化への置き換えとこれらの負債を解消しながらが大きな課題です。
本セッションでは、これらの技術的負債に対し、日々の機能開発を止めることなく、いかにして立ち向かっているか、そのアプローチを共有します。

主にお話しする内容：
Fat ViewControllerの分割戦略: 巨大なViewControllerの責務を、Presenter/ViewModel//UseCaseといった単位へ安全に分割していくか、具体的なリファクタリング手法をコードと共に解説します。
依存関係の解消プロセス: DI（依存性注入）の考え方を導入し、AppDelegateやシングルトンへの直接参照をどのように剥がしていくか、その段階的なプロセスを共有します。
テスト可能なコードへの改善: 既存のコードにユニットテストを追加するための、インターフェース導入や副作用の分離といった具体的な手法を紹介します。

このセッションを通じて、同様の課題を抱える開発者の皆さんが、明日から自身のプロダクトで試せる具体的な一歩を踏み出すための、現実的な選択肢と知見を持ち帰っていただくことを目指します。