software-mobile

モバイル開発

プラットフォームの選択、クロスプラットフォーム開発のトレードオフ、認証、通知、ディープリンク、リリース準備、ポリシーチェックなど、モバイル開発に共通する課題にはこのスキルを使用してください。iOS ネイティブの詳細な実装や書き換え作業には、software-ios-native を使用してください。iOS ネイティブのビルド、インストール、パッケージング、古いアプリのデバッグには、software-ios-runtime-debugging を使用してください。Android ネイティブの実装には、software-android-native を使用してください。

クイックリファレンス

タスク	iOS	Android	クロスプラットフォーム	デフォルト
UI	SwiftUI + UIKit 相互運用	Jetpack Compose + Views 相互運用	React Native、Flutter、KMP + ネイティブ UI	プラットフォーム固有の作業が多い場合はネイティブを優先
状態管理	@State、@Observable、@Environment	ViewModel + StateFlow	Zustand/RTK、Riverpod、共有ドメイン状態	プラットフォームネイティブの状態モデル
ナビゲーション	NavigationStack	Navigation Compose / Navigation Component	Expo Router または React Navigation	新規 Expo アプリでは Expo Router
ネットワーキング	URLSession + async/await	Retrofit/OkHttp/Ktor + coroutines	Fetch/Axios、生成されたクライアント	場当たり的な fetch より型付きクライアント
ストレージ	SwiftData/Core Data、Keychain	Room/DataStore、Keystore	MMKV/SQLite/WatermelonDB、セキュアストレージ	シークレットはプラットフォームのセキュアストレージに保管
テスト	Swift Testing + XCTest UI	JUnit + Compose Test + Macrobenchmark	Detox/Maestro、フレームワーク標準のテスト	パフォーマンスを測定し、決めつけない
リリース	プライバシーマニフェスト、App Review の確認	Play の target SDK、Data safety、署名	Expo/EAS またはネイティブのパイプライン	リリースごとにストアポリシーを再確認
CI / 署名	Xcode Cloud またはネイティブ CI	Gradle の署名 / Play App Signing	EAS Build またはネイティブのパイプライン	リリース署名がアプリのアテステーションとは別に機能することを確認
プッシュ通知の検証	Xcode から実機へ → APNs sandbox	設定によって FCM のデバッグ環境 / 本番環境を分離	本番の送信経路で環境ごとの配信を検証する必要がある	ローカルでのプッシュ通知の成功を TestFlight の検証と見なさない

このスキルを使用する場合

次のような場合にこのスキルを使用してください。

• iOS ネイティブ、Android ネイティブ、React Native、Flutter、Kotlin Multiplatform、ラッパーシェルからプラットフォームを選択する
• React Native、Expo、Flutter、Kotlin Multiplatform、WebView シェルに関するクロスプラットフォームの判断を行う
• モバイル認証、パスキー、プッシュ通知、オフラインファースト同期、ディープリンク、アプリストアへのリリース準備を行う

このスキルを使用しないケース

要件	代わりに使用するもの
Web 専用のフロントエンド	software-frontend
文字列、複数形、カタログ、翻訳パイプライン、バックエンドで生成されるローカライズ済みの文章	software-localisation（バックエンドで生成される文章のリファレンス）
バックエンド API の実装	software-backend
マネージドアプリバックエンド（Supabase、Firebase、Appwrite）	software-baas-platforms
iCloud／CloudKit／App Intents／Foundation Models を備えたネイティブ iOS アプリの骨組み	software-ios-native + software-ios-ai-engine
ネイティブ iOS への書き換え、SwiftUI、Xcode のワークフロー	software-ios-native
ネイティブ iOS のビルド／インストール／起動の失敗、古いアプリ、シミュレーターの不整合	software-ios-runtime-debugging
ネイティブ iOS のビジュアル監査	software-ios-design
iOS 固有のテストの詳細解説	qa-testing-ios
ネイティブ Android への書き換え、Kotlin、Gradle、Android Studio	software-android-native
ネイティブ Android のビルド／インストール／起動の失敗、エミュレーターの不整合	software-android-runtime-debugging
ネイティブ Android のビジュアル監査	software-android-design

プラットフォームの選択

Need to ship mobile product?
    │
    ├─ Single platform only?
    │   ├─ iOS → SwiftUI for new code, UIKit interop where needed
    │   └─ Android → Jetpack Compose for new code, Views interop where needed
    │
    ├─ Both iOS and Android?
    │   ├─ Native integrations / performance / platform fidelity dominate? → Separate native apps
    │   ├─ JS/TS team and fastest shared delivery? → React Native + Expo-managed for greenfield
    │   ├─ Fully shared rendering and custom UI control? → Flutter
    │   └─ Kotlin team, shared logic, native UI? → Kotlin Multiplatform
    │
    └─ Existing web app wrapper?
        ├─ Low-complexity shell → WebView / Capacitor
        └─ Meaningful native features → React Native or native modules

クロスプラットフォームのデフォルト

フレームワーク	デフォルト	状態
React Native	現行の RN リリースでは新アーキテクチャが必須です。レガシーアーキテクチャは削除され、newArchEnabled=false は無視されます。移行の対象となるバージョンについては RN のリリースノートを、レガシーアーキテクチャに対応する最後の SDK については Expo SDK の変更履歴を確認してください。判断のポイントは「依存するすべてのネイティブモジュール／ライブラリが移行済みか、相互運用レイヤーで対応されているか」です	オプトインではなく必須
Expo + Expo Router	新規の JS／TS アプリではチームのデフォルトです。カスタムネイティブコードには開発ビルドを使用し、埋め込みへの対応状況はインストール済みの Router リリースで確認してください	現行のデフォルト
Flutter	ネイティブらしさよりも、レンダリングとアニメーションの一元管理が重要な場合に有力です	現行
Kotlin Multiplatform	ネイティブ UI でビジネスロジックを共有するのに最適です。iOS 向けの Compose Multiplatform は安定版です。現行リリースで追加された内容はリリースノートを確認してください	単一の安定性に関する発表ではなく、リリースごとにライブラリの成熟度を検証してください

ワークフロー

1. 製品の範囲、対象プラットフォーム、ネイティブ要件、リリース上の制約を確認します。
2. Web 専用、バックエンド、または iOS ネイティブの詳細な検討は、関連するスキルに振り分けます。
3. 上記の選択ガイダンスに基づいてスタックを選択します。
4. 認証、プッシュ通知、オフライン時の動作、リリース判定条件、テストに関するガイダンスを適用します。
   • iOS のプッシュ通知では、ローカルの sandbox 経路と production 経路を個別に検証します。
   • プッシュ通知の承認は 2 つの判定条件として扱います。すなわち、通知が受け付けられて表示されることを確認する通信経路の検証と、コールドスタートおよびウォームスタートの状態からタップしてもフリーズやクラッシュが発生しないことを確認する起動経路の検証です。
5. 最終的な推奨を提示する前に、プラットフォームポリシーとフレームワークに関する最新情報を再確認します。

プラットフォーム選択の検証ゲート

ネイティブ、React Native、Flutter、KMP のいずれかを選ぶ前に、製品で最も難しいと考えられる機能を列挙します。たとえば、バックグラウンド実行、カメラ／メディアパイプライン、Bluetooth／ハードウェア SDK、ウィジェット／拡張機能、ディープリンク、オフライン時の競合解決、決済、アクセシビリティ、プラットフォーム固有の UI です。各候補の不確実性と影響度を順位付けします。同じフレームワークとバージョン範囲、ネイティブ依存関係、リリース構成、機能、代表的なデバイスクラスを対象としている既存の証拠があれば再利用し、その日付と担当者を記録します。

重大な候補のうち、ネイティブ対応、パフォーマンス、ライフサイクル、アクセシビリティ、パッケージングに関する重大な未解決リスクがあるものに限り、時間を区切ったスパイクを実施します。事前に合否基準を定めます。ビルドとパッケージング、ネイティブ SDK の統合、コールドスタートと操作の予算、アクセシビリティの挙動、オフライン時の動作／復旧、メンテナーのスキルを評価します。実際のリリース構成と、そのリスクに関係する最も古いデバイスクラスを使用します。スパイクによって、有料サービス、署名の利用枠、希少なデバイス、共有 CI クォータを、合意済みのタスク予算を超えて消費する場合は、まずそのリソースの使用許可を得ます。リスクの低い製品では、適用可能な本番環境の証拠と明示的な前提条件を添えた、文書化された判断で十分です。最も難しい機能が失敗するか、恒久的な独自のネイティブモジュールが必要になる場合は、そのモジュールを 2 つのプラットフォームで保守するコストを判断に含めます。難しい機能がなければ、製品開発の重複を減らせるスタックを優先します。

機能とネイティブへの切り替え手段

共有による提供とネイティブでの管理を比較検討する際は、cross-platform-comparison.md を読み込んでください。この一覧を使って、選択したスタックでなお必要となるネイティブ開発を特定してください。

スタック	切り替え手段	採用を決める前に実証すべき機能
ネイティブアプリを個別に開発	Swift/Objective-C および Kotlin/Java SDK を直接使用	2 つのプラットフォームでの実装とリリース管理
React Native / Expo	Turbo Native Modules、または開発ビルドでの Expo Modules	ハードウェア SDK、バックグラウンドでのライフサイクル、ネイティブ依存関係との互換性。Expo Go では任意のネイティブモジュールを読み込めません
Flutter	Platform channels / Pigeon、プラグイン、ネイティブビュー	カメラ／メディアのスループット、プラットフォームビューの合成、チャネルのスレッド処理
ネイティブ UI を使う KMP	プラットフォーム別のソースセットと iOS フレームワークの統合	Swift から利用する API、Kotlin/Native ライブラリのサポート、パッケージ化とシンボル化
Compose Multiplatform	共有 UI では必要な機能を提供できない場合のプラットフォーム API とネイティブ UI の相互運用	アクセシビリティ、入力、プラットフォーム固有の UI、拡張機能、ライフサイクル
Capacitor / WebView	ネイティブプラグイン とネイティブホスト	バックグラウンド実行、ハードウェア API、拡張機能のターゲット。ブラウザー API だけではこれらの機能を提供できません

KMP の iOS ツールチェーンの必須条件。 Apple 向けの最終バイナリには、ビジネスロジックを共有する場合でも macOS ホストと Xcode が必要です。プロジェクトの Kotlin プラグインについては Kotlin/Gradle/AGP/Xcode の互換性マトリックスを、デバイス／シミュレーターのアーキテクチャについてはサポートされているターゲット／ホストを確認してください。既存の CocoaPods 依存関係とモジュールの配布要件に応じて、Xcode との直接統合または依存関係マネージャーとの統合を選択し、シミュレーターでのビルドと署名済みデバイスアーカイブの両方で動作を確認してください。

アテステーションの必須条件。 機密性の高いサーバー操作については、スタックのネイティブモジュール／プラグインを通じた App Attest と Play Integrity の利用を検討してください。結果をサーバーで検証し、新しいチャレンジまたはリクエストの内容に結び付けてください。適用を必須にする前に、デバイス／API の利用可否とリリースの配布方法を確認してください。また、非対応デバイスや障害発生時の動作を定義してください。アテステーションは認証および認可と併用する不正利用の兆候であり、すべてのストア提出に必須の要件ではありません。詳細な脅威モデリングとセキュアストレージについては、software-security-appsec を参照してください。

プラットフォーム配信の必須条件

• iOS： アーキテクチャ、状態管理、並行処理、パフォーマンスについては、software-ios-native を参照してください。提出前に、プライバシーマニフェスト、理由の申告が必須の API、SDK の要件適合性を確認してください。各インストール環境で APNs の通信経路と通知を開く動作を検証してください。配布アーカイブの aps-environment エンタイトルメントを確認し、トークンの振り分け先をその環境に合わせてください。
• Android： Compose、状態管理、バックグラウンド処理、パフォーマンスについては、software-android-native を参照してください。アプリの種類とリリーストラックに応じた最新の Play のターゲット API 要件を確認し、データセーフティ、署名、バックグラウンドの制限を検証してください。不正利用のリスクに応じて、Play Integrity の利用を検討してください。

リリース運用、落とし穴、判断事項

iOS のリリース運用に関するゲート（TestFlight のチャンネル、アップロード経路、バックエンドのみの修正、実機でのスモークテストの証明、アップロードに必要な最小 Xcode/SDK）、既知の iOS および Android の実行時の落とし穴、専門家としての判断事項、アンチパターンの表については、references/platform-traps-and-judgment.md に記載されています。リリースの確定、プッシュ通知／アプリ起動経路の調査、またはプラットフォーム選定の推奨を行う前に、このドキュメントを読み込んでください。

• アーカイブ／アップロードの前に、必要な最小 Xcode/SDK を developer.apple.com/news/upcoming-requirements で確認してください。ローカルビルドに合格していても、受け付け時に却下されることがあります。
• 該当する App Review 条項に基づき、アカウント削除、ログインサービス要件、サブスクリプションの開示と解約について確認してください。認証機能があるだけで、Sign in with Apple が必須になるわけではありません。

OTA アップデートと外部決済

どちらも頻繁に変更されるストアポリシー上の判断事項です。判断ロジック、運用ルール、主要ページへのリンクは references/store-update-and-payment-policy.md に記載されています。

• OTA／コードプッシュ。 Apple のガイドライン 2.5.2 と、同ガイドラインで解釈されるインタープリターコードのライセンス条項を、Google Play のインタープリター例外とは別に確認してください。JS バンドルは、機能変更を包括的に許可するものではありません。ネイティブの変更や新機能には、原則としてストアビルドを使用してください。OTA は、該当するポリシー、実行時の互換性、段階的なロールアウト、ロールバックを参考資料で確認した後にのみ使用してください。
• 外部決済／外部誘導禁止ポリシー。 米国ストアフロントでの外部リンクや、地域別の代替決済・外部オファープログラムは、どちらのストアにも存在します。適用資格、権利、開示 UI、適用される残りの手数料は、ストアフロントによって異なり、判決後に変更されることがあります。判断時点で、Apple のガイドライン／StoreKit External Purchase ページと、Google Play の Payments／billing-program ページを参照し、ストアフロントごとに判断してください。サーバー側でストアが報告するストアフロントに基づいて分岐し、ストア決済に戻すキルスイッチを用意してください。手数料や日付を記憶に頼って引用しないでください。

リリース準備チェックリスト

iOS App Store

• アイコン、起動時アセット、権限に関する説明文が完成している
• プライバシーマニフェストと必須理由 API が、アプリのターゲットおよび記載されている SDK に対して正しい
• サードパーティ SDK のコンプライアンスが Apple の最新要件に適合している
• アクセシビリティ、ディープリンク、プッシュ通知のフローを最新デバイスでテスト済み
• App Store のメタデータ、プライバシーポリシー、TestFlight のテスト範囲を準備済み
• App Store Connect の準備をすべて完了 — references/app-store-connect-checklist.md を参照

Google Play

• ターゲット SDK が現在の Play ターゲット API 要件を満たしている（Play のターゲット SDK ページでレベルと期限を確認してください。要件は毎年変わります）
• プライバシーポリシー、コンテンツレーティング、データセーフティを完成させている
• 最新の Android の制約下で、署名、認証、バックグラウンド動作をテスト済み。使用する場合はアテステーションもテスト済み
• 内部／クローズド／オープンテストトラックを適切に設定している

既知の落とし穴

• プラットフォーム固有の検証を行わずに、単一のモバイルフレームワークの選択で、リリース、権利、ディープリンク、プッシュ通知の動作に関する問題を解決できると考える
• ローカルのデバッグビルドだけで認証、プッシュ通知、ディープリンクを検証し、それを本番環境への準備ができた証拠として扱う
• サンドボックス、ステージング、本番環境のモバイルバックエンドを混在させ、インストールごとの動作を再現できなくする
• エミュレーターやシミュレーターでの成功を、バックグラウンド実行、通知の配信、デバイス固有のライフサイクルの証拠として扱う
• ネイティブ統合、拡張ポイント、ストアポリシー上の制約を洗い出す前にクロスプラットフォームのスタックを選び、ネイティブへの切り替えを余儀なくされる

ナビゲーション

参考資料

• references/ios-best-practices.md — iOS ネイティブの担当者向け情報です。実装を引き継ぐ際に読み込んでください
• references/android-best-practices.md — Android ネイティブの担当者向け情報です。実装を引き継ぐ際に読み込んでください
• references/cross-platform-comparison.md — React Native／Flutter／KMP／ネイティブのトレードオフ
• references/deep-linking-guide.md — Universal Links、App Links、Expo Router、Dynamic Links 廃止後の対応
• モバイルテスト（レイヤー、デバイスマトリックス、スナップショット／UI／E2E、フレーク）は qa-testing-mobile が担当します。test-layers-and-suite-anti-patterns.md から始めてください
• references/offline-first-architecture.md — ローカルファーストのストレージ、同期、競合解決
• references/push-notifications-guide.md — APNs、FCM、権限、チャンネル、分析
• references/operational-playbook.md — リリース運用、判断表、集約されたパターン
• references/app-store-connect-checklist.md — App Store Connect の項目別チェックリスト
• references/store-update-and-payment-policy.md — OTA／コードプッシュのポリシーと、外部決済／誘導禁止に関する判断
• references/platform-traps-and-judgment.md — iOS のリリース運用、プラットフォーム特有の落とし穴、判断事項、アンチパターン
• data/sources.json — 最新の公式および厳選された外部ソース

共通チェックリストとユーティリティ

• ../software-clean-code-standard/assets/checklists/mobile-release-checklist.md
• ../software-clean-code-standard/references/auth-utilities.md
• ../software-clean-code-standard/references/error-handling.md
• ../software-clean-code-standard/references/resilience-utilities.md
• ../software-clean-code-standard/references/testing-utilities.md
• ../software-clean-code-standard/references/clean-code-standard.md

テンプレート

• クロスプラットフォーム: assets/cross-platform/template-webview.md（WebView ラッパー、iOS + Android）
• ネイティブコードはネイティブスキルにあります。iOS については、networking-and-data-loading.md と swiftui-composition-patterns.md を参照してください。Android については、coroutine-and-compose-recipes.md を参照してください。Keychain と Keystore のストレージについては、template-mobile-security.md を参照してください。

関連スキル

• software-ios-native — iOS 17 以降のネイティブ実装、書き換え、エージェントのワークフロー
• software-ios-ai-engine — Apple Foundation Models、ローカル AI エンジン、オンデバイス検索
• software-ios-runtime-debugging — ビルド／インストール／起動の確認、シミュレーターの差異、パッケージングのトリアージ
• software-ios-design — iOS ネイティブの視覚的階層、HIG、スクリーンショットのレビュー
• software-android-native — Android ネイティブ、Kotlin、Jetpack Compose、エージェントのワークフロー
• software-android-design — Material Design 3、スクリーンショットのレビュー
• software-android-runtime-debugging — Android のビルド／インストール／起動の確認、エミュレーターの差異
• software-frontend — Web UI と共有プロダクトのインターフェース
• software-backend — API 設計、認証、バックエンドの契約
• software-baas-platforms — Supabase、Firebase、Appwrite、PocketBase
• qa-testing-strategy — CI ゲート、信頼性、リリースへの確信
• qa-resilience — ネットワークの耐障害性と障害モードの設計
• qa-testing-ios — iOS 固有のテスト
• software-ui-ux-design — モバイル UX とアクセシビリティ

リリース情報の確認

リリースを推奨する前に、data/sources.json を使用して、Apple のアップロード／SDK 要件とサードパーティ SDK の要件、Google のターゲット API ポリシー、インストール済みフレームワークのアップグレードノートを確認してください。アクセスできない提出ゲートは未検証として扱い、準備が整ったという判断を妨げます。ソースリストの編集日から、すべてのページが確認済みであるとは判断できません。

学びのループ

過去の判断や落とし穴が関係する場合は、learnings.consolidated.md があれば参照してください。必要な履歴を確認する場合、または利用可能な代替手段としてのみ learnings.md を使用してください。それ以外の場合は、どちらも参照しないでください。

適用後、覚えておく価値のあるパターン、再発防止が必要なミス、または意外だった分野の事実に遭遇した場合は、agents-skills-feedback-loop/scripts/append_learning.py を使って learnings.md に日付付きの箇条書きを 1 つ追記してください。SKILL.md 自体は変更しないでください。