トーク

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

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

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

このトークで話すこと

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

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

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の世界に楽しく入門しましょう！

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

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

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

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

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

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

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エンジニアが自身の開発を見直すきっかけ」になれば幸いです。

Apple WatchでUIアニメーションと一緒に音や振動を鳴らし続けるにはどうすればいいのか？

watchOSには厳しいリソース制約があり、シミュレーターでは軽快に動いても実機では長時間安定して動作しないことが多々あります。
私がwatchOS向けのメトロノームアプリを開発した時はwatchOSでリアルタイムな処理を安定させるための設計が欠かせませんでした。

本発表では、watchOSで高負荷な動作を安定化させるために実際に効いたパフォーマンスチューニングのエッセンスを共有します。

具体的には

• AVAudioEngineのタイミング管理で触覚フィードバックやSwiftUIアニメーションを同期させる構成
• AVAudioEngineをwatchOS上で効率良く動かすためのパフォーマンス改善施策

について話します。

また、実用に耐えるようにチューニングが成功した証としてメトロノームアプリで練習した作品(ショートver.)をチューバで実演奏します。

watchOSでリアルタイム処理に挑む方の参考になれば幸いです。

「出品って、正直めんどくさい」——そんなユーザーの声から始まった、Yahoo!フリマの生成AI機能「らくらくAI出品」。
本セッションでは、UX視点で“かんたんな出品体験”を実現するために試行錯誤したらくらくAI出品のUI/UX設計の工夫と、実装面で直面した課題とその解決策を紹介します。
生成AIは万能ではありません。だからこそ、ユーザーに過度な期待をさせず、でも手間を減らし、迷いを最小化する。
生成AIとユーザーの自然な関わり方をどう設計し、“使いたくなる体験”を生んだのか。失敗と発見に満ちた機能開発の舞台裏の"リアル"にお届けします。

私は2019年にiOSエンジニアからマネージャーに転向し、それ以来、iOS開発の現場から離れていました。
しかし、現在はエンジニアリングマネージャー（EM）としてマネジメントを主務としながらも、小規模な機能の開発や技術的な判断を行っています。

このトークでは、私がどのようにして5年分の技術ギャップを埋めつつ、業務を遂行しているのかについてお話しします。
具体的な事例として、AIの活用方法や最新技術への適応プロセスを2025年の視点から共有します。
技術的なキャッチアップのヒントや、EMとしての役割を維持しながら開発に関与する方法についても詳しく説明します。

iPhone・iPadアプリにおいて、マルチウィンドウ機能を活用しようとしても、画面サイズの制約によりその利用には限界がありました。
しかしvisionOSでは、周囲の空間全体を表現の領域として活用できるため、複数ウィンドウを互いに干渉せず同時に配置することが容易になり、macOSを超える表現力を実現しています。

これはRealityKitを用いたXR機能に匹敵する、空間コンピューティングの大きな強みだと考えています。

このLTでは、一般的にiOS・iPadOSで提供されるようなアプリをvisionOSで提供する際にvisionOSの性能を引き出す方法を、マルチウィンドウ機能に焦点を当ててご紹介します！

• マルチウィンドウを使った魅力的なアプリ表現の具体例
• visionOSでのマルチウィンドウの実装方法

SwiftとRustは互いに影響を与えながら発展した言語と言われることがあります。実際、他の言語に比べ、多くの類似点見つけられるでしょう。しかし、その類似性にも拘らず、Swiftを書くノリでRustを書くと思わぬ落とし穴にハマってしまいます。

例えば、Swiftのprotocolがオブジェクトの振舞いを保証するインターフェースと考えられるのに対し、Rustのtraitはポリモーフィズムのための制約と考えられます。そのため、Swiftではダウンキャストやprotocolによる型チェックを行えますが、Rustでこれを再現するためにはAny traitを用いた煩雑なプログラムを組まなければなりません。

また、Swift 5.9で導入されたnoncopyableはRustのownershipによく似ています。しかし、noncopyableが適宜使い分けられる仕様であるのに対し、ownershipは常に意識しなければならない言語の中核となる仕様です。そのため、Swiftでは参照型と複合してプログラムを組めますが、Rustでこれを再現するためにはRefCellを用いた冗長なコードを書かなければなりません。

このような言語仕様の違いによる落とし穴は言語の指向性の違いに由来します。本トークでは、その言語の指向性を紐解くことで、なぜ上記のような似て非なる言語仕様になったか考えます。

近年、GitHub CopilotやClaude CodeといったAIツールがコードレビューの分野に進出してきています。
これにより、AIがコードを評価することが一般的になりつつあります。

本LTでは、実際にAIレビューで起きた珍事件・失敗例を5つ紹介します。存在しないAPIを提案する、過剰な最適化を求める、テストコードにマジックナンバー回避を強要する、急に英語に切り替わってまくしたてる、絵文字に気を取られる...など、思わず「それは違うだろ！」とツッコミたくなる事例ばかり。

私：「こういうことってよくあるんですか？」
AI:「はい。よくあります。」

これが現実です。

しかし、AIレビューを否定するのが目的ではありません。これらの失敗から学んだ「AIレビューとの正しい付き合い方」として実際にプロジェクトに導入できる具体的なルール化手法をお見せします。

AIは優秀なアシスタントですが、適切なガードレールがあってこそ真価を発揮します。
AIツールを使い始めた方、導入を検討している方に、共感と今日から使える実践的な知見をお届けする5分間です。

皆さん、KeyPathを使っていますか？
普段の開発では静的なKeyPathを使う場面ばかりなのではないでしょうか。
例えば、SwiftUIのList(_:id:rowContent:)でKeyPathを静的に指定する場面です。

実は、KeyPathを動的に生成することで再帰的な型のプロパティに効率良くアクセスできるようになります。
再帰的な型とは、以下に示すようなものです。

struct Box: Identifiable {
let id: UUID
var children: [Box]
// その他のプロパティ
}

上記のBox型インスタンスでは、アクセスしたい子要素のidがわかっても簡単にはアクセスできません。childrenを先頭から調べて、idが一致するものがなければchildren[0].childrenのように1階層下をさらに先頭から調べて...と探索していては効率が悪いです。

辞書を使って[UUID: Box] のように値を持てば探索は速くなるものの、Valueに入るインスタンスが階層構造を持つため、同じ子要素が複数のValueに存在してSingle Source of Truthに反してしまいます。Boxのプロパティを更新する際に整合性を保つのは難しくなるでしょう。
そこで、階層が最も浅いルートからのKeyPathをValueにすることで、整合性を保ったまま効率良くアクセスできるようになります。

本LTでは以下をお話しします。

• KeyPathを動的に生成する方法
• KeyPathを使って再帰的な型のプロパティに効率よくアクセスする方法
• ルートがオプショナルな場合のKeyPathの書き方
• プロパティがswift-identified-collectionsのIdentifiedArrayな場合のKeyPathの書き方

iOSアプリケーションで時刻を扱う際、Swift標準のDateオブジェクトは便利ですが、端末の時刻設定に依存するという認識されにくい特性があります。
これにより、ユーザーが意図的に、あるいは誤って端末時刻を変更した場合、アプリケーション内で取得される時刻も影響を受けてしまいます。特にサブスクリプション機能や時間制限のあるコンテンツなど、正確な時刻管理が求められる場面では、この挙動が深刻なバグや不正利用を引き起こすリスクがあります。

本セッションでは、このDateオブジェクトが抱える問題点を掘り下げ、影響を受ける具体的なユースケースを解説します。
そして、端末の時刻設定に左右されない正確な時刻を取得するための強力なライブラリ「Kronos」をご紹介します。
Kronosの基本的な使い方から、実際のアプリケーションでの実装サンプルを解説し、
Kronosを活用することで不正な時刻操作に起因するバグからアプリケーションを解き放つことを目指します。

アジェンダ

• Swiftにおける時刻扱いの基本: Dateオブジェクトの基本的な使い方と一般的な実装パターン
• Dateオブジェクトの落とし穴: 端末時刻設定の影響を受けるユースケース
• Kronosの紹介: Kronosが提供する機能、NTPを利用した時刻同期の利点（NTPを利用することで、世界中の標準時間を基にした正確な時刻をアプリケーションにもたらす）
• Kronosによる正確な時刻表示サンプル: Kronosライブラリを組み込んだ具体的なサンプルコードを用いて、正確な時刻取得と表示の実装を解説

私自身がこの数年主務としてきた領域はAndroidアプリ開発です。
「Androidアプリ開発のことなら設計からパフォーマンス改善まで何でもござれ！」と言える自負はある程度あれど、iOS開発の議論となると借りてきた猫のようにしおらしくせざるを得ないという場面も多々あります。
そんな私に、iOSアプリ開発者が多数を占めるチームでモバイルアプリ開発のテックリードを務めることはできるのでしょうか？iOS開発未経験というハンディキャップを背負いながら、いかにしてこの重要な役割を果たしていったのか、そのリアルな奮闘と学びを共有します。

テックリードという立場は、多岐にわたる技術課題に対しメンバーと共に立ち向かう深い知識が求められる職能だと解釈しています。このセッションでは開発環境やビルドシステムの違い、Jetpack Composeとは異なるUIKit/SwiftUIの思想など、Androidエンジニアにとって大きなギャップとなる具体的なポイントに焦点を当てます。 そして、私がどのようにこれらのギャップを効率的にキャッチアップし、チームメンバーと効果的なコミュニケーションを図り、さらには技術的な意思決定を行うための知識を身につけたか、そのリアルな体験談をお伝えします。

iOS開発にこれから入門しようというAndroidエンジニアの皆さんにとってはプラットフォーム間の技術的なギャップをいかに乗り越えるかのヒントを、
そしてiOS開発者の皆さんにはAndroidエンジニアから見た世界を知っていただき、ご自身の開発スタイルを客観的に見つめ直すきっかけや、Androidエンジニアとの協業における相互理解を深める視点を提供できるようなセッションを目指します。

SwiftUIといえばViewにModifierをたくさんつけるかと思います。
簡単なViewであれば標準のModifierでもいいのですが、UIにこだわればこだわるほどModifierを付けすぎてごちゃごちゃになります。
標準のModifierの付け方は人それぞれですが、そんなことで議論していては日も暮れてしまいます。
日が暮れる前にシンプルでわかりやすいカスタムModifierを作ってしまい、余計なストレスから解放されましょう。
生成AIに厳密で複雑な標準のModifierのルールを守らせるのではなく、カスタムModifierを使うように指示すれば結構楽に思い通りの実装ができると思います。

このトークでは、単にカスタムしたViewModifierを紹介するのではなく、とても複雑なUIを組んだ時のストレスからの解放についてご紹介させていただく予定です。
また、どの程度の単位でカスタマイズしたModifierを使用すると最適かについてもお話しします。

レイアウト系でカスタマイズすると結構嬉しいことが多いので、複雑なUIを組んでいて、可読性に苦しんでいる方に参考にしていただけると幸いです。

Git で xcodeprojが衝突して深夜に泣いたこと、ありませんか？
私は、大学サークルで2週間〜2か月スプリントのvisionOS / iOSアプリ開発を続ける中、毎回「xcodeproj のコンフリクト → 作業停止」に悩まされてきました。

そんな状況を打破するべく、0→1のチーム開発でコンフリクトを最小限に抑えるプロジェクト構成を模索しました。その結果、SPMローカルパッケージ＋xcconfigでxcodeprojの衝突を0件にできた構成にたどり着きました。

本LTでは、具体例を交えながらこの構成とノウハウを紹介します。

LTで話すこと：

・なぜxcodeprojは衝突するのか？
・衝突が起きない SwiftPM 分割パターン:
1Package ＋ multi-target戦略 と 1 Workspace ＋ 複数Package戦略
・xcconfig で実機ビルドOK＆差分を撲滅！

JetbrainsのAppCodeが販売終了した年の2022年4月に私はAndroidエンジニアからiOSエンジニアになりました。
使い慣れたJetbrains製のIDEへ恋い焦がれつつも、わたしは、かの有名な IDE に慣れ親しんでいきました...。

それから3年の時が経った。
ときは2025年某日、Android StudioのKotlin Multiplatform向けプラグイン “Kotlin Multiplatform IDE plugin” がiOS開発を強力にサポート！遂にわたしが恋い焦がれた状況が結実。

待ち望んだ状況を迎え、Kotlinの存在しない、Pure SwiftのiOSアプリ開発環境をAndroid Studioで構築し、快適に開発することができるのか！？あの有名なIDEとの関係性はどうなってしまうのか。

いまAndroid StudioでiOS開発するための最短ステップを5分でお届けします。

ウワサの次期OS「iOS26」が話題の今、未来のデザインに胸を躍らせる今だからこそ、僕たちが毎日触れてきたiOSのUIデザインの歴史をタイムスリップしてみませんか？最新のデザインを深く理解するためのヒントは、そのルーツにこそ隠されているはずです！

このトークではまず、多くの開発者の記憶に刻まれているであろうiOS 6までの「スキューモーフィズム」の世界へご案内します。緑のフェルトが敷かれたGame Center、革の表紙がめくれるiBooks。なぜあの頃のUIは、現実世界の質感を忠実に再現しようとしていたのでしょうか？？

次に、世界に衝撃を与えたiOS 7の「フラットデザイン」への大転換を振り返っていきます！
アイコンから光沢が消え、UI全体がミニマルになったあの瞬間。
開発者たちが熱狂し、あるいは困惑したデザイン思想の変化を探っていきます！

そして、単なるフラットデザインに留まらず、すりガラスのような半透明のブラー表現、ウィジェットやLive Activitiesによる新たな情報提示、物理法則を感じさせるアニメーションなど、リッチでインタラクティブに進化した現在のデザインへと旅を続けます。

ベテランの方には懐かしさを、若手の方には新鮮な発見を。
スクリーンショット満載でUIの"エモさ"の変遷を辿り、未来のデザインを考えるきっかけを持ち帰っていただける、そんなLTです！

昨年、私が寄稿したiOSDC Japan 2024のパンフレット記事においてSwift Playgroundsを紹介した際、教育分野での活用の可能性に触れました。 今回のLTでは、その着想を実際に形にした、ZOZOでの「Girls Meet STEM」プログラミング体験イベントの学びを共有します。

イベントでは、AppleのSwift Playgroundsに標準搭載されているレッスンを活用し、中高生がプログラミングの基礎（条件分岐やループなど）を楽しく学べるよう取り組みました。実際に開催してみて、Swift Playgroundsはビジュアルプログラミングからのステップアップに適しており、教える側にとっても扱いやすいツールだと分かりました。LTでは、具体的な事例から見えてきた活用メリットとデメリットについてお話しします。

本イベントで得られた知見が未来のiOSエンジニアを育むきっかけとなり、iOSコミュニティのさらなる発展に繋がればと思います。

エッジAIとは、iPhoneなどの端末上で直接動作するAI技術のことで、プライバシー保護やネットワーク帯域の節約など、さまざまな観点から注目を集めています。近年ではエッジデバイスの高性能化により、その存在感がますます高まっています。

しかし、実際にアプリにAIを組み込もうと思うと、さまざまな「迷いポイント」に直面します。
私自身、個人開発アプリにAIを導入する際に、

• 本当にエッジAIを使うべき？
• Apple純正からサードパーティ製まで多くのAPI・ツールの中で、どれを選べばいい？
• モデルやデータセットのライセンスは大丈夫？

といった疑問に悩み、何度も手が止まりました。

このLTでは、そんな試行錯誤の中で得た「迷いポイントの全体像」をベースに、iOSエッジAI導入の判断プロセスをフローチャート形式でサクサク整理していきます。
iOSアプリにAIを組み込みたいが、何から始めればいいか分からない──そんな開発者に向け、Apple公式資料だけではカバーされない導入判断フェーズの実践知を凝縮し、5分間でスッキリ理解できる判断軸をお届けします。