ck:mobile-development

モバイル開発スキル

最新のフレームワーク、ベストプラクティス、モバイルファーストの思考パターンを活用した、本番環境に対応できるモバイル開発です。

使用する場面

• モバイルアプリケーション（iOS、Android、クロスプラットフォーム）を構築するとき
• モバイルファーストのデザインや UX パターンを実装するとき
• モバイル特有の制約（バッテリー、メモリ、ネットワーク、小さな画面）に合わせて最適化するとき
• ネイティブとクロスプラットフォームの技術選定をするとき
• オフラインファーストのアーキテクチャとデータ同期を実装するとき
• プラットフォーム固有のガイドライン（iOS HIG、Material Design）に従うとき
• モバイルアプリのパフォーマンスとユーザーエクスペリエンスを最適化するとき
• モバイルセキュリティと認証を実装するとき
• モバイルアプリケーションをテストするとき（単体、統合、E2E）
• App Store と Google Play にデプロイするとき

技術選定ガイド

クロスプラットフォームフレームワーク：

• React Native：JavaScript の知識、ウェブコードの共有、成熟したエコシステム（星 121K、認知度 67%）
• Flutter：パフォーマンスが重要なアプリ、複雑なアニメーション、最も急速に成長（星 170K、採用率 46%）

ネイティブ開発：

• iOS（Swift/SwiftUI）：iOS の最大限のパフォーマンス、最新機能、Apple エコシステムとの統合
• Android（Kotlin/Jetpack Compose）：Android の最大限のパフォーマンス、Material Design 3、プラットフォームの最適化

詳細なフレームワーク比較については、references/mobile-frameworks.md を参照してください。

モバイル開発の考え方

モバイル開発の 10 の戒め：

1. パフォーマンスは機能ではなく土台です - 読み込みに 3 秒以上かかるアプリは 70% が使われなくなります
2. すべてのキロバイト、すべてのミリ秒が重要です - モバイルの制約は現実のものです
3. デフォルトでオフラインファーストにします - ネットワークは不安定なため、それを前提に設計します
4. ユーザーの状況 > 開発者の環境 - 実際の利用シナリオを想定します
5. プラットフォームを意識しつつ、プラットフォームに縛られないようにします - プラットフォームの慣習を尊重します
6. 完璧を目指すのではなく、反復します - リリース、測定、改善のサイクルが生き残る鍵です
7. セキュリティとアクセシビリティは設計段階から考慮します - 後付けにしません
8. 実機でテストします - シミュレーターのパフォーマンスは当てになりません
9. 複雑さに合わせてアーキテクチャを拡張します - シンプルなアプリを過剰設計しません
10. 継続的な学習が生き残る鍵です - モバイルを取り巻く状況は急速に進化します

思考パターンと意思決定フレームワークについては、references/mobile-mindset.md を参照してください。

リファレンスの案内

コア技術：

• mobile-frameworks.md - React Native、Flutter、Swift、Kotlin、フレームワーク比較表、それぞれを使用する場面
• mobile-ios.md - Swift 6、SwiftUI、iOS のアーキテクチャパターン、HIG、App Store の要件、プラットフォーム機能
• mobile-android.md - Kotlin、Jetpack Compose、Material Design 3、Play Store、Android 固有の機能

ベストプラクティスと開発の考え方：

• mobile-best-practices.md - モバイルファーストの設計、パフォーマンス最適化、オフラインファーストのアーキテクチャ、セキュリティ、テスト、アクセシビリティ、デプロイ、分析
• mobile-debugging.md - デバッグツール、パフォーマンスのプロファイリング、クラッシュ分析、ネットワークのデバッグ、プラットフォーム固有のデバッグ
• mobile-mindset.md - 思考パターン、意思決定フレームワーク、プラットフォーム固有の考え方、よくある落とし穴、デバッグ戦略

重要なベストプラクティス（2024～2025年）

パフォーマンス目標：

• アプリの起動時間：2秒未満（3秒を超えると70％が離脱します）
• メモリ使用量：一般的な画面で100MB未満
• ネットワークリクエスト：積極的に一括処理し、キャッシュします
• バッテリーへの影響：Doze Mode とバックグラウンド制限を遵守します
• アニメーション：60 FPS（1フレームあたり16.67ms）

アーキテクチャ：

• 小～中規模のアプリには MVVM（明確な分離とテストのしやすさ）
• 大規模なエンタープライズアプリには MVVM + Clean Architecture
• ハイブリッド同期（プッシュ + プル）によるオフライン優先設計
• 状態管理：Zustand（React Native）、Riverpod 3（Flutter）、StateFlow（Android）

セキュリティ（OWASP Mobile Top 10）：

• 認証には OAuth 2.0 + JWT + 生体認証
• 機密データには Keychain（iOS）/ KeyStore（Android）
• ネットワークセキュリティには証明書ピンニング
• 認証情報や API キーをハードコードしないでください
• 適切なセッション管理を実装します

テスト戦略：

• 単体テスト：ビジネスロジックのカバレッジ70％以上
• 統合テスト：重要なユーザーフロー
• E2E テスト：Detox（React Native）、Appium（クロスプラットフォーム）、XCUITest（iOS）、Espresso（Android）
• リリース前の実機テストは必須です

デプロイ：

• 複数プラットフォームの自動化には Fastlane
• 段階的なロールアウト：内部 → クローズド → オープン → 本番
• 必須：iOS 17 SDK（2024年）、Android 15 API 35（2025年8月）
• CI/CD により開発時間を20％削減できます

すばやく選べる判断マトリクス

ニーズ	選択肢
JavaScript チーム、Web コードの共有	React Native
パフォーマンスが重要、複雑なアニメーション	Flutter
iOS のパフォーマンスを最大化、最新機能	Swift/SwiftUI ネイティブ
Android のパフォーマンスを最大化、Material 3	Kotlin/Compose ネイティブ
迅速なプロトタイピング	React Native + Expo
デスクトップ + モバイル	Flutter
JavaScript スキルを持つエンタープライズ	React Native
リソースが限られたスタートアップ	Flutter または React Native
ゲームや高度なグラフィックス	ネイティブ（Swift/Kotlin）または Unity

フレームワークの簡易比較（2024～2025年）

基準	React Native	Flutter	Swift/SwiftUI	Kotlin/Compose
スター数	121K	170K	該当なし	該当なし
採用率	35%	46%	iOS のみ	Android のみ
パフォーマンス	ネイティブの80～90%	ネイティブの85～95%	ネイティブの100%	ネイティブの100%
開発速度	高速（ホットリロード）	非常に高速（ホットリロード）	高速（Xcode Previews）	高速（Live Edit）
学習曲線	易しい（JavaScript）	中程度（Dart）	中程度（Swift）	中程度（Kotlin）
UI パラダイム	コンポーネントベース	ウィジェットベース	宣言型	宣言型
コミュニティ	非常に大規模（npm）	成長中	Apple エコシステム	Android エコシステム
最適な用途	JS チーム、Web 共有	パフォーマンス、アニメーション	iOS 専用アプリ	Android 専用アプリ

実装チェックリスト

プロジェクトのセットアップ：

• フレームワークの選択 → プロジェクトの初期化 → 開発環境の設定 → バージョン管理のセットアップ → CI/CD の設定 → チーム標準の策定

アーキテクチャ：

• パターンの選択（MVVM/Clean） → フォルダーのセットアップ → 状態管理 → ナビゲーション → API 層 → エラー処理 → ロギング

コア機能：

• 認証 → データ永続化 → API 統合 → オフライン同期 → プッシュ通知 → ディープリンク → アナリティクス

UI/UX：

• デザインシステム → プラットフォームのガイドライン → アクセシビリティ → レスポンシブレイアウト → ダークモード → ローカライズ → アニメーション

パフォーマンス：

• 画像の最適化 → 遅延読み込み → メモリプロファイリング → ネットワークの最適化 → バッテリーテスト → 起動時間の最適化

品質：

• 単体テスト（70％以上） → 統合テスト → E2E テスト → アクセシビリティテスト → パフォーマンステスト → セキュリティ監査

セキュリティ：

• セキュアストレージ → 認証フロー → ネットワークセキュリティ → 入力値検証 → セッション管理 → 暗号化

デプロイ：

• アプリアイコン／スプラッシュ画面 → スクリーンショット → ストアの掲載情報 → プライバシーポリシー → TestFlight／内部テスト → 段階的なロールアウト → モニタリング

プラットフォーム固有のガイドライン

iOS（Human Interface Guidelines）：

• ネイティブのナビゲーションパターン（タブバー、ナビゲーションバー）
• iOS のデザインパターン（引っ張って更新、スワイプアクション）
• San Francisco フォント、iOS のカラーシステム
• 触覚フィードバック、3D Touch／Haptic Touch
• セーフエリアとノッチに配慮する

Android（Material Design 3）：

• Material のナビゲーション（ボトムナビゲーション、ナビゲーションドロワー）
• フローティングアクションボタン、Material コンポーネント
• Roboto フォント、Material You のダイナミックカラー
• タッチフィードバック（波紋効果）
• システムバーとジェスチャーに配慮する

避けるべきよくある落とし穴

1. シミュレーターだけでテストする - 実機で実際のパフォーマンスを確認できます
2. プラットフォームの慣習を無視する - ユーザーはプラットフォーム固有のパターンを期待しています
3. オフライン時の処理がない - ネットワーク障害は発生します
4. メモリ管理が不十分 - クラッシュや UX の低下につながります
5. 認証情報をハードコードする - セキュリティ上の脆弱性になります
6. アクセシビリティに対応しない - 15％以上のユーザーを排除することになります
7. 時期尚早な最適化 - 想定ではなく、指標に基づいて最適化します
8. 過剰な設計 - シンプルに始め、必要に応じて拡張します
9. 実機テストを省略する - シミュレーターではバッテリーやネットワークの問題を確認できません
10. バッテリーに配慮しない - バックグラウンド処理には正当な理由が必要です

パフォーマンス予算

推奨目標：

• アプリサイズ：初回ダウンロードは <50MB、合計で <200MB
• 起動時間：操作可能になるまで <2 秒
• 画面の読み込み：キャッシュデータの場合は <1 秒
• ネットワークリクエスト：API 呼び出しは <3 秒
• メモリ：通常の画面では <100MB、ピーク時は <200MB
• バッテリー：アクティブな使用 1 時間あたりの消費を <5％に抑える
• フレームレート：60 FPS（1 フレームあたり 16.67ms）

リソース

公式ドキュメント：

• React Native: https://reactnative.dev/
• Flutter: https://flutter.dev/
• iOS HIG: https://developer.apple.com/design/human-interface-guidelines/
• Material Design: https://m3.material.io/
• OWASP Mobile: https://owasp.org/www-project-mobile-top-10/

ツールとテスト：

• Detox E2E: https://wix.github.io/Detox/
• Appium: https://appium.io/
• Fastlane: https://fastlane.tools/
• Firebase: https://firebase.google.com/

コミュニティ：

• React Native Directory: https://reactnative.directory/
• Pub.dev（Flutter パッケージ）: https://pub.dev/
• Awesome React Native: https://github.com/jondot/awesome-react-native
• Awesome Flutter: https://github.com/Solido/awesome-flutter