iOSアプリ開発の論点は、画面を作る技術だけではなく、実装をどこで進め、誰がレビューし、どの端末で判断するかに広がっている。
CursorはiOS向けネイティブアプリを公開ベータとして案内し、クラウド上のエージェントを起動することや、手元のコンピューターで動くエージェントをスマートフォンから操作することを説明している。KiroもiOS向けのモバイル画面で、クラウドセッションの開始、差分レビュー、変更承認を扱う体験を紹介している。
この変化は、iOSアプリそのものをスマートフォンだけで作るという話ではない。実務上の変化は、開発環境、クラウド実行、仕様管理、レビュー判断が分かれ、スマートフォンがその間をつなぐ判断端末になる点にある。
スマートフォンは開発端末ではなく判断端末になる
モバイルから開発エージェントを扱えるようになると、移動中や外出先でも作業を進められる。しかし、そこで起きるのは「スマートフォンで全部のコードを書く」ことではない。
スマートフォンに向いているのは、作業の開始、状況確認、軽い追加指示、差分の一次確認である。複雑な設計判断、セキュリティレビュー、リリース前の最終確認は、画面の広い環境とチームのレビュー手順に戻す必要がある。
Cursorの説明では、iOSアプリからリポジトリを選び、モデルを選択し、音声入力やスラッシュコマンドでエージェントに方向づけできる。さらに、Live Activitiesやプッシュ通知で完了、入力待ち、レビュー可能な状態を知らせるとしている。
この機能を有効に使うには、開発チーム側で「どこまでをモバイル判断に任せるか」を先に決めておく必要がある。通知が届いたからすぐにマージするのではなく、変更の種類ごとに承認者、確認項目、差し戻し条件を分ける。
iOS開発で先に決めるべき境界
エージェントが関わるiOS開発では、実装速度よりも境界設計が先に来る。境界が曖昧なまま作業を渡すと、コードは進んでも、審査、プライバシー、保守で手戻りが増える。
| 決めること | 理由 | 実務での確認 |
|---|---|---|
| エージェントに渡す作業範囲 | UI修正、テスト追加、文言調整、調査などで必要な監督が違う | タスクを小さく分け、マージ権限を人間のレビューに残す |
| 扱ってよいデータ | 端末ログ、顧客情報、解析データにはプライバシー上の制約がある | サンプルデータ、匿名化ログ、再現手順を使う |
| レビューの証跡 | 後から判断理由を追えない変更は保守で弱い | 仕様、差分、テスト結果、レビューコメントを残す |
| App Store向け説明 | 非自明な機能や購入導線は審査メモで説明が必要になる | 機能説明、デモアカウント、バックエンド稼働状態を提出前に確認する |
実装エージェントに渡す前の仕様
Kiroは、プロンプトを要件、設計、タスクに分けるspec-driven developmentを前面に出している。Kiroの仕様ドキュメントでは、requirements.md、design.md、tasks.mdの三つを中心に、ユーザーストーリー、受け入れ条件、設計、実装タスクを整理すると説明している。
iOSアプリ開発でも、この考え方はそのまま使える。たとえば通知機能を追加するなら、「通知を送る」だけでは足りない。ユーザーがどのタイミングで通知を受け取り、どの設定で止められ、通知からどの画面に戻るのかまで書く。
仕様は長い文章である必要はない。画面、状態、入力、エラー、権限、計測、テストの観点を一枚に並べるだけでも、エージェントが誤った前提で実装を進めるリスクは下がる。
レビューとApp Store対応を後回しにしない
AppleのApp Review Guidelinesは、提出前にクラッシュやバグをテストし、メタデータを正確にし、ログインが必要なアプリにはデモアカウントやデモモードを用意するよう求めている。バックエンドサービスがレビュー時に使える状態であることも確認項目に含まれる。
プライバシー面では、AppleはApp Store Connectでデータ収集の扱いを説明する必要があると案内している。広告や解析SDKなど第三者コードを使う場合、そのコードが何のデータを集め、どう使われ、トラッキングに使われるかも説明対象になる。
したがって、iOSアプリ開発でエージェントを使う場合も、提出直前に「プライバシー表示だけ整える」進め方は危うい。ログ、SDK、通知、アカウント連携、決済、外部サービス連携は、実装タスクと同じ段階でレビュー対象に入れる。
小さく導入する手順
導入は、失敗しても戻せる作業から始めるのが現実的である。最初から主要機能の全面改修を渡すより、テスト追加、画面文言の整理、軽微なUI崩れの修正、ドキュメント更新から始める。
- リポジトリ内に、エージェントが読んでよい仕様と読ませない情報を分ける。
- 変更対象を一つの画面または一つの機能に絞る。
- 受け入れ条件を、表示、入力、エラー、アクセシビリティ、テストで書く。
- エージェントの出力は、モバイルで一次確認しても、最終マージは通常のレビュー手順に戻す。
- 提出前に、Appleの審査メモ、プライバシー表示、デモアカウント、バックエンド稼働状態を確認する。
この手順なら、エージェントは速度を上げる道具として働き、チームはプロダクト判断を失わずに済む。iOSアプリ開発で差が出るのは、どのツールを使うかだけではなく、作業を渡す前の仕様と、戻ってきた変更を判断するレビュー設計である。
よくある質問
iPhoneだけでiOSアプリ開発を完結できるのか
実務では難しい。モバイルアプリは作業開始、進捗確認、差分の一次確認に向くが、ビルド、デバッグ、設計レビュー、リリース判断は、引き続き通常の開発環境とチームの確認が必要になる。
エージェントに任せやすい作業は何か
テスト追加、軽微なUI修正、再現手順の調査、ドキュメント更新、リファクタリング候補の整理は始めやすい。認証、課金、個人情報、医療や金融など高リスク領域は、作業範囲とレビュー条件を細かく定める。
App Store審査で注意する点は何か
Appleのガイドラインに沿って、機能、メタデータ、デモアカウント、バックエンド稼働状態、プライバシー情報を事前にそろえる。非自明な機能や外部サービス連携は、審査メモで説明できる状態にする。