english/.opencode/skills/mobile-development/references/mobile-mindset.md

Mobile Development Mindset & Thinking Patterns

Essential thinking patterns and decision-making frameworks for successful mobile development.

The 10 Commandments of Mobile Development

1. Performance is Foundation, Not Feature

• Reality: 70% users abandon apps >3s load time
• Mindset: Optimize from day one, not "later"
• Action: Set performance budgets before writing code

2. Every Kilobyte, Every Millisecond Matters

• Reality: Mobile = constrained environment (battery, memory, network)
• Mindset: Desktop assumptions don't apply
• Action: Profile real devices, not simulators

3. Offline-First by Default

• Reality: Network is unreliable (elevators, tunnels, airplanes, poor signal)
• Mindset: Design for offline, sync when online
• Action: Local persistence first, cloud sync second

4. User Context > Developer Environment

• Reality: Users on trains, walking, one-handed, bright sunlight
• Mindset: Test in real-world scenarios
• Action: Real device testing mandatory

5. Platform Awareness Without Platform Lock-In

• Reality: iOS and Android users expect different patterns
• Mindset: Respect conventions, but keep logic portable
• Action: Platform-specific UI, shared business logic

6. Iterate, Don't Perfect (2024-2025 Survival Strategy)

• Reality: Mobile landscape changes rapidly
• Mindset: Ship, measure, improve cycle
• Action: MVP → User feedback → Iterate

7. Security and Accessibility by Design

• Reality: Not afterthoughts, but core requirements
• Mindset: Build trust and inclusivity from start
• Action: Security audit + accessibility testing in every sprint

8. Test on Real Devices

• Reality: Simulators lie about performance, battery, network
• Mindset: Simulators for speed, devices for truth
• Action: CI/CD with real device farms

9. Architecture Scales with Complexity

• Reality: Over-engineering kills simple apps
• Mindset: Start simple, refactor when needed
• Action: MVVM for small apps, Clean Architecture when complexity demands

10. Continuous Learning is Survival

• Reality: 85% developers use AI tools (2024), frameworks evolve constantly
• Mindset: Embrace change, allocate learning time
• Action: 1+ hour weekly for new tech/patterns

Mobile-Specific Constraints & Thinking

Small Screens (Constraint → Design Parameter)

Constraint:

• 5-7 inch screens, thumb-reach zones, fat finger problem

Thinking Shift:

• Embrace minimalism: "What can we remove?"
• Priority-based hierarchy: Most important action front and center
• Progressive disclosure: Hide complexity behind layers

Practical Targets:

• 44x44px minimum touch targets (iOS)
• 48x48px minimum touch targets (Android)
• Primary actions within thumb reach (bottom 1/3)
• Maximum 3-4 items in bottom navigation

Example Decision:

❌ Bad: 8-column data table on mobile
✅ Good: Card view with 3 key metrics, "View more" for details

Limited Resources (Every KB/ms Matters)

Constraint:

• Battery drain, memory pressure, thermal throttling

Thinking Shift:

• Resource consciousness in every decision
• Measure before optimizing (don't guess)
• Graceful degradation on low-end devices

Practical Targets:

• <100MB memory for typical screens
• <5% battery drain per hour active use
• <50MB initial download, <200MB total
• 60 FPS (16.67ms per frame)

Example Decision:

❌ Bad: Load all 1000 items in list
✅ Good: Virtualized list (10 items visible + buffer)

Intermittent Connectivity (Offline-First)

Constraint:

• Network unreliable: elevators, tunnels, poor signal, airplane mode

Thinking Shift:

• Local-first data architecture
• Optimistic UI updates
• Sync conflict resolution strategy

Practical Approaches:

• Write-through cache: Write local, sync background
• Hybrid sync: Push (realtime) + Pull (periodic)
• Conflict resolution: Last-write-wins with timestamps or CRDT

Example Decision:

❌ Bad: Show spinner while posting comment
✅ Good: Show comment immediately (optimistic), sync background, handle conflicts

Platform-Specific Thinking

iOS Mental Model

Philosophy: Consistent, polished, opinionated

• Users expect iOS patterns (tab bar, navigation bar, swipe back)
• Design reviews reject non-standard UIs
• "It just works" expectation = zero tolerance for crashes

Fragmentation: LOW

• 90%+ on iOS 16+ (2024)
• Only ~50 device models to test
• Predictable hardware specs

Design Thinking:

• Follow Human Interface Guidelines religiously
• Native navigation patterns non-negotiable
• Haptic feedback for important actions
• Respect safe areas (notch, Dynamic Island)

When to Go Native iOS:

• App Store is primary revenue channel
• Need latest Apple features (WidgetKit, Live Activities)
• Target affluent user base (iOS users spend 2.5x more)

Android Mental Model

Philosophy: Flexible, customizable, democratic

• Users expect Material Design but tolerate variations
• Extreme fragmentation = defensive programming
• "Back button" = fundamental navigation expectation

Fragmentation: HIGH

• 24,000+ device models
• Android 6-14 in active use (8 years of OS versions)
• Wide range of hardware specs (512MB to 12GB RAM)

Design Thinking:

• Material Design 3 as baseline
• Test on low-end devices (1GB RAM minimum)
• Respect system navigation (gesture vs 3-button)
• Handle back button properly

When to Go Native Android:

• Global market focus (72% market share)
• Emerging markets (Android dominates)
• Enterprise/B2B (customization needs)

Performance Mindset (Every Millisecond Matters)

Critical Metrics (User Perception)

Metric	Threshold	User Perception
Launch time	<2s	Acceptable
Launch time	2-3s	Noticeable delay
Launch time	>3s	70% abandon
Screen load	<1s	Instant (cached)
Screen load	1-3s	Acceptable (network)
Screen load	>3s	Frustrating
Animation	60 FPS	Smooth
Animation	30-60 FPS	Noticeable jank
Animation	<30 FPS	Unusable

Performance Budget Example

Mobile App Performance Budget:

Launch Time
├─ Cold start: <2s (target 1.5s)
├─ Warm start: <1s
└─ Hot start: <0.5s

Screen Load
├─ Cached data: <500ms
├─ Network data: <2s
└─ Heavy computation: <3s

Memory
├─ Typical screen: <100MB
├─ Heavy screen (images): <150MB
└─ Peak usage: <200MB

Network
├─ Initial bundle: <2MB
├─ Per screen: <500KB
└─ Images: <200KB each

Battery
├─ Active use: <5% per hour
├─ Background: <1% per hour
└─ Idle: <0.1% per hour

Optimization Decision Tree

Is it slow?

1. Measure first (Xcode Instruments, Android Profiler)
2. Find bottleneck (CPU, memory, network, disk I/O)
3. Fix biggest impact (80/20 rule)
4. Measure again (verify improvement)

Common Culprits:

• Synchronous main thread operations
• Unoptimized images (too large, wrong format)
• N+1 query problem (fetch in loop)
• Memory leaks (retain cycles, listeners)
• Re-renders without memoization

Mobile Development Workflow

Iterative Development Cycle (Agile)

Sprint Structure (2 weeks):

Week 1: Build + Test
├─ Day 1-2: Design + plan
├─ Day 3-4: Implement core
└─ Day 5: Code review + tests

Week 2: Polish + Ship
├─ Day 6-7: Bug fixes + polish
├─ Day 8: QA testing
├─ Day 9: Staging deployment
└─ Day 10: Production release (staged)

Daily Workflow:

1. Pull latest code
2. Run tests locally
3. Develop feature/fix
4. Write/update tests
5. Local testing on device
6. Code review
7. CI/CD validation
8. Merge to develop

CI/CD Impact:

• 20% reduction in development time
• 50% fewer production bugs
• 3x faster deployment

Common Pitfalls & Avoidance

1. Testing Only on Simulators

Problem: Simulators don't show real performance (battery, memory, network) Solution: Real device testing mandatory before every release Impact: 40% of bugs only appear on real devices

2. Ignoring Platform Conventions

Problem: Custom navigation confuses users Solution: Follow iOS HIG and Material Design Impact: 30% lower engagement with non-standard UIs

3. No Offline Handling

Problem: Network failures = blank screens, errors Solution: Offline-first architecture, cached data Impact: 50% of users experience network issues daily

4. Poor Memory Management

Problem: Memory leaks → crashes, poor performance Solution: ARC/GC understanding, profile regularly Impact: Memory issues = #1 crash cause (35%)

5. Hardcoded Credentials

Problem: Security vulnerability, API key exposure Solution: Environment variables, secure storage Impact: 23% of apps leak sensitive data (OWASP)

6. No Accessibility

Problem: Excludes 15%+ of users (disability, situational) Solution: VoiceOver/TalkBack testing, semantic labels Impact: Accessibility = 1.3B global market

7. Premature Optimization

Problem: Wasted time optimizing non-bottlenecks Solution: Measure first, optimize biggest impact Impact: 80% of performance issues = 20% of code

8. Over-Engineering

Problem: Complex architecture for simple apps Solution: Start simple, scale when needed Impact: 3x longer development for no user benefit

9. Skipping Real Device Testing

Problem: Missed battery drain, thermal issues Solution: Device farm in CI/CD, manual testing Impact: 25% of performance issues device-specific

10. Not Respecting Battery

Problem: Background processing drains battery Solution: Batch operations, respect Doze Mode Impact: Battery drain = #1 uninstall reason

Debugging Strategies & Tools (2024-2025)

iOS Debugging (Xcode 16)

Tools:

• Instruments: Profiling (Time, Allocations, Leaks, Network)
• Memory Graph: Visual retain cycles
• View Hierarchy: UI debugging
• Network Link Conditioner: Simulate poor network
• Console: System logs, os_log

AI-Driven:

• Xcode 16 AI crash analysis
• Automatic memory leak detection
• Performance suggestions

Process:

1. Reproduce bug on device
2. Attach debugger / capture crash log
3. Symbolicate crash report
4. Fix root cause (not symptom)
5. Add test to prevent regression

Android Debugging (Android Studio Giraffe+)

Tools:

• Profiler: CPU, Memory, Network, Energy
• Layout Inspector: 3D view hierarchy
• Database Inspector: SQLite/Room debugging
• Network Inspector: API call monitoring
• Logcat: System logs with filters

AI-Driven:

• Android Vitals: Crash clustering, ANR analysis
• Firebase Crashlytics: AI-powered issue grouping
• Play Console insights: User-reported bugs

Process:

1. Reproduce on emulator/device
2. Check Logcat for stack traces
3. Use Android Profiler for performance
4. Fix and verify with instrumented tests
5. Monitor Play Console vitals post-release

Cross-Platform Debugging

React Native:

• Chrome DevTools / Safari Web Inspector
• Flipper (meta debugger: network, layout, logs)
• Reactotron (state inspection)

Flutter:

• Flutter DevTools (Inspector, Timeline, Memory, Network)
• Dart Observatory (VM debugging)
• Widget Inspector (UI debugging)

Progressive Enhancement & Graceful Degradation

Progressive Enhancement (Build Up)

Strategy: Start with baseline, enhance for capable devices

Example: Image Loading

Baseline (all devices):
├─ Show placeholder immediately
├─ Load low-res image (10KB)
└─ Display with smooth fade-in

Enhancement (modern devices):
├─ Check network (fast = high-res)
├─ Check memory (ample = cache)
└─ Progressive JPEG rendering

Benefits:

• Works on all devices
• Optimal experience on modern devices
• No user left behind

Graceful Degradation (Strip Down)

Strategy: Build for best, degrade for constraints

Example: Animation

Best (flagship devices):
├─ Complex particle effects
├─ 120 FPS animations
└─ Parallax scrolling

Degraded (budget devices):
├─ Simple fade transitions
├─ 60 FPS target
└─ Disable parallax (GPU load)

Detection:

// React Native
const isLowEndDevice =
  DeviceInfo.getTotalMemory() < 2000000000; // <2GB

if (isLowEndDevice) {
  // Disable heavy animations
  // Reduce concurrent operations
  // Lower image quality
}

Benefits:

• Optimized for all hardware tiers
• Prevents crashes on low-end devices
• Better user experience across spectrum

Native vs Cross-Platform Decision Framework

Decision Tree

Q1: Do you need 100% native performance?

• Yes → Native (Swift/Kotlin)
• No → Continue

Q2: Is team comfortable with JavaScript?

• Yes → React Native
• No → Continue

Q3: Need desktop or web versions too?

• Yes → Flutter
• No → Continue

Q4: Complex animations or custom UI?

• Yes → Flutter
• No → React Native (easier for standard UIs)

Q5: Existing codebase to share?

• React web app → React Native
• No existing code → Flutter (cleaner slate)

Hybrid Approach (Best of Both Worlds)

Strategy: Cross-platform for most features, native for critical paths

Example Architecture:

React Native / Flutter (90%)
├─ UI and business logic
├─ Standard features
└─ API integration

Native Modules (10%)
├─ Performance-critical (video processing)
├─ Platform-specific (HealthKit, Android Auto)
└─ Third-party SDKs (payment, analytics)

When to Use:

• Best: Leverage cross-platform speed + native power
• Complexity: Maintain native module knowledge
• Team: Need both cross-platform and native developers

Architecture Decision-Making

Complexity-Based Architecture Selection

Simple App (1-5 screens, basic CRUD)

• Architecture: MVVM (no Clean Architecture)
• State: Local state (useState, setState)
• Reasoning: Over-engineering adds complexity without benefit

Medium App (5-20 screens, moderate logic)

• Architecture: MVVM with clear separation
• State: Global state management (Zustand, Riverpod)
• Reasoning: Scalability without over-engineering

Complex App (20+ screens, enterprise logic)

• Architecture: Clean Architecture (domain, data, presentation)
• State: Advanced state management + dependency injection
• Reasoning: Maintainability and testability critical

Architecture Evolution

Start Simple:

v1.0: MVVM, local state, single module
└─ Focus: Ship fast, validate idea

v2.0: Add global state when needed
└─ Trigger: Props drilling becomes painful

v3.0: Add Clean Architecture when scaling
└─ Trigger: Team grows, features multiply

v4.0: Extract microservices if justified
└─ Trigger: Independent deployment needs

Key Principle: Refactor when pain > refactoring cost, not before

Resources & Continuous Learning

Weekly Learning Targets (2024-2025):

• 1 hour: New framework features
• 30 min: Performance optimization techniques
• 30 min: Security updates (CVEs, OWASP)
• 30 min: Community articles/videos

Top Resources:

• iOS: Apple WWDC videos, Swift by Sundell
• Android: Android Dev Summit, Medium Android Dev
• React Native: React Native Blog, Expo Blog
• Flutter: Flutter Engage, Medium Flutter
• Mobile DevOps: Bitrise Blog, Fastlane guides

Communities:

• Stack Overflow (mobile tags)
• Reddit (r/iOSProgramming, r/androiddev, r/reactnative, r/FlutterDev)
• Discord (React Native, Flutter official)
• Twitter: Follow framework creators and contributors

AI Tools (85% adoption in 2024):

• GitHub Copilot: Code completion, boilerplate
• ChatGPT/Claude: Architecture questions, debugging
• Tabnine: Context-aware suggestions
• Average time saved: 1+ hour weekly

Key Mindset: Continuous learning is not optional, it's survival in mobile development