Guides mobile platform selection and delivery across native and cross-platform stacks. Use when planning auth, push, deep links, releases, or app architecture for iOS/Android.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Use this skill for platform choice, cross-platform tradeoffs, and shared mobile concerns such as authentication, notifications, deep linking, release readiness, and policy checks. For deep native iOS implementation or rewrite work, route to software-ios-native. For native iOS build, install, packaging, or stale-app debugging, route to software-ios-runtime-debugging. For native Android implementation, route to software-android-native.
| Task | iOS | Android | Cross-Platform | Default |
|---|---|---|---|---|
| UI | SwiftUI + UIKit interop | Jetpack Compose + Views interop | React Native, Flutter, KMP + native UI | Native first for platform-heavy work |
| State | @State, @Observable, @Environment | ViewModel + StateFlow | Zustand/RTK, Riverpod, shared domain state | Platform-native state models |
| Navigation | NavigationStack | Navigation Compose / Navigation Component | Expo Router or React Navigation | Expo Router for greenfield Expo apps |
| Networking | URLSession + async/await | Retrofit/OkHttp/Ktor + coroutines | Fetch/Axios, generated clients | Typed clients over ad hoc fetches |
| Storage | SwiftData/Core Data, Keychain | Room/DataStore, Keystore | MMKV/SQLite/WatermelonDB, secure storage | Keep secrets in platform secure storage |
| Testing | Swift Testing + XCTest UI | JUnit + Compose Test + Macrobenchmark | Detox/Maestro, framework-native tests | Measure performance, do not assume it |
| Release | Privacy manifests, App Review checks | Play target SDK, Data safety, signing | Expo/EAS or native pipelines | Re-check store policy before each cut |
| CI / signing | Xcode Cloud or native CI | Gradle signing / Play App Signing | EAS Build or native pipelines | Prove release signing separately from app attestation |
| Push proof | Xcode real-device → APNs sandbox | FCM debug / prod separation by config | Production send path must prove delivery per environment | Never treat local push success as TestFlight proof |
Use this skill when you need:
| Need | Use Instead |
|---|---|
| Web-only frontend | software-frontend |
| Strings, plurals, catalogs, translation pipeline, backend-generated localized prose | software-localisation (backend prose reference) |
| Backend API implementation | software-backend |
| Managed app-backend (Supabase, Firebase, Appwrite) | software-baas-platforms |
| Native iOS app skeleton with iCloud/CloudKit/App Intents/Foundation Models | software-ios-native + software-ios-ai-engine |
| Native iOS rewrite, SwiftUI, or Xcode workflows | software-ios-native |
| Native iOS build/install/launch failures, stale-app, simulator drift | software-ios-runtime-debugging |
| Native iOS visual audits | software-ios-design |
| iOS-specific testing deep dives | qa-testing-ios |
| Native Android rewrite, Kotlin, Gradle, Android Studio | software-android-native |
| Native Android build/install/launch failures, emulator drift | software-android-runtime-debugging |
| Native Android visual audits | 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
| Framework | Default | Status |
|---|---|---|
| React Native | New Architecture is mandatory in current RN releases: the Legacy Architecture is removed and newArchEnabled=false is ignored. Check the RN release notes for the cutoff version and the Expo SDK changelog for the last Legacy-capable SDK. The decision point is "is every native module/library we depend on migrated or covered by the interop layer" | Mandatory, not opt-in |
| Expo + Expo Router | Team default for a JS/TS greenfield app; use a development build for custom native code and check the installed Router release for embedding support | Active default |
| Flutter | Strong when shared rendering and animation control matter more than native feel | Active |
| Kotlin Multiplatform | Best fit for shared business logic with native UI; Compose Multiplatform for iOS is stable; check its release notes for what the current release adds | Validate library maturity per release, not from a single stability announcement |
sandbox path and the production path separately.Before committing to native, React Native, Flutter, or KMP, list the product's hardest likely capability: background execution, camera/media pipeline, Bluetooth/hardware SDK, widgets/extensions, deep links, offline conflict resolution, payments, accessibility, or platform-specific UI. Rank each candidate's uncertainty and consequence. Reuse existing evidence when it covers the same framework and version range, native dependency, release configuration, capability, and representative device class; record its date and owner.
Run a time-boxed spike only for serious finalists with a material unresolved native, performance, lifecycle, accessibility, or packaging risk. Define pass/fail before it: build and package, native SDK integration, cold-start and interaction budget, accessibility behavior, offline/recovery behavior, and maintainer skill. Use the real release configuration and the oldest device class relevant to that risk. If the spike consumes paid services, signing capacity, scarce devices, or shared CI quota outside the agreed task budget, obtain authorization for that resource use first. For low-risk products, a documented decision with applicable production evidence and explicit assumptions is sufficient. If the hardest capability fails or requires a permanent bespoke native module, include that module's two-platform ownership cost in the decision; if no hard capability exists, favor the stack that reduces duplicated product work.
Load cross-platform-comparison.md when weighing shared delivery against native ownership. Use this catalog to identify the native work the chosen stack still needs:
| Stack | Escape hatch | Capability to prove before committing |
|---|---|---|
| Separate native apps | Swift/Objective-C and Kotlin/Java SDKs directly | Two-platform implementation and release ownership |
| React Native / Expo | Turbo Native Modules, or Expo Modules in a development build | Hardware SDK, background lifecycle, and native dependency compatibility; Expo Go cannot load arbitrary native modules |
| Flutter | Platform channels / Pigeon, plugins, native views | Camera/media throughput, platform-view composition, and channel threading |
| KMP with native UI | Platform source sets and iOS framework integration | Swift-facing API, Kotlin/Native library support, packaging and symbolication |
| Compose Multiplatform | Platform APIs and native UI interop where shared UI lacks the required surface | Accessibility, input, platform-specific UI, extensions and lifecycle |
| Capacitor / WebView | Native plugins and a native host | Background execution, hardware APIs and extension targets; browser APIs alone do not supply these capabilities |
KMP iOS toolchain gate. Apple final binaries require a macOS host and Xcode even when business logic is shared. Read the Kotlin/Gradle/AGP/Xcode compatibility matrix for the project's Kotlin plugin and supported targets/hosts for device/simulator architectures. Choose direct Xcode integration or dependency-manager integration according to existing CocoaPods dependencies and module distribution needs; prove both a simulator build and a signed device archive.
Attestation gate. For sensitive server actions, evaluate App Attest and Play Integrity through the stack's native module/plugin. Verify results on the server and bind them to a fresh challenge or request content. Check device/API availability and release distribution before enforcing; define behavior for unsupported devices and outages. Attestation is an abuse signal, alongside authentication and authorization, and is not a universal store-submission requirement. Detailed threat modeling and secure storage belong to software-security-appsec.
aps-environment entitlement and keep its token routing aligned with that environment.iOS release-operation gates (TestFlight channels, upload path, backend-only fixes, real-device smoke proof, minimum Xcode/SDK for upload), known iOS and Android runtime traps, expert judgment calls, and the anti-pattern table live in references/platform-traps-and-judgment.md. Load it before a release cut, a push/open-path investigation, or a platform-choice recommendation.
Both are store-policy decisions that change often. Decision logic, operating rules, and primary-page links are in references/store-update-and-payment-policy.md.
Before a release recommendation, read Apple's upload/SDK and third-party SDK requirements, Google's target-API policy, and the installed framework's upgrade notes using data/sources.json. An unreachable submission gate is unverified and blocks a readiness claim. Source-list edit dates do not establish that every page was checked.
When prior decisions or pitfalls are relevant, consult learnings.consolidated.md if present; use learnings.md only for needed history or as the available fallback. Otherwise skip both.
After applying it, if you encountered a pattern worth remembering, a mistake worth preventing, or a domain fact that surprised you, append one dated bullet to learnings.md via agents-skills-feedback-loop/scripts/append_learning.py. Do not modify SKILL.md itself.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Configures Claude Code hooks and Codex hooks.json/notify. Use when adding PreToolUse guards, Stop hooks, managed hooks, format-on-save, preflight, audits, or worktree/budget hooks.
日本語の概要は準備中です。原文の説明を表示しています。
Configures and hardens Claude Code and Codex MCP servers. Use when connecting databases, APIs, SaaS, building servers, or serving a clearance-filtered knowledge base.
日本語の概要は準備中です。原文の説明を表示しています。
Owns instruction files: AGENTS.md, CLAUDE.md, personal and repo rules. Use when writing, pruning, auditing them, sharing rules across Claude and Codex, or fixing ignored rules.
日本語の概要は準備中です。原文の説明を表示しています。
Creates and audits agent skills: SKILL.md, references, scripts, runtime metadata. Use when writing, validating, or security-reviewing a skill, or fixing truncated skill listings.
日本語の概要は準備中です。原文の説明を表示しています。
Adds per-skill learnings loops for dated patterns, mistakes, and domain facts. Use when wiring skill memory, consolidation, or drift audits.
日本語の概要は準備中です。原文の説明を表示しています。
Chooses subagent, team, workflow, or debate and launches it on Claude Code or Codex. Use when delegating, running agent review boards, or installing shared agents.
日本語の概要は準備中です。原文の説明を表示しています。