トーク

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

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

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分にしたいと思います。

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

デジタルプロダクトの成功には、ユーザー体験の最適化が欠かせません。そこでよく用いられる手法の一つに 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やシングルトンへの直接参照をどのように剥がしていくか、その段階的なプロセスを共有します。
テスト可能なコードへの改善: 既存のコードにユニットテストを追加するための、インターフェース導入や副作用の分離といった具体的な手法を紹介します。

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

2ヶ月ほど前Swift Forumsに投稿された Xtool: cross-platform Xcode replacement. Build iOS apps on Linux and more! という投稿をご存知でしょうか。

Linux上でネイティブのiOSアプリ開発をビルドするためのXcodeに成り変わるツールを開発したという内容で、これは私にとってとても衝撃的でした。

iOSアプリ開発といえばmacOSが必要というのは多くの人に知られていると思います。IDEであるXcodeを始め、プロジェクトをビルドするための xcodebuild や署名用の codesign など、多くのツールがmacOS上でしか提供されていないためです。

それではこのXToolというツールはどのようにmacOS外でのiOSアプリビルドを可能にしたのでしょうか。それにはSwiftのビルド技術の進化が大きく関わっています。

このトークで話さないこと

• XToolの使い方

このトークで話すこと

• SE-0387によって仕様策定されたクロスコンパイルのための仕組みについて
• XTool作者によって実証用に用意されたswift-sdk-darwinについて

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

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

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

具体的には

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

について話します。

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

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

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

Apple Vision Proを活用し、自分の発した声や楽器の音程を空間上に可視化する機能を実装しました。

単に周波数を表示するのではなく、「今の音が目的の音程に対して高いか・低いか」を3D空間に直感的に表示し、自分の音感をリアルタイムで補正できる仕組みを構築。
実際にこのアプリを使って練習を継続した結果、ピッチのズレ補正が体感でき、音感トレーニングとしての実用性が期待できそうです。

本セッションでは、空間UIによる音程フィードバック設計、Vision Pro上での周波数検出と3Dビジュアライズ手法、日々の改善プロセスまで、実装から習熟までの過程を具体的に解説します。

空間コンピューティングの新しい応用例や、感覚の可視化×習得支援に興味のある方にとって、技術面・UX面の学びを持ち帰っていただける内容です。

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

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

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

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

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

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

iPadは、iOS 9でマルチウィンドウ機能が導入されて以来、複数のアプリを同時に利用できるよう段階的に進化してきました。そして、今年登場予定のiPadOS 26ではその機能がさらに進化し、各ウィンドウのサイズを自由に変更したり、複数のアプリを重ねて表示したりと、macOSのような、より自由度の高いマルチタスク環境が実現します。

この変化は、私たちiOSエンジニアにとって、単なるUI表現のバリエーションの追加にとどまらず、アプリの設計思想そのものに影響を与える可能性があります。

もちろん、macOSでさえマルチウィンドウの活用が自然に馴染むのは一部のアプリに限られており、すべてのアプリで多ウィンドウ対応が最適解になるわけではありません。しかし、特定の用途、例えばドキュメント編集やクリエイティブツール、情報集約型のアプリにおいては、ユーザー体験を大きく向上させる可能性を秘めています。

本トークでは、iPadOS 26における新しいマルチウィンドウ環境を最大限に活かすために、どのようなアプリ表現が可能になるのかを具体例とともに紹介しつつ、その実装方法を解説します。

想定視聴者:
マルチウィンドウ対応に関心があるiPadOSやvisionOSのアプリエンジニア

話す内容:
・ マルチウィンドウだからこそ実現できるアプリの表現例
・ マルチウィンドウ環境におけるUISceneのライフサイクルの要点
・ 具体的なマルチウィンドウの実装方法
・ マルチウィンドウでできること・できないこと
・ 既存アプリのiPadOS 26への移行で押さえるべき注意点

Swiftでバックエンドも開発できたら、便利だと感じたことがある方は多いのではないでしょうか？
フロントエンドとバックエンドで異なる言語を使い分ける必要がなく、一つの言語でアプリケーション開発を完結できれば、開発効率は格段に向上します。
Server-Side Swiftは、開発者がフロントエンドとバックエンドをSwiftで統一できる選択肢を提供します。
本LTではSwiftをサーバーサイドでも活用する利点と、複数あるServer-Side Swiftのフレームワークの中でも、特にVaporに焦点を当てます。

【本LTで得られること】

• iOSアプリ開発者がすでに持つSwiftの知識をサーバー開発にも活かせる具体的なメリット
• PerfectやKituraなどのフレームワークと比較した時のVaporの特徴や優位性
• 短時間で始められるVaporの環境構築手順
• クライアントに返すJSONレスポンスの実装と、Codableを活用したデータ連携方法

Vaporは型安全性、Swift Concurrencyのサポートなど、Swiftの強みを最大限に活かしたフレームワークです。
本LTでは、まずSwift Package Managerを使用した環境構築手順を説明し、その後、基本的なルーティング設定とミドルウェア構築について解説します。続いて、async/awaitを活用した非同期処理を実際のコードで示します。さらに、Codableプロトコルを活用したモデル定義とJSONレスポンスの実装を通して、iOSアプリとサーバー間でのスムーズなデータ連携方法を示します。

今日からすぐに試せる具体的な知識と実装テクニックを5分間でお届けします。

Embedded Swiftの登場により、Swiftで組み込み機器向けのプログラミングが可能になりました。

AppleがSecure Enclaveの開発でEmbedded Swiftを使っていたり、去年のiOSDC JapanでもRaspberry Pi PicoやPlaydate、ゲームボーイアドバンスをEmbedded Swiftでプログラミングをするトークがあったりと、とても注目の領域です。

私もそれに触発されてゲームボーイアドバンスのプログラミングをはじめました。しかし、"Safe"が売りのSwiftで、組み込みプログラミングに特有の"Unsafe"な手続きをどう実装したらいいか、かなり試行錯誤しました。

C言語やObjective-Cを使えば簡単なのはわかっています。でも、私はなるべくSwiftだけでプログラミングしたい！ なぜならSwiftが好きだから！

このトークでは、ゲームボーイアドバンスでのプログラミング例と共に、「アドレス指定のメモリアクセス」「レジスタ操作」「関数ポインタによる割り込み処理」「＿attribute＿の利用」「インラインアセンブラ」に挑戦した結果を紹介します。

Embedded Swiftの可能性と「危なさ」を体感してください！