トーク

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との比較

サードパーティアプリ開発者は長年、Appleの純正アラーム機能に制約を感じてきました。
Silent modeやFocus modeに阻まれ、重要な通知が届かないリスクは、開発者とユーザー双方にとって深刻な問題でした。

iOS 26のAlarmKitは、この技術的障壁をついに解放し、開発者にも革命的なアラーム機能の実装を可能にします。
従来のローカル通知の根本的問題は、デバイス設定への依存性でした。
AlarmKitを使用することで、重要な通知がどんな状況でもユーザーに確実に届くようになります。

AlarmKitの主な革新として以下の特徴が挙げられます。

1）あらゆるシステム設定を突破するアラーム実行により、Silent modeやFocus modeの影響を受けない確実な通知を実現
2）Live Activitiesと連携したDynamic Island統合により、ユーザーの目に留まりやすい視覚的なアラーム表示を提供
3）Apple Watchでの自動同期により、デバイスを問わない一貫したアラーム機能
4）App Intentsによるカスタムアクション実行により、アラーム後の独自ワークフローを組み込み可能

実装デモを行い、料理タイマーアプリを題材に段階的な構築過程をお見せします。
AlarmKitの登場により、開発者はユーザーにとってより信頼性の高いアラーム機能を提供できるようになります。

私自身がこの数年主務としてきた領域は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エンジニアとの協業における相互理解を深める視点を提供できるようなセッションを目指します。

visionOS 26 では、iPhone／iPad のホーム画面でおなじみのウィジェットを、壁に貼る置き時計のように、机に置く写真立てのように、現実空間へ自在に配置できます。

本講演では、既存の iOSウィジェットを visionOS 26 へ移植する際の注意点と移行手順を、ソースコードと合わせて詳しく解説します。

まず visionOS におけるウィジェットの基礎を整理し、インタラクション対応の WidgetKit、壁掛け（elevated）／埋め込み（recessed）という二つのマウントスタイルの違いを説明します。
更に、WWDC 25の発表時に気になった「ウィジェットはいくつまで配置できるのか？」「どれほど現実世界に自然に溶け込むのか？」といった疑問についても、調査結果をデモ動画を交えて紹介します。

既存のiOSウィジェットをvisionOSに拡張する際に、利用可能なウィジェット種別の制限や背景色を変更した場合の影響、シミュレーターと実機での挙動の差異など、開発時に押さえておくべきポイントを解説します。
Apple Vision Pro を持っていなくても実践可能な内容となっています。

メルカリでは過去、ネイティブからReact Native、Flutterに至るまで、多岐にわたる方針でモバイルアプリ開発を行ってきました。それらの経験も踏まえ、今回の新規アプリ開発では、既存リポジトリをモノレポとして再定義し、その中で新たなネイティブアプリを開発する戦略を採用しました。

大規模な単一レポジトリ環境で複数のモバイルアプリを開発・運用することは、コードの一元管理、実装の再利用による開発速度の向上、ビルドシステムや周辺ツールの統一といった様々なメリットを享受できます。一方で、複数アプリでの利用を前提としたモジュール再設計の必要性や、各モジュールの影響範囲の拡大、技術的・組織的な依存関係がボトルネック化するといった問題も存在します。

もちろん、こういったメリット・デメリットは、既存のコードベース、目標の時間軸、組織構造、メンバー構成といった様々な変数によって、その性質や度合いは変化します。本トークでは、この点を踏まえつつ、モノレポへの移行からその後のアプリ開発に至るまでの実態を、事例と共に紹介します。主なトピックは以下の通りです。

• 既存のリポジトリ環境から移行するまでの具体的なステップ、Bazelを用いた設計、その過程で直面した課題
• 再利用性と独立性を両立させるモジュール設計の勘所と、実際の再設計事例
• アーキテクチャや個々の実装パターン、技術の選定方針と判断基準（例: swiftui-atom-properties, gRPC, etc.）
• 開発体制および組織面におけるチャレンジ

私たちの戦略と意思決定の過程を一つの実践例として共有します。

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

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

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

近年、汎用的なLLMエージェントは、自然言語による指示からブラウザ操作までを自律的に行えるようになりつつあります。中でもDevinのようなエージェントは、複雑なUIの解釈やフォーム入力、ページ遷移などを含む一連の操作を一貫して実行できるポテンシャルを持っています。また、ブラウザの操作に限らず、Androidアプリを自律的に操作できるエージェントも増えています。

一方、iOSでは、Appleのセキュリティポリシーによる制約により、iPhoneを完全に自動操作するエージェントはApp Storeの審査でリジェクト対象になります。よって、現時点では一般向けには存在しません。しかし、将来的にiOSアプリがエージェントによって操作される日が訪れるかもしれません。そんな日に備え、エージェントによる自律的なUI操作の実態を分析・解剖して未来を見据えることが重要です。

このLTでは、居酒屋でのモバイルオーダーというタスクに注目し、エージェントとしてのDevinの振る舞いをエスノグラフィー調査を通じて分析した結果を報告します。また、お店のQRコードと参加者の食の好みを入力、モバイルオーダーの注文結果を出力として定義し、幹事としてのDevinの挙動を厳正に評価します。エージェントといえど、飲み会の幹事に忖度はありません！実験は、初回実験（参加者8人）と追試実験（参加者16人）の2回にわたり実施しました。
Devinに胃袋を捧げた参加者とともに、厳正に実施した実験の結果に注目です！

ブラウザ操作ができるようになり自由の翼を得たLLMは、さらなる自由を求め、どこまで突き進むのか。
胃袋の限界が来るまで、進み続けるんだ！
唐揚げが来ても、唐揚げが来た後も。
これは、お前が始めた物語だろ！