mobile-development

モバイル開発

iOS と Android のモバイルアプリを構築するためのスキルです。ネイティブ（Swift/SwiftUI、Kotlin/Jetpack Compose）とクロスプラットフォーム（Flutter、React Native）の各スタックに合わせた詳しい情報を用意しています。4つのスタックはすべて、共通のエージェントワークフロー（ひな形の作成、ビルドと署名、デバイスやエミュレーターでのテスト、ストアへの公開）を共有しているため、フレームワークごとのリファレンスを備えた1つのファミリースキルとしてまとめています。これは frontend-engineering の先例に倣ったものです。以下の共通ワークフローを読み込んだ後、実際に使用するフレームワークのリファレンスを読み込んでください。

フレームワーク	スタック	リファレンス（必要に応じて読み込み）
iOS	Swift, SwiftUI/UIKit, Xcode	references/ios.md
Android	Kotlin, Jetpack Compose, Gradle	references/android.md
Flutter	Dart, Flutter SDK	references/flutter.md
React Native	TypeScript/JavaScript, React, Metro	references/react-native.md

使用する場面

モバイル開発ライフサイクルのいずれかの作業が含まれる場合は、このスキルを読み込んでください。

• ひな形の作成 — iOS、Android、Flutter、React Native の新しいモバイルプロジェクトを作成する場合。フレームワークの選定、プロジェクトの初期化、プラットフォームのツールチェーンのセットアップが該当します。
• ビルドと署名 — デバッグビルドまたはリリースビルドのコンパイル、コード署名（証明書、プロビジョニングプロファイル、キーストア、アプリ署名）の設定、配布可能な成果物（.ipa、APK、AAB）の作成が該当します。
• デバイスやエミュレーターでのテスト — iOS シミュレーター、Android エミュレーター、または実機での実行とデバッグが該当します。デバイスのプロビジョニング、接続、プラットフォーム固有のランタイム動作も含みます。
• ストアへの公開 — App Store（TestFlight、App Store Connect）または Google Play（内部テスト、クローズドテスト、オープンテストのトラック、Play Console）への申請、およびストア審査に向けた準備状況の検討が該当します。
• モバイル固有の動作 — アプリのライフサイクルとバックグラウンド動作、オフラインストレージと同期、プッシュ通知、ディープリンク、モバイルテスト（ユニット、ウィジェット、UI、デバイスファームの各テスト）が該当します。

使用しない場面

• ウェブフロントエンド — コンポーネントアーキテクチャ、状態管理、ブラウザーの動作については frontend-engineering を参照してください。このスキルの対象は、iOS および Android デバイスで動作するアプリです。
• バックエンドサービスと API — サーバーサイドのロジック、API 設計、サーバー上のデータ永続化については backend-engineering を参照してください。モバイルアプリはこれらの API を利用するものであり、置き換えるものではありません。
• デスクトップまたはウェブ向けプラットフォーム — デスクトップ／ウェブ向けの Flutter や、ウェブ向け React Native（React Native Web）では、公開とテストの対象が異なります。このスキルの対象は、iOS および Android のアプリストアプラットフォームです。
• クロスプラットフォームのウェブファースト開発 — 成果物がウェブサイトまたは PWA の場合は、代わりに frontend-engineering を使用してください。

モバイルエンジニアの担当領域

担当すること	担当しないこと
モバイルアプリのアーキテクチャ — プラットフォーム構成、アプリのエントリーポイント、ナビゲーション、デバイス上の状態管理	バックエンド API、データモデル、サーバー側の永続化 — これらは backend-engineering の担当です
フレームワークとツールチェーンのセットアップ — Xcode/Gradle のプロジェクト設定、Flutter/React Native のひな形、依存関係管理	Web フロントエンドのアーキテクチャとブラウザーの動作 — これらは frontend-engineering の担当です
ビルドと署名 — デバッグ／リリースビルド、証明書、プロビジョニングプロファイル、キーストア、アプリの署名、バージョン管理、ビルド番号	サーバーソフトウェアのリリース調整とロールアウトプロセス — これらは release-engineering の担当です
デバイスとエミュレーターでのテスト — シミュレーター、エミュレーター、実機、adb/xcrun によるデバイスのワークフロー	プロダクト全体のテスト戦略、カバレッジ、品質ゲート — これらは qa-methodology の担当です
モバイル固有の事項 — ライフサイクル／バックグラウンド処理、オフライン対応と同期、プッシュ通知、ディープリンク、モバイルのパフォーマンス	ユーザージャーニー、ワイヤーフレーム、インタラクションデザイン — これらは product-design-and-ux の担当です
ストアへの申請 — TestFlight、App Store Connect、Play Console、リリーストラック、ストア掲載用メタデータ	CI/CD パイプラインのインフラストラクチャ — これらは platform-engineer の担当です

モバイル開発で共通するワークフロー

モバイルのタスクは、フレームワークにかかわらず、同じ4つのステップに従います。フレームワーク固有の詳細については、各フレームワークのリファレンスを参照してください。必要なステップで確認します。

1. ひな形を作成する

コードを生成する前に、アプリの要件を明確にします。

• プラットフォームとフレームワーク — iOS ネイティブ、Android ネイティブ、Flutter、React Native のいずれかを選びます。チームのスキル、対象ユーザー、機能ごとのニーズに基づいて選択してください（「基本原則」を参照）。
• 最小 OS バージョン — サポートする iOS と Android の最も古いバージョンを決めます。以下のすべての判断（API、依存関係、テスト）は、この決定に基づきます。
• プロジェクトの初期化 — フレームワークの標準ツール（xcodebuild/Xcode テンプレート、Android Studio/Gradle、flutter create、npx @react-native-community/cli init、または create-expo-app）でプロジェクトを生成し、アプリのコードを追加する前にひな形をコミットします。これにより、ツールチェーンのアップグレードをレビューできる状態に保てます。
• 信頼できる唯一の情報源 — クロスプラットフォームのフレームワークを使用する場合、両方のプラットフォームをビルドできる単一のプロジェクトルートにします。これにより、リポジトリから成果物を再現できます。

2. ビルドして署名する

自分のマシンでしか動作しないものは、ビルドとはいえません。

• CI で一度ビルドする — リリースビルドは IDE 上だけでなく、クリーンなマシンまたは CI ランナー上でも再現できる必要があります。ツールチェーンのバージョン（Xcode、JDK/Gradle、Flutter SDK、Node）を固定してください。
• 署名とビルドは別の工程 — 署名用のアセット（証明書、プロビジョニングプロファイル、キーストア）はリポジトリに含めず、環境変数または安全なシークレットストレージを通じて参照してください。各プラットフォームでの配置場所については、各フレームワークのリファレンスを参照してください。
• 識別可能な成果物 — テスターやクラッシュレポートでビルドを特定できるよう、リリースごとにバージョン番号とビルド番号を増やす必要があります。
• 成果物の形式を把握する — iOS は .ipa、Android は APK と AAB、さらにフレームワーク固有の中間成果物を使用します。ストアへの申請には厳格な形式要件があります（たとえば、Google Play では新しいアプリに AAB が必須です）。

3. デバイスとエミュレーターでテストする

コードが実行される環境でテストし、都合のよい環境で済ませないでください。

• 速度重視のエミュレーター／シミュレーターと、実態確認のデバイス — シミュレーターとエミュレーターは高速でスクリプト化できますが、実機ではネットワーク、バッテリー、メモリ、センサーの実際の挙動を確認できます。両方を対象にしてください。
• クリーンインストール — 古いバージョンに上書きして再ビルドするだけでなく、新規インストールをテストし、初回起動、ストレージ、移行に関するバグを見つけます。
• デバイスマトリックス — スコープで定めた OS バージョンと画面サイズに加え、低メモリやストレージ不足の条件も対象にします。マトリックスがローカルのハードウェアで対応できる範囲を超えたら、デバイスファーム（Firebase Test Lab、BrowserStack、Xcode Cloud）を利用してください。
• デバッグ版とリリース版の同等性 — デバッグビルドとリリースビルドは異なるプログラムです（proguard／縮小化、不要コードの除去、最適化）。ストアに提出する前に、署名済みのリリース成果物でスモークテストを実施してください。

4. ストアにリリースする

申請は後回しにせず、チェックリストに沿って進めます。

• まずテストトラックへ — 本番リリースの前に、TestFlight（iOS）と内部テストまたはクローズドテストトラック（Android）で配布してください。ストアを初めての実機フィードバックの場にしてはいけません。
• ストア公開の準備 — メタデータ、スクリーンショット、プライバシーポリシー、データ収集に関する申告、プライバシー情報ラベルは、アプリの実際の動作と一致していなければなりません。審査要件は変更されるため、提出時期が近づいたら再確認してください。
• 審査で求められること — プライバシー情報の開示不足、誤解を招くメタデータ、起動時のクラッシュ、サインインやアプリ内購入フローの不具合を理由に、どちらのストアもアプリを却下します。アップロード前に、プラットフォームの審査チェックリストに沿ってアプリを確認してください。
• 段階的リリース — 段階的なロールアウト（Play での段階的リリース、App Store Connect での段階的リリース）を優先し、リグレッションの影響が全ユーザーに及ぶ前に、影響を受けるユーザーを少数に抑えましょう。

モバイル固有の考慮事項

以下の点で、モバイル開発は Web やデスクトップの開発と異なります。

アプリのライフサイクルとバックグラウンド動作

モバイル OS はアプリを積極的に終了・一時停止するため、ライフサイクルへの対応は必須です。

• ライフサイクルの状態 — iOS（フォアグラウンド／バックグラウンド／非アクティブ、シーンベースのライフサイクル）と Android（アクティビティ／フラグメントの状態、プロセス終了）。こうした遷移をまたいで永続化されない状態は失われます。
• バックグラウンド実行は特権 — どちらのプラットフォームもバックグラウンド処理を制限しています。OS に逆らうのではなく、プラットフォームが認める仕組み（バックグラウンドモード、WorkManager、バックグラウンドフェッチ、プッシュ通知による起動）を使用してください。
• プロセス終了 — OS はいつでもアプリを終了できます。処理中の状態を保存し、再起動時にはメモリではなくストレージから UI の状態を復元してください。

オフラインと同期

モバイルネットワークは不安定なため、オフラインを第一級の動作モードとして扱います。

• オフラインファーストのストレージ — ローカルの永続化（Core Data、Room、SQLite ベースのストア、またはキー・バリューストア）は、切断中の信頼できる情報源です。ネットワークは依存先ではなく、同期のための経路です。
• 同期のセマンティクス — 競合解決（最終書き込み優先、フィールド単位のマージ、または明示的な競合 UI）、冪等な書き込み、バックオフを伴う再試行を定義してください。古いローカルデータで新しいリモートデータを決して無条件に上書きしないでください。
• 変更をキューに登録する — オフライン中の書き込みはキューに登録し、接続が回復したら順番に再実行する必要があります。また、同期状態を明確にユーザーへ提示してください。

モバイル固有のテスト

単体テストに加えて、モバイルコードにはプラットフォームを考慮したテストが必要です。

• 単体テストとウィジェット／コンポーネントテスト — フレームワークレベルのロジック、リデューサー、状態を、デバイスを使わずにテストします（XCTest、JUnit、Flutter widget tests、Jest）。
• UI／計装テスト — デバイスまたはエミュレーター上で実際の UI を操作します（XCUITest、Espresso／Compose UI tests、Flutter integration_test、Detox）。
• デバイスファームでのカバレッジ — デバイスファーム上で UI テストスイートをデバイスマトリックス全体に対して実行します。1 台のデバイスで成功したテストが、他のデバイスでも成功する保証はありません。
• パフォーマンスとバッテリー — 機能だけでなく、起動時間、フレームレート、メモリ、ネットワークを実機で測定してください。

基本原則

話題性ではなく制約に基づいてフレームワークを選びます — ネイティブの iOS と Android はプラットフォームとの最も深い統合を実現し、Flutter と React Native はプラットフォーム間でコードを共有できます。適切な選択は、チームのスキル、アプリが必要とするデバイス API、プラットフォームごとの作業をどの程度許容できるかによって決まります。アプリの実際の要件に合わせて判断してください。

OS のライフサイクルは契約の一部です — モバイルアプリは常に一時停止、終了、バックグラウンド化されます。アプリが常時起動してオンラインであることを前提とする機能は、いずれ動作しなくなります。最初のコミットから、プロセスの終了と切断を前提に設計してください。

署名とビルドはリリースエンジニアリングであり、CI の飾りではありません — 再現可能なビルドと署名ができないアプリは、リリース、パッチ適用、監査を行えません。署名用アセットは秘密に保ち、バージョンを固定して、スクリプトで扱えるようにし、リリースパイプラインを本番環境のインフラとして扱ってください。

出荷する成果物をテストしてください — ユーザーやレビュアーが目にするのはデバッグビルドではなく、署名済みリリースビルドです。TestFlight、Play、または App Review チームに提出する前に、実機でスモークテストを行ってください。

ストアの要件は変わり続けます — プライバシーに関する申告、ターゲット API レベル、提出形式は毎年変わります。記憶しているルールに頼らず、提出時期が近づいたら最新のストアドキュメントで要件を確認してください。

関連スキル

• frontend-engineering — Web フロントエンドの方法論です。このスキルが手本とする兄弟スキル群の先例であり、ブラウザベースの UI 作業のルーティング先です。
• backend-engineering — モバイルアプリが利用する API とサービスです。サーバーサイドの作業のルーティング先です。
• release-engineering — リリースのオーケストレーション、バージョン管理、ロールアウトの方法論です。ストアへのリリースは、この専門分野の一例です。
• qa-methodology — テスト戦略と品質ゲートです。製品全体のテスト計画のルーティング先です。
• platform-engineering — モバイルビルドを大規模に出荷するための CI/CD パイプラインとビルドインフラストラクチャです。