トーク

Apple Vision Proの登場で注目される空間写真や空間ビデオなどの3Dコンテンツ。しかし、Appleやサードパーティのアプリで提供されるコンテンツはクオリティが高いものの、それだけでは物足りなさを感じている方も多いのではないでしょうか。

そんな方におすすめしたいのが、自分で撮影したオリジナルコンテンツです。思い出や特別な瞬間を切り取った自作のコンテンツは、プロが作った作品とは一味違う、特別な価値をもたらしてくれます。

先日のWWDC25では、時期OSに向けてVR撮影機器との連携を強化する発表もされました。iPhoneで撮影しても手軽に楽しめますが、様々な専用の機材で撮影して活用する土壌も整えられつつあります。

本発表では、比較的安価で手を出しやすいミラーレスカメラを使い空間写真や空間ビデオを撮影する方法と、その魅力についてご紹介します。Apple Vision Proの新たな可能性を、自らの手で引き出してみませんか？

iOS 26の登場により、App Intentの重要性が劇的に高まりました！
もはや「あったら便利」な機能ではなく、Appleエコシステムでユーザーの期待に応え、競合と差別化するための必修技術です。
あなたのアプリはこんな状況ではありませんか？「Siriに話しかけても反応してくれない」「Spotlightに表示されるのは競合アプリばかり」「OSの最新機能の恩恵を受けられず、ユーザーエンゲージメントが低下している」。本セッションでは、これらの課題をApp Intentで解決し、プロダクションレベルで活用するための全知識を提供します。

App Intentは、アプリの機能をシステムに公開する役割を持ちます。
SiriやSpotlight連携の基本に加え、iOS 26で加わった新機能「Interactive Snippets」や「画面上のエンティティ連携」により高度なユーザー体験を実現するテクニックをお伝えします。

単なる機能紹介に留まらず、実装時の「ハマりポイント」やトラブルシューティング、App Intentがもたらす「アプリを開かないUX」による利便性の向上とそのビジネス的価値を力説し、最新のiOS開発を勝ち抜くための即戦力スキルを提供します。

明日からあなたのアプリをAppleエコシステムの中核に据え、競合に差をつけ、より多くのユーザーに愛されるアプリへと進化させましょう！

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分間です。

自転車のタイヤがパンクしたら、あなたはどうしますか？自転車屋に持っていって修理してもらうか、あるいは自分で直してしまうかもしれません。まさか自転車ごと買い替えるなんてことはしないですよね。では、iPhoneの画面が割れたら？あれ、買い替えるかも…？

こう考えてしまうのには訳があります。私たち消費者を修理から遠ざける要因が、ハードウェアの設計やソフトウェアの制限、知的財産権、さらにはマーケティングメッセージにまで、至るところに潜んでいるのです。例えば、AirPodsのネジがない設計は、修理の第一ステップである「デバイスを開ける」ことをほぼ不可能にしています。

修理の疎遠化は企業に大きな利益をもたらす一方で、消費者には経済的負担を、地球には環境負荷を与えています。こうした状況を打破するために、「修理する権利」を求める運動が、欧米やヨーロッパを中心に世界中で広がっています。もちろんAppleも例外ではありません。

本セッションでは、次のような内容をお話しします。

• なぜ修理が重要なのか？
• Apple製品から修理を遠ざけている要因たち
• 「修理する権利」を求める運動と、それを受けてAppleが変えたこと
• 日本で「修理する権利」を阻む壁: 技適
• 私たちiOSエンジニアにできること: Minimum deployment targetを再考する

修理がもたらすのは、金銭的・環境的価値だけではありません。修理は、デバイスの仕組みをより深く理解することに役立ち、自分が所有するモノを最大限に使いこなすことを可能にします。Appleプラットフォームでサービスを提供する者として、「修理する権利」について一緒に考えましょう。

WWDC25で発表されたAIツールの進化は凄まじく、Foundation Modelは実際に触った人も多いのではないでしょうか。
そして今、多くの開発者がAI機能の導入を検討している時期かと思います。そこで、導入に際して何が課題点なのか、精度はどのくらいなのかについて私が皆さんの代わりに検証を行います。
ただ、昨今は自然言語の話題が多いので、今回は敢えて視点を変え画像認識に焦点を当てます。そして、その中でも特にオンデバイスの良さが活かせる「顔認証」を調査します。

「VisionフレームワークやCreateMLを使ったお手軽実装」から、「PyTorchやMLXで独自モデルを構築する本格実装」まで、具体的な実装方法をコードと共に紹介します。
それぞれのメリット・デメリット、そして「実装難易度」と「認証精度」を徹底的に比較・解説します。

今回は顔認証を題材にしますが、ここで得られる知見は、画像分類や認識などの他のモデルを扱う上でも必ず役立つはずです。
あなたのアプリに最適なAI技術を見つけるための、実践的なヒントをぜひ持ち帰ってください！

【構成】
・難易度別の実装方法とその詳細
・実機で動かした場合の精度や負荷
・実装途中の失敗談やTips

「エンジニアの価値は技術力だ。それが正義で、格好いい」
そう信じたい一方で、世の中技術力に長けている人ばかりではありません。そして自分より遥かに優れた同期と比べて無力感を覚えてしまうものです。
もしあなたが今、技術力に絶対の自信が持てなくても大丈夫です。 入社時はoptionalの存在すら忘れていた私が、社内で新人賞を受賞できたのです。

このLTでは、技術で突き抜けられない自分が社内で少しでも認めてもらうためにどう戦ってきたのか、そのリアルな姿をお見せします。
社内でiOSエンジニアとして働く上で本当に必要だったスキルやスタンスを全て詰め込みました。

あなたの明日からの働き方に、何か一つでもヒントを持ち帰っていただけたらそれ以上に嬉しいことはありません。
覗きにくるだけでも結構ですので、お気軽に足をお運びください。

【構成】
・iOSエンジニアの評価と会社のカルチャー理解
・外部登壇が引き起こすキャリアへの影響
・エンジニアの特性と差別化
・キャリアを豊かにする「複利効果」

あるとき、開発しているサービスのユーザから「この挙動不便なんだよね」と打ち明けられ、「なにその話、それ仕様じゃなくて意図せぬ挙動です」と不具合に気付いたことはありませんか。同じことが我々開発者とプラットフォーム提供者（Apple）の間でも起こっています。伝えることで解決する不具合や訊くことで判明する方略があります。
APIもフレームワークもガイドラインも天から降ってきて受け取るだけのものではありません。疑問があったら質問をしましょう。要望があったら介入しましょう。大切なのはコミニュケーションです。
フィードバックフォームやオンラインでのエンジニアとのone-on-oneなど、Appleは我々サードパーティの開発者とコミニュケーションを取る複数の方法を提供しています。それらを活用することで、あなたの開発はもっと充実したものになるでしょう。このトークではその使い方と効能を登壇者の実感とともに紹介します。

以下の話をします:
・Appleとコミュニケーションを取る方法の紹介
・それぞれの手段のProとCon
・上記に関する登壇者の体験事例
・フィードバックを出すことに関する啓蒙

以下の話はしません:
・企業としての特別ルートの会話

対象とする聴講者:
・Appleの提供する技術を使っているすべての開発者
・ルーキー

皆さん、普段コードレビューを行なっていますでしょうか？

もし、そうならこんな悩みや不安を抱えたことはありませんか？

• コメントはいつも「LGTM👍🏻」だけ。本当にコードは読まれているのだろうか？
• レビュー依頼を出しても一向に反応がなく、開発が進まずに焦りを感じる。
• 人間関係を気にするあまり、本当に伝えるべき指摘を躊躇してしまう。

これらの課題は、コードレビューの目的や手法をチームで共有できていない「雰囲気レビュー」が原因かもしれません。

「雰囲気レビュー」を放置すると、

• コードレビューがただの承認作業と化し、品質向上の機会を失う。
• レビュアーの経験や気分によって指摘の質が大きく変わってしまう。
• 終わらないコメントの応酬で開発が遅延する。（あるいは、諦めてマージしてしまう）

といった事態を招き、チーム全体の生産性を下げかねません。

本トークでは、これらの課題を解決するため、明日からすぐに実践できる具体的なノウハウを解説します。

• コードレビューの本質とは何か？
• コードレビューの登場人物とそれぞれの責務
• 関係を悪化させる不安をなくしつつ、的確に意図を伝えるコメント術

などについて、私自身のこれまでの経験と『Looks good to me』という書籍の翻訳を通じて得られた知見を基に、皆さんと一緒に考えていきます。

さらに、避けては通れない未来として、AIを活用したコードレビューについても深掘りします。AIツールがどのようにコードレビューを効率化し、どのような新たな課題が生じる可能性があるのか、皆さんと共に考えます。

本トークが、皆さんのコードレビューに対するモヤモヤを少しでも解消し、自信を持ってレビューができる一助となりましたら幸いです。

「Siriで自分のアプリを操作したい」「Spotlightから直接アプリの機能を使いたい」「Apple Intelligenceと連携させたい」—そんな願いを叶えるのがApp Intentです！
iOS 26では、Apple Intelligenceが本格始動し、App Intentがそのゲートウェイとしてますます重要になりました。

従来、アプリの機能はアプリ内でしか使えませんでした。
ユーザーがメモアプリでメモを作りたいとき、アプリを開いて、画面をタップして、やっと作成できる。
この「アプリを開く」という壁が、ユーザー体験の大きな障害でした。

App Intentは、この壁を取り払います！
Siriに話しかけるだけでメモを作成、Spotlightから検索して直接アプリの機能を実行、ウィジェットやコントロールセンターからワンタップでアクション実行。
さらにiOS 26では、Visual Intelligence（カメラでの画像検索）、Spotlight上でのアクション実行、Apple Intelligenceとの深い連携が可能になりました。

基本的なIntent作成から始まり、App Shortcutの設定、Entity（動的データ）の扱い方、Query（検索機能）の実装、そして最新のVisual Intelligence連携まで。
Apple Intelligence時代に必要な実装パターンを、実際のコードと共にお見せします。
App Intentで、あなたのアプリをApple エコシステムの一等市民にしましょう！

SwiftではSwift RegexとNSRegularExpressionという二つの正規表現エンジンが利用できます。しかし、SwiftUIとUIKitの関係と同じく、新しい方が常に正解ではありません。サポートする機能が異なるので、単純な置き換えはできません。パフォーマンスの観点からはSwift Regexの方が多くのケースで遅いことも分かっています。

しかし、この２つの正規表現エンジンはどちらもバックトラック型の実行方式のため、仕組み上、正規表現の書き方がパフォーマンスに大きく影響します。どちらを利用するかを適切に選択するには、単純なベンチマークで決まるものではなく、正規表現エンジンが文字列をマッチする原理と仕組みの理解が重要です。

Swift Regexはオープンソースなので、ソースコードを読むことも可能ですが、一般的なアプリケーションコードとは大きく異なるため読み解くことは容易ではありません。（NSRegularExpressionも実装はICUなのでソースコードは読めます。）

また、Swift Regexは更新頻度が落ちており、SE-0448など承認済みの改善であってもいまだ未実装の機能が存在するため、自ら改善に貢献したいという人も多いでしょう。

そこで本講演ではSwift Regexとまったく同じ構成で、機能だけを「連接・選択・繰り返し」の基本三演算に限定した最小の正規表現エンジンをゼロから実装します。限定版といっても、正規表現は基本三演算さえ実装すれば理論上はフル機能の正規表現と同じ表現力を持つので、実用性は変わりません。

自分で実装することは動作の原理や仕組みを学ぶための最適な手法です。正規表現が動作する仕組みを理解することで、技術選択に確信が持てます。また、公式の実装を読み解き、機能の拡張へ貢献するための第一歩となります。

iOSDC2023で紹介されたScipioは2年間の時を経て、さまざまな進化を遂げました。
私はそのScipioの開発に現在携わっています。
Scipioとは、XCFrameworkの生成・キャッシュを行うツールです。生成したいXCFrameworkをPackage.swiftに依存として追加し, それを元に依存解決をSwift Package Managerで行い、その依存関係からXCFrameworkを生成しています。

Scipioでは、内部的にSwift Buildを使用してXCFrameworkの生成を行っています。しかし調査の結果、マクロターゲットを含むパッケージは Swift Build ではビルドできないという問題に突き当たりました。本トークでは、その問題に対してどのような方法でマクロターゲットをビルドすることにしたのか、解説します。

具体的には、以下の点についてお話しします：

• Scipioのビルドフローの全体像
• SwiftPMやSwift Build、それを仲介するPIF (The Project Interchange Format)の関係や制約
• マクロの詳しい動作原理
• Scipioでマクロターゲットをビルドする場合にどのような手法を取ったのか

本トークは、マクロを含むライブラリをXCFrameworkとして利用したい方や、Scipioのビルドフローの全体像、マクロの動作原理を理解したい方にとって、有益なトークです。

「来年度からチームにジョインする新卒のメンターよろしくね」 そう言われたとき、少しでも不安を感じる方は多いのではないでしょうか。
ZOZOTOWN iOSチームでは、これまで新卒メンバーのメンタリングはメンターの経験と裁量に委ねられていたため、メンターの得意不得意によって新卒メンバーが活躍するまでの期間が左右されてしまう、属人性の高さが課題でした。

そこでZOZOTOWN iOSチームでは、2024年新卒のメンバー受け入れにあたり 「初めてのメンターでも、iOS未経験の新メンバーでも最高のスタートダッシュを切れる」 ことを目指した教育プランを作成しました。
このプランでは、iOS開発やチーム開発の基礎知識の習得だけでなく、ZOZOTOWNという巨大で歴史のあるプロジェクトならではのリファクタやリアーキを前提にした開発ステップなど、実務に向けたエッセンスを凝縮した実践課題を通して新卒メンバーがスムーズにステップアップできるようになっています。

本トークでは、教育プランの具体的な内容と、実際に1年間メンターとして伴走した結果、新卒メンバーがどのような成長を遂げたのかをご紹介します。
iOSエンジニアを目指す学生の方々には効果的な学習ステップのヒントとして、企業のメンターやリーダーの方々には再現性の高い育成の仕組み作りの具体例として、役立つ知見をお届けします。

クラウドAIエージェント「Devin」などの活用が進む中で、iOSアプリの開発も“人がビルドしてエラーを確認する”時代から“AIが自律的にビルド＆デバッグする”時代へ向かっています。
しかし、私たちが取り組んだTCA採用プロジェクト「LogoREGI」では、xcodebuildによるCLIビルドそのものが大きな壁として立ちはだかりました。

例えば、 SKIP_MACRO_VALIDATION=YES ではMacroが展開できず、 defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES を設定しなければビルドできない、というCLI環境特有の落とし穴にハマりました。

さらに、 destination と sdk オプションの相互作用によるビルド失敗、煩雑で読みにくいログ出力など、「まずビルドを通すこと」自体が大きな課題となりました。

このLTでは、try! Swift TokyoのiOSもくもくハッカソン参加時に試行錯誤しながら見出した、「まずビルドを通す」→「安定してAIと連携できる構成へ」進めるまでの実践知を共有します。

LTで話すこと: 

• xcodebuild でハマった具体的なエラーとその原因
• defaults による設定の回避策と効果
• xcbeautify でログを読み解く小技

このLTが、CLIビルドの壁にぶつかるiOS開発者にとって、自動化に踏み出すきっかけとなれば嬉しいです。

皆さん、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ライブラリを組み込んだ具体的なサンプルコードを用いて、正確な時刻取得と表示の実装を解説

SwiftUI における Container views （以下「コンテナビュー」という）とは、複数の子ビューを内部に持ち、それらを管理・配置する役割を持つビューのことです。代表的なものとして、子ビューを縦方向に整列する VStack、横方向に整列する HStack、スクロール可能なリストを構成する List などが挙げられます。

WWDC24では、こうしたコンテナビューをより柔軟にカスタマイズできる新しいAPIが発表されました。これにより、たとえば「子ビューを横方向に整列しつつ、横幅の上限に達した場合に自動で折り返す HStack」のような独自のレイアウトコンテナを、SwiftUIの構文のまま実装できるようになります。

ただし、この新APIはiOS18以降でのみ利用可能です。iOS17以前をサポートするアプリは依然として多く、なかにはiOS16を対象とするアプリも少なくありません。

そこで、iOS17以前の環境でもSwiftUIらしい記述でカスタムコンテナビューを構築可能な、非公開APIである Variadic View に注目します。これを活用すれば、iOS16やiOS17をサポートする環境でも柔軟なレイアウトを実現できます。

本セッションでは、まずSwiftUIにおけるコンテナビューとは何かを説明し、その中で、コンテナビューを定義する際に重要な概念となる2種類のsubviews（Declared subviewsとResolved subviews）に触れます。その上で、iOS18以降で使える新しいAPIによってカスタマイズしたコンテナビューを定義する方法を実例を用いて紹介します。次に、Variadic Viewの仕組みを解説します。最後に、新APIにより実装したコンテナビューと同様のものをVariadic Viewを用いて定義する方法を詳しく解説します。

Xcodeでコードを読む際、依存関係を理解するために定義ジャンプやシンボル検索を利用した経験はありませんか？
それらの機能はコードジャンプであり、依存関係を1階層しか調べられません。例えば型やメンバの構造を上下に、そこから選択した要素の依存関係を左右にそれぞれ階層構造で可視化するツールを自作できると、より調べやすくなります。
そのようなツールを開発する際にまず思いつくのが、SwiftSyntaxです。

SwiftSyntaxでは、抽象構文木を走査することでSwiftソースコードの構造を抽出できます。
しかし、SwiftSyntaxを使って依存関係を自力で抽出することは困難です。あるプロパティについて依存関係を抽出したい場合、抽象構文木の各ノードの名前に注目したらいいでしょうか。この時、複数の名前空間があると対応が困難です。

そのような場合に、IndexStoreという強力な仕組みを使うことができます。IndexStoreから各シンボルの位置や一意な識別子、その役割を抽出できます。さらに、シンボルが他のどのシンボルを参照しているかを抽出できます。
一方で、IndexStoreから得られるシンボルの情報だけでは、その型やメンバの構造は分かりません。

そこで、SwiftSyntaxとIndexStoreを組み合わせることで、「この型はこんなメンバを持っていて、それは何に影響を与えていて、何に依存しているのか」という情報を抽出することができます。

本トークでは、以下をお話しします。

• SwiftSyntaxを使ってソースコードの構造を維持しながら宣言を抽出する方法
• IndexStoreの概要
• シンボルの一意な識別子を使って、ネストした宣言に効率良くアクセスする方法
• SwiftSyntaxとIndexStoreを組み合わせたツールの実装例
• Xcodeとの比較

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

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

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

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

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

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