Mobile Design
Choose React Native, Flutter, or native stacks and related state/storage patterns before coding a mobile app.
Overview
Mobile Decision Trees is an agent skill most often used in Build (also Validate scope) that guides framework, state, and storage choices for iOS and Android apps.
Install
npx skills add https://github.com/davila7/claude-code-templates --skill mobile-designWhat is this skill?
- Master framework tree: Expo OTA, Flutter custom UI, native-only, or React Native for TS teams
- Thinking guides for state management and storage—not copy-paste boilerplate
- Context-based branches for heavy native features (ARKit, HealthKit, sensors)
- Kotlin Multiplatform called out when sharing logic across native shells
Adoption & trust: 1.3k installs on skills.sh; 27.8k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need a mobile stack but agents keep recommending one framework without weighing OTA, native APIs, or your team's web background.
Who is it for?
Solo builders or small teams starting or refactoring a mobile app who want agent answers tied to real tradeoffs.
Skip if: Teams that already locked a stack and only need pixel implementation snippets with no architecture debate.
When should I use this skill?
Starting mobile app work, comparing cross-platform vs native, or when the agent must justify framework choice with constraints.
What do I get? / Deliverables
You get explicit decision paths (Expo vs Flutter vs native vs RN) so the next implementation steps align with constraints instead of generic templates.
- Documented framework recommendation with rationale
- Aligned state/storage direction for the chosen stack
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because decision trees assume you are committing to a mobile product and need stack and architecture choices. Frontend subphase fits UI framework, navigation, and cross-platform rendering decisions rather than backend or ship gates.
Where it fits
Compare Expo OTA vs store releases before building a weekend MVP.
Pick Flutter when branded visual parity matters more than web-team familiarity.
Choose SwiftUI-only when ARKit or HealthKit is the core product hook.
How it compares
Use for structured mobile architecture reasoning, not as a UI component library or Expo config generator.
Common Questions / FAQ
Who is mobile-design for?
Indie builders and agent users planning iOS/Android apps who need framework and state/storage decisions before writing features.
When should I use mobile-design?
During validate when choosing prototype stack, during build before scaffolding RN/Flutter/native, and when revisiting storage or state after scope changes.
Is mobile-design safe to install?
It is documentation-style guidance without bundled executables; review the Security Audits panel on this Prism page before trusting the upstream repo.
SKILL.md
READMESKILL.md - Mobile Design
# Mobile Decision Trees > Framework selection, state management, storage strategy, and context-based decisions. > **These are THINKING guides, not copy-paste answers.** --- ## 1. Framework Selection ### Master Decision Tree ``` WHAT ARE YOU BUILDING? │ ├── Need OTA updates without app store review? │ │ │ ├── Yes → React Native + Expo │ │ ├── Expo Go for development │ │ ├── EAS Update for production OTA │ │ └── Best for: rapid iteration, web teams │ │ │ └── No → Continue ▼ │ ├── Need pixel-perfect custom UI across platforms? │ │ │ ├── Yes → Flutter │ │ ├── Custom rendering engine │ │ ├── Single UI for iOS + Android │ │ └── Best for: branded, visual apps │ │ │ └── No → Continue ▼ │ ├── Heavy native features (ARKit, HealthKit, specific sensors)? │ │ │ ├── iOS only → SwiftUI / UIKit │ │ └── Maximum native capability │ │ │ ├── Android only → Kotlin + Jetpack Compose │ │ └── Maximum native capability │ │ │ └── Both → Consider native with shared logic │ └── Kotlin Multiplatform for shared │ ├── Existing web team + TypeScript codebase? │ │ │ └── Yes → React Native │ ├── Familiar paradigm for React devs │ ├── Share code with web (limited) │ └── Large ecosystem │ └── Enterprise with existing Flutter team? │ └── Yes → Flutter └── Leverage existing expertise ``` ### Framework Comparison | Factor | React Native | Flutter | Native (Swift/Kotlin) | |--------|-------------|---------|----------------------| | **OTA Updates** | ✅ Expo | ❌ No | ❌ No | | **Learning Curve** | Low (React devs) | Medium | Higher | | **Performance** | Good | Excellent | Best | | **UI Consistency** | Platform-native | Identical | Platform-native | | **Bundle Size** | Medium | Larger | Smallest | | **Native Access** | Via bridges | Via channels | Direct | | **Hot Reload** | ✅ | ✅ | ✅ (Xcode 15+) | ### When to Choose Native ``` CHOOSE NATIVE WHEN: ├── Maximum performance required (games, 3D) ├── Deep OS integration needed ├── Platform-specific features are core ├── Team has native expertise ├── App store presence is primary └── Long-term maintenance priority AVOID NATIVE WHEN: ├── Limited budget/time ├── Need rapid iteration ├── Identical UI on both platforms ├── Team is web-focused └── Cross-platform is priority ``` --- ## 2. State Management Selection ### React Native State Decision ``` WHAT'S YOUR STATE COMPLEXITY? │ ├── Simple app, few screens, minimal shared state │ │ │ └── Zustand (or just useState/Context) │ ├── Minimal boilerplate │ ├── Easy to understand │ └── Scales OK to medium │ ├── Primarily server data (API-driven) │ │ │ └── TanStack Query (React Query) + Zustand │ ├── Query for server state │ ├── Zustand for UI state │ └── Excellent caching, refetching │ ├── Complex app with many features │ │ │ └── Redux Toolkit + RTK Query │ ├── Predicable, debuggable │ ├── RTK Query for API │ └── Good for large teams │ └── Atomic, granular state needs │ └── Jotai ├── Atom-based (like Recoil) ├── Minimizes re-renders └── Good for derived state ``` ### Flutter State Decision ``` WHAT'S YOUR STATE COMPLEXITY? │ ├── Simple app, learning Flutter │ │ │ └── Provider (or setState) │