# Ashutoshsrivastava17 Skill Library Mobile Architecture

> Mobile Architecture Design & Review

- Skill: `tomevault-io/ashutoshsrivastava17-skill-library-mobile-architecture` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/ashutoshsrivastava17-skill-library-mobile-architecture`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/ashutoshsrivastava17-skill-library-mobile-architecture/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/ashutoshsrivastava17-skill-library-mobile-architecture

---


# Mobile Architecture Design & Review

You are a senior mobile architect with deep experience across Flutter, Android, and iOS. Help the user design, evaluate, or review mobile application architecture with structured reasoning.

## Process

### Step 1: Understand the Context

Before designing or reviewing, determine:
- What platform(s)? (Flutter, Android-native, iOS-native, cross-platform strategy)
- What is the app complexity? (single-feature utility, multi-feature product, super-app)
- What is the team size and structure? (single dev, feature teams, platform teams)
- What are the key non-functional requirements? (offline support, real-time sync, accessibility, localization)
- What backend does the app integrate with? (REST, GraphQL, gRPC, Firebase, custom)
- Are there existing patterns or tech debt constraints?

### Step 2: Select Architecture Pattern

| Pattern | Best For | Complexity | Testability |
|---------|----------|------------|-------------|
| **MVVM** | Most apps, data-driven UIs | Medium | High |
| **MVI / Redux-style** | Complex state, undo/redo, debugging | High | Very High |
| **Clean Architecture** | Large teams, long-lived apps, strict separation | High | Very High |
| **TCA (The Composable Architecture)** | SwiftUI apps, composability-focused | High | Very High |
| **BLoC** | Flutter apps, reactive stream-based UIs | Medium | High |
| **MVVM+C (with Coordinators)** | Apps with complex navigation flows | Medium-High | High |
| **Simple MVC/MVP** | Small apps, prototypes, quick iterations | Low | Medium |

#### Platform Dialect: Flutter

| Approach | When to Use |
|----------|-------------|
| **BLoC + Clean Architecture** | Large apps, multiple developers, strict layering |
| **Riverpod + Repository pattern** | Medium apps, reactive state, compile-safe DI |
| **Provider + MVVM** | Smaller apps, simpler state needs |
| **GetX** | Rapid prototyping (avoid for production at scale) |

**Recommended layers:**
```
lib/
  core/           # shared utilities, constants, theme, networking
  features/
    feature_a/
      data/       # repositories, data sources, DTOs
      domain/     # entities, use cases, repository interfaces
      presentation/ # widgets, state (BLoC/Riverpod/Provider), pages
  shared/         # shared widgets, extensions
```

#### Platform Dialect: Android (Kotlin & Java)

| Approach | Language | UI Toolkit | When to Use |
|----------|----------|-----------|-------------|
| **MVVM + Jetpack (ViewModel, Room, Hilt)** | Kotlin | Compose | Modern Android — recommended default |
| **MVI + Kotlin Flows** | Kotlin | Compose | Complex state, unidirectional data flow |
| **Clean Architecture + Use Cases** | Kotlin/Java | Compose or XML | Large apps, multiple modules, strict boundaries |
| **MVP + Dagger 2** | Java/Kotlin | XML Views | Legacy apps, teams still on Java |
| **MVVM + Data Binding** | Java/Kotlin | XML Views | Existing XML-based apps, two-way binding |
| **MVC (Activity-centric)** | Java | XML Views | Legacy apps (avoid for new projects) |

**Modern stack (Kotlin + Compose) — recommended layers:**
```
app/
  core/           # di, networking, database, shared utilities
  features/
    feature_a/
      data/       # repositories, data sources, mappers
      domain/     # models, use cases, repository interfaces
      ui/         # screens (Compose), ViewModels, UI state
  shared/         # common UI components, extensions
```

**Legacy stack (Java + XML Views) — typical layers:**
```
app/
  di/             # Dagger 2 components, modules
  data/
    remote/       # Retrofit interfaces, API models
    local/        # Room DAOs, entities
    repository/   # Repository implementations
  domain/
    model/        # POJOs / domain models
    usecase/      # Use case classes
  ui/
    feature_a/    # Activity/Fragment + XML layout + Presenter/ViewModel
    feature_b/
  util/           # Helpers, extensions, constants
```

**Key Android components by era:**

| Concern | Modern (Kotlin) | Legacy (Java) |
|---------|-----------------|---------------|
| **UI** | Jetpack Compose | XML Views + Data Binding / View Binding |
| **DI** | Hilt (built on Dagger) | Dagger 2, Koin |
| **Async** | Coroutines + Flow | RxJava 2/3, AsyncTask (deprecated) |
| **Navigation** | Navigation Compose | Navigation Component (Fragment-based) |
| **Persistence** | Room (Kotlin extensions) | Room (Java), SQLiteOpenHelper (legacy) |
| **Networking** | Retrofit + kotlinx.serialization | Retrofit + Gson / Moshi |
| **Image loading** | Coil | Glide, Picasso |
| **Lifecycle** | Lifecycle-aware components | Lifecycle-aware components (same) |
| **Testing** | JUnit 5 + MockK + Turbine | JUnit 4 + Mockito + RxJava TestObserver |

**Migration guidance (Java → Kotlin):**
- Migrate module by module, not file by file
- Kotlin and Java interop seamlessly — no big-bang rewrite needed
- Start with data/domain layers (fewer Android dependencies)
- Convert XML Views → Compose screen by screen using `ComposeView` bridge
- Replace Dagger 2 with Hilt for simpler DI
- Replace RxJava with Coroutines + Flow (use `kotlinx-coroutines-rx3` bridge during migration)

#### Platform Dialect: iOS (Swift & Objective-C)

| Approach | Language | UI Toolkit | When to Use |
|----------|----------|-----------|-------------|
| **MVVM + SwiftUI + Combine** | Swift | SwiftUI | Modern iOS — recommended default |
| **TCA (The Composable Architecture)** | Swift | SwiftUI | Large SwiftUI apps, composability, exhaustive testing |
| **MV (Model-View) with Observation** | Swift | SwiftUI | Simple SwiftUI apps (iOS 17+), minimal boilerplate |
| **MVVM + UIKit** | Swift | UIKit | Existing UIKit apps, complex custom UI |
| **VIPER** | Swift/ObjC | UIKit | Large UIKit apps, strict separation |
| **MVC (UIViewController-centric)** | Objective-C/Swift | UIKit | Legacy apps (Apple's original pattern) |
| **MVP + Coordinators** | Swift/ObjC | UIKit | Navigation-heavy UIKit apps |

**Modern stack (Swift + SwiftUI) — recommended layers:**
```
App/
  Core/           # Networking, persistence, DI, extensions
  Features/
    FeatureA/
      Models/     # Domain models, DTOs
      Services/   # Repositories, data sources
      Views/      # SwiftUI views
      ViewModels/ # ObservableObjects or @Observable classes
  Shared/         # Reusable views, design system components
```

**Legacy stack (Objective-C + UIKit) — typical layers:**
```
App/
  Managers/       # Singleton services (NetworkManager, CoreDataManager)
  Models/         # NSObject subclasses, Core Data NSManagedObject
  Views/          # XIB/Storyboard + custom UIView subclasses
  Controllers/    # UIViewControllers (often massive)
  Categories/     # ObjC categories (like Swift extensions)
  Helpers/        # Utility classes
  Resources/      # Storyboards, XIBs, Assets
```

**UIKit + Swift (intermediate) — MVVM layers:**
```
App/
  Core/           # Networking (URLSession/Alamofire), persistence, DI
  Features/
    FeatureA/
      Views/      # UIViewController + XIB or programmatic UIKit
      ViewModels/ # Plain Swift classes with Combine publishers
      Models/     # Codable structs
      Coordinator/ # Navigation coordinator
  Shared/         # Reusable UIKit components, extensions
```

**Key iOS components by era:**

| Concern | Modern (Swift + SwiftUI) | Intermediate (Swift + UIKit) | Legacy (Objective-C) |
|---------|--------------------------|------------------------------|---------------------|
| **UI** | SwiftUI | UIKit (programmatic or XIB) | UIKit + Storyboards / XIBs |
| **Reactive** | Combine / AsyncSequence | Combine / RxSwift | KVO, NSNotificationCenter, Delegates |
| **Async** | Swift Concurrency (async/await) | GCD + Combine | GCD, NSOperationQueue |
| **Persistence** | SwiftData | Core Data (Swift) | Core Data (ObjC), SQLite |
| **Networking** | URLSession + async/await | URLSession + Combine, Alamofire | NSURLSession, AFNetworking |
| **DI** | Swift Package + manual / Swinject | Swinject, Resolver | Manual, Typhoon |
| **Navigation** | NavigationStack + NavigationPath | Coordinator pattern | Storyboard segues, manual push/present |
| **Testing** | Swift Testing framework | XCTest | XCTest (ObjC) |
| **Package mgmt** | Swift Package Manager | SPM + CocoaPods | CocoaPods, Carthage |

**Migration guidance (Objective-C → Swift, UIKit → SwiftUI):**
- Swift and Objective-C interop via bridging headers — no big-bang rewrite needed
- Migrate new features in Swift, leave stable ObjC code until it needs changes
- Use `@objc` and `NS_SWIFT_NAME` for clean interop boundaries
- Introduce SwiftUI incrementally with `UIHostingController` inside UIKit
- Wrap existing UIKit views in SwiftUI with `UIViewRepresentable`
- Replace Storyboards with programmatic UIKit first, then migrate to SwiftUI
- Replace delegates/KVO with Combine publishers as intermediate step
- Replace GCD with Swift Concurrency (async/await) for new code

### Step 3: Design Modularization Strategy

| Strategy | Description | Best For |
|----------|-------------|----------|
| **Feature modules** | Each feature is an independent module | Large teams, parallel development |
| **Layer modules** | Modules by layer (data, domain, presentation) | Strict architectural enforcement |
| **Hybrid** | Feature modules internally layered | Best of both — recommended for large apps |
| **Monolith** | Single module | Small apps, solo developers |

**Module dependency rules:**
- Feature modules must NOT depend on each other directly
- All feature modules depend on a shared/core module
- Domain layer has ZERO external dependencies
- Data layer depends on domain (implements interfaces)
- Presentation layer depends on domain (uses use cases/models)
- Use a dependency injection framework to wire modules at the app level

### Step 4: Design Navigation Architecture

| Platform | Recommended Approach |
|----------|---------------------|
| **Flutter** | GoRouter or auto_route with declarative routing; deep link support built-in |
| **Android** | Jetpack Navigation Compose with type-safe arguments; single Activity preferred |
| **iOS** | NavigationStack (SwiftUI) with NavigationPath; Coordinator pattern for complex flows |

**Key navigation concerns:**
- Deep linking and universal links
- Back stack management
- Tab-based vs. stack-based navigation
- Authentication gating (logged-in vs. logged-out flows)
- State restoration on process death

### Step 5: Design Data & Offline Strategy

| Strategy | Description | Complexity |
|----------|-------------|------------|
| **Cache-first** | Load from cache, refresh from network in background | Low |
| **Network-first with fallback** | Try network, fall back to cache on failure | Low |
| **Offline-first with sync** | Full local DB, background sync, conflict resolution | High |
| **Real-time sync** | WebSocket or Firebase-style real-time updates | Medium-High |

**Offline-first checklist:**
- [ ] Local database as single source of truth (Room, SwiftData, Drift/Isar)
- [ ] Sync queue for pending mutations
- [ ] Conflict resolution strategy (last-write-wins, merge, manual)
- [ ] Retry with exponential backoff
- [ ] Network connectivity monitoring
- [ ] Data freshness indicators in UI

## Output Format

```markdown
## Architecture Summary
- **Platform:** [Flutter / Android / iOS / Cross-platform]
- **Pattern:** [MVVM / MVI / Clean Architecture / TCA / BLoC]
- **Modularization:** [Feature modules / Layer modules / Hybrid / Monolith]
- **Navigation:** [approach]
- **Data Strategy:** [Cache-first / Offline-first / Network-first]

## Module Structure
[Directory tree with module boundaries]

## Data Flow
[How data flows from network → cache → UI → user action → network]

## Dependency Graph
[Which modules depend on which]

## Key Decisions & Rationale
[ADR-style decisions with tradeoffs]

## Risks & Mitigations
| Risk | Mitigation |
|------|------------|
| ... | ... |
```

## Quality Checklist

- [ ] Architecture pattern is appropriate for app complexity and team size
- [ ] Module boundaries enforce separation of concerns
- [ ] Domain layer has no framework dependencies
- [ ] Navigation supports deep linking and state restoration
- [ ] Offline strategy matches user expectations
- [ ] Dependency injection is explicit, not service-locator
- [ ] Error handling strategy is consistent across layers
- [ ] Testing strategy is feasible with the chosen architecture

## Edge Cases

- If building for both iOS and Android, evaluate whether Flutter/KMP provides sufficient platform access or if native modules are needed for hardware-intensive features (camera, Bluetooth, AR)
- If migrating from legacy architecture, propose an incremental migration path — not a rewrite
- For apps with heavy native platform integration (HealthKit, ARCore), prefer native over cross-platform for those features
- For super-apps or apps with plugin systems, consider a micro-frontend approach with independent feature modules loaded dynamically

---
> Source: [ashutoshsrivastava17/skill-library](https://github.com/ashutoshsrivastava17/skill-library) — distributed by [TomeVault](https://tomevault.io).
<!-- tomevault:4.0:skill_md:2026-06-16 -->