トーク

本セッションでは、Live Activityに現在駅と次駅を表示するiPhoneアプリを一緒に作りながら、乗客がアプリを開く必要のない体験を実現します。その道中でCore Location、Core Motion、ActivityKit、SQLiteなどのフレームワークを使います。

1. データ収集
   まず、実際のGPSデータを収集する専用iPhoneアプリを実装します。

2. アルゴリズムのブラッシュアップ
   収集したデータを用いてリアルタイムに予測を行う純粋アルゴリズムを開発します。検証のために、シミュレーションデータを再生できるmacOSアプリを用意します。

3. バックグラウンド対応アプリの開発
   本番のアプリではCore Locationの「signficant change location service」を利用して自動的に起動し、バックグラウンド位置取得でアルゴリズムにデータを供給し続けます。

4. 自動的に開始・終了するLive Activityの実装
   プッシュ通知サーバを使い、バックグラウンドからLive Activityを開始・終了させます。これにより、乗車の開始と終了に合わせてLive Activityが自動的に表示・非表示を切り替わり、ユーザはアプリを開く必要がありません。

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の活用事例

SwiftUIをメインで使っているプロダクトでは、デザイナーやPdMとのやり取りで誰もがこんな経験をしたことがあるのではないでしょうか。

👩‍💼： 「この機能、〇〇アプリみたいなUIにしてください！」
🧑‍💻： 「了解です〜！」
（実装中・・・）
🧑‍💻： 「iOS 15や16だとちょっと上手く動かないんですよね…」
👩‍💼： 「えっ、〇〇アプリではできてますよ？」
🧑‍💻： 「ちょっとやり方変えてみますね…（仕方ない、UIKitを使うか…）」

SwiftUIは年々進化していて、新しい表現力やインタラクションを作り出せる強力なツールです。しかし、多くの有名アプリではまだUIKitが使われており、デザイナーやPdMがそれらを参考にすることも多いです。その結果、SwiftUIだけでは再現が難しいUI表現を求められる場面がよくあります。

開発者は、UIViewRepresentableやUIViewControllerRepresentableを使ってUIKitを取り入れる選択を迫られますが、これによりSwiftUI本来の宣言的なスタイルや一貫した状態管理が崩れ、保守性や可読性に新たな課題が生まれます。

このLTでは、実際に「SwiftUIだけでは実装できなかったUI」や、「UIKitを使わざるを得なかったシーン」を例に挙げつつ、そのときに考えた工夫やトレードオフを共有します。たとえば、カスタムトランジションやインタラクティブなスクロール、特殊なジェスチャー処理など、現場でぶつかったリアルな壁を紹介します。

私たちのチームでは、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を考えるきっかけになれば幸いです。

アプリを多言語対応する際の最も面倒な作業はみなさんご存知ですか？
もちろんそうです。AppStore用のスクショの作成です！！！

アプリの画面を撮影してFigmaなどで上部に文章を加えるのがよくあるパターンですが、言語ごとにiPhone/iPad用のスクショを作成するのは単調な作業で全く面白くないです。
「でも多言語対応って言っても数言語でしょ？」と思うかもしれませんが、私が個人でリリースしているアプリでは16言語対応しています。
16言語分の各画面のスクショと言語ごとの文章を当てはめるのはただの苦行です。

このLTでは、そんな面倒な16言語分のスクショ作成を加速させた方法を紹介します。

• 各言語/地域ごとの撮影の自動化
• Figmaを活用した言語ごとの文章やスタイル設定の簡略化

実際、対応した言語圏のユーザからのinstall数は多いです。このLTを通じて皆さんの多言語対応の1つの壁を打ち砕きましょう！

皆さんは 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作文体験を向上させましょう！

Swift は値型を中心とした言語です。値型を用いてコードを書くと、あるオブジェクトを変更したところ、別のオブジェクトも一緒に変更されてしまった！のような意図しない変更を防ぐことに繋がります。

では、Swiftにおける値型と参照型の違いはなんでしょうか。上記のようなオブジェクトの振る舞いから説明する人もいるでしょう。公式ドキュメントを確認すると、値型は、変数や定数への代入、または関数への引数渡しのときに、値がコピーされる型であると定義があります。一方で参照型は、変数や定数への代入、または関数への引数渡しのときに、コピーされるのではなく、インスタンスへの参照が使用される型であると記載があります。

さて、WWDC24「Consume noncopyable types in Swift」の動画の中で、以下のような言及があります。
「Notice how copying worked the same in both cases. The only difference is whether you're copying a value, or a reference.」
「どちらの場合も（struct も class も）、コピーの動作は同じでした。 唯一違う点は、値をコピーするか、参照をコピーするかという点です。」

あれ？！値型と参照型のコピーの動作って同じなの？！
公式ドキュメントに、参照型はコピーされないって書いてたよ？
一体、どっちが正しいの？！

このLTは、公式ドキュメントとWWDC24のセッション動画との表現上の対立の謎に迫り、そして真理を求める人間が、Swiftの内部実装を紐解きオブジェクトのコピーとは何かを理解することに自らの信念と命を掛けた物語です。「コピーとは何か？」を突き詰めることで、改めて値型と参照型のそれぞれの内部動作の違いに迫ります。

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

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

本セッションでは

• 学びラボの運用方法
• 実際に取り組まれたことや得られた効果
  についてお話しします。

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

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

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

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

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

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

生成 AI の進化により、個人でも驚くほどのスピードでアプリを開発できる時代になりました。
しかし「開発は速いけれど、マーケティングにかけられる予算はごくわずか……」というジレンマに直面する方も多いのではないでしょうか。

本 LT では、“少額”でも効果を出すアプリマーケティング手法を、国内外の成功事例や各種リサーチをもとに整理し、5 分に凝縮してご紹介します。

具体的には
• ASO（App Store Optimization）を最短で回すチェックリスト
• ブログ／LPなどを活用した「検索＆メディア流入」に関して
• 低コストでの広告運用

など、今日から試せる具体的アクションを中心にまとめます。開発フェーズだけでなく、その先のユーザー獲得までを視野に入れ、AI 時代を戦い抜く個人開発者の“少額マーケティング”を一緒に考えましょう。

アプリをインストールして起動すると表示される起動画面。
ロゴが表示されたり、さらにはアニメーションしたりすると、リッチに見えたりもします。
一方、通信環境が悪いところだとロゴの画面から全然動かなかったりすることも。

Human Interface Guidelines(HIG)には、「アプリ起動」の項目もあり、起動画面についてもガイドラインが示されています。
このLTでは、HIGに基づいたアプリ起動体験とベストプラクティスについてお話しします。

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

• HIGの「Launching」と「Onboarding」について

このセッションで話さないこと:

• アプリ起動のパフォーマンス改善手法

WWDC25で待望のChart3Dが登場し、私たちのデータ可視化の可能性は大きく広がりました。しかし、その力を本当に引き出そうとすると、新たな壁にぶつかります。それは、複雑な3D曲面や大量のデータを描画するために必要な、膨大な座標計算という「計算地獄」です。

普通に実装すれば、UIは数秒間フリーズし、ユーザー体験は最悪なものになります。

このLTでは、この「計算地獄」から脱出するための現代的な解決策、すなわちSwift Concurrency、特にTaskGroupに焦点を当てます。

このトークで話すこと

• 新たな力と課題: SwiftChartsが拓く可能性と、複雑な描画における計算コスト問題の提示
• パフォーマンス: Concurrency非対応コードによる、UIフリーズという絶望的な待ち時間の体感
• TaskGroup: 重い計算処理を並列化し、描画を劇的に高速化する手法の解説
• ベンチマーク: Concurrency使用でのパフォーマンス提示

この5分間は、Swift ChartsのTipsに留まりません。あなたのアプリにある、あらゆる「重い計算処理」を高速化し、ユーザー体験を向上させるための普遍的なテクニックです。

近年、行政や金融など高いセキュリティ基準が求められるサービスと連携するモバイルアプリでは、サーバーサイドだけでなくクライアント（iOSアプリ）側でも厳格なセキュリティ対策が求められるようになっています。私たちのプロジェクトでも、外部サービスとの連携に際して、国際的に認知されたモバイルアプリセキュリティ標準であるOWASP MASVS（Mobile Application Security Verification Standard）v2.0.0に準拠する必要がありました。

本トークでは、「なぜ今、iOSアプリにおいてクライアント側のセキュリティ対策が必要なのか？」という背景を出発点に、MASVSの概要やMASプロジェクト全体の構成、そしてMASVS対応において実際に行った対策を具体的に紹介します。また、標準やベストプラクティスに対してどこまで実装で落とし込むべきかという現実的な判断や、運用・開発体制に与えた影響、対応を通じて得られた気づきもあわせて共有します。

クライアント側のセキュリティ対策という難題に挑んだ実例として、これから同様の取り組みを検討する方や、セキュリティ設計に関心のあるiOSエンジニアの皆さんにとって、有益な知見を持ち帰っていただくことができます。

Bluetooth の権限管理、スキャン、接続処理…。
Core Bluetooth を利用した Bluetooth デバイスとの接続フローの実装は、多くの開発者にとって悩みの種です。
ユーザーにとってもペアリングを完了させるまでに手順を踏む必要があり、決して快適な体験とは言えません。

誰もが一度は「AirPodsのように、もっと簡単にデバイスを接続できたら…」と考えたことがあるのではないでしょうか。

その理想を現実にするのが、iOS18 で登場した AccessorySetupKit です。
AccessorySetupKit を活用することで、これまで作り込んできた複雑な接続フローを OS標準のUIを使用してシームレスに提供できるようになります。

本セッションでは AccessorySetupKit で何が実現できるのか活用事例を紹介し、具体的な導入手順と実装にあたってつまづいた点まで実践的な知見を共有します。
本セッションを通じて、皆さんのアプリでペアリング体験を改善するきっかけやヒントを得ていただければ幸いです。

Model Context Protocol（MCP）は、AIと外部サービスやアプリをつなぐためのプロトコルとして注目されています。
実はこのMCP Server、Swiftでも簡単に構築できるのをご存知でしょうか？

本トークでは、MCP公式が提供しているSwift SDKを利用し、IoTデバイスを動かすためのMCP Serverを構築しつつ、CursorやClaude CodeからIoTデバイスを動かす方法をご紹介します。

具体的には以下のような内容を扱います：

1. MCP Serverとは
2. Swift製MCP Serverを構築する
3. 構築したMCP ServerをCursorやClaude Codeに登録する
4. 入力したプロンプトから実際にIoTデバイスを動かしてみる

Swiftで実際にMCP Serverを構築する流れを体験しながら、一緒にMCPの世界に楽しく入門しましょう！