⬡ Dev Tools/2026-03-28Advanced

Rork App Architecture Patterns Guide— Building Maintainable Apps with MVVM, Clean Architecture, and Dependency Injection

A comprehensive guide to architecture patterns for Rork mobile apps. Learn how to implement MVVM, Clean Architecture, and dependency injection in React Native / Expo to build scalable and maintainable applications.

Rork⁵⁴⁷ architecture patterns MVVM Clean Architecture dependency injection React Native²³⁴ app development³⁹

✦ Premium Article

Context and Background

With Rork, you can rapidly prototype mobile apps using AI. But as your app grows — more screens, more features, more complexity — you'll inevitably hit the wall of "I can't find anything in this codebase" and "changing one thing breaks something else."

This guide addresses these challenges with three architectural pillars: MVVM (Model-View-ViewModel) for separating UI from logic, Clean Architecture for layered design, and dependency injection for testability. Integrating these patterns into your Rork workflow will help you build apps that remain maintainable in the long run.

Why Architecture Patterns Matter

Technical Debt You Don't See in Small Apps

Code generated by Rork often mixes business logic, API calls, and state management within a single component. For a small app with five screens, this works fine. But once you pass twenty screens, problems start surfacing:

Components exceeding 500 lines, making it hard to locate what needs fixing
API specification changes requiring simultaneous edits across multiple screens
Difficulty writing tests because components depend directly on APIs

Three Problems Architecture Patterns Solve

Separation of concerns: Clearly dividing UI display, business logic, and data fetching responsibilities minimizes the blast radius of changes
Reusability: Extracting logic from components enables sharing across different screens
Testability: Making dependencies injectable enables unit testing with mocks

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦Learn how to implement the MVVM pattern using custom hooks in a React Native / Expo environment

✦Apply Clean Architecture's three-layer design (Domain, Data, Presentation) to your Rork apps

✦Practice building testable, loosely coupled app structures with dependency injection patterns

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

The MVVM Pattern — Separation of Concerns with Custom Hooks

MVVM Structure Basics

MVVM (Model-View-ViewModel) clearly separates the UI layer from business logic. In the React Native / Expo context, it maps like this:

Model: Data type definitions and persistence logic
View: React components (responsible only for display)
ViewModel: Custom hooks (responsible for business logic and state management)

Implementation Example: Task Management Screen

Start with the Model (type definitions):

// models/Task.ts
export interface Task {
  id: string;
  title: string;
  completed: boolean;
  createdAt: Date;
  priority: "low" | "medium" | "high";
}
 
export interface TaskFilter {
  status: "all" | "active" | "completed";
  priority?: Task["priority"];
}

Next, implement the ViewModel (custom hook):

// viewmodels/useTaskListViewModel.ts
import { useState, useMemo, useCallback } from "react";
import { Task, TaskFilter } from "../models/Task";
 
export function useTaskListViewModel(initialTasks: Task[]) {
  const [tasks, setTasks] = useState<Task[]>(initialTasks);
  const [filter, setFilter] = useState<TaskFilter>({ status: "all" });
 
  // Memoized filtered task list
  const filteredTasks = useMemo(() => {
    return tasks.filter((task) => {
      if (filter.status === "active" && task.completed) return false;
      if (filter.status === "completed" && !task.completed) return false;
      if (filter.priority && task.priority !== filter.priority) return false;
      return true;
    });
  }, [tasks, filter]);
 
  // Toggle task completion
  const toggleTask = useCallback((id: string) => {
    setTasks((prev) =>
      prev.map((t) =>
        t.id === id ? { ...t, completed: !t.completed } : t
      )
    );
  }, []);
 
  // Add a new task
  const addTask = useCallback(
    (title: string, priority: Task["priority"] = "medium") => {
      const newTask: Task = {
        id: Date.now().toString(),
        title,
        completed: false,
        createdAt: new Date(),
        priority,
      };
      setTasks((prev) => [newTask, ...prev]);
    },
    []
  );
 
  // Statistics
  const stats = useMemo(
    () => ({
      total: tasks.length,
      active: tasks.filter((t) => !t.completed).length,
      completed: tasks.filter((t) => t.completed).length,
    }),
    [tasks]
  );
 
  return {
    filteredTasks,
    filter,
    setFilter,
    toggleTask,
    addTask,
    stats,
  };
}

Finally, create the View (component). It uses only the values and functions returned by the ViewModel — no business logic whatsoever:

// screens/TaskListScreen.tsx
import React from "react";
import { View, Text, FlatList, TouchableOpacity } from "react-native";
import { useTaskListViewModel } from "../viewmodels/useTaskListViewModel";
 
export function TaskListScreen({ initialTasks }) {
  const { filteredTasks, toggleTask, stats } =
    useTaskListViewModel(initialTasks);
 
  return (
    <View style={{ flex: 1, padding: 16 }}>
      <Text style={{ fontSize: 18, fontWeight: "bold" }}>
        Tasks: {stats.active} / {stats.total}
      </Text>
      <FlatList
        data={filteredTasks}
        keyExtractor={(item) => item.id}
        renderItem={({ item }) => (
          <TouchableOpacity onPress={() => toggleTask(item.id)}>
            <Text
              style={{
                textDecorationLine: item.completed
                  ? "line-through"
                  : "none",
                padding: 12,
              }}
            >
              {item.title}
            </Text>
          </TouchableOpacity>
        )}
      />
    </View>
  );
}

With this structure, UI changes stay in the View and logic changes stay in the ViewModel, making each independently testable.

Clean Architecture — Structuring Your App in Three Layers

Layer Composition

Clean Architecture divides your application into three layers:

Domain layer: Business rules, entities, use cases (no external dependencies)
Data layer: Repository implementations, API clients, local storage
Presentation layer: UI components, ViewModels, navigation

The critical rule is that dependencies flow from the outside in. The Domain layer must never depend on the Data or Presentation layers.

Directory Structure Design

src/
├── domain/
│   ├── entities/          # Entities (type definitions)
│   │   └── Task.ts
│   ├── repositories/      # Repository interfaces
│   │   └── ITaskRepository.ts
│   └── usecases/          # Use cases
│       ├── GetTasksUseCase.ts
│       └── CreateTaskUseCase.ts
├── data/
│   ├── repositories/      # Repository implementations
│   │   └── TaskRepository.ts
│   ├── api/               # API clients
│   │   └── taskApi.ts
│   └── local/             # Local storage
│       └── taskStorage.ts
└── presentation/
    ├── screens/            # Screen components
    ├── components/         # Shared UI components
    └── viewmodels/         # ViewModels (custom hooks)

Implementing Use Cases

A use case describes a single unit of application behavior, with each use case corresponding to one business operation.

// domain/usecases/GetTasksUseCase.ts
import { Task, TaskFilter } from "../entities/Task";
import { ITaskRepository } from "../repositories/ITaskRepository";
 
export class GetTasksUseCase {
  constructor(private taskRepository: ITaskRepository) {}
 
  async execute(filter: TaskFilter): Promise<Task[]> {
    const tasks = await this.taskRepository.getAll();
 
    return tasks.filter((task) => {
      if (filter.status === "active" && task.completed) return false;
      if (filter.status === "completed" && !task.completed) return false;
      return true;
    });
  }
}

// domain/repositories/ITaskRepository.ts
import { Task } from "../entities/Task";
 
export interface ITaskRepository {
  getAll(): Promise<Task[]>;
  getById(id: string): Promise<Task | null>;
  create(task: Omit<Task, "id" | "createdAt">): Promise<Task>;
  update(id: string, data: Partial<Task>): Promise<Task>;
  delete(id: string): Promise<void>;
}

Repository Implementation (Data Layer)

// data/repositories/TaskRepository.ts
import { Task } from "../../domain/entities/Task";
import { ITaskRepository } from "../../domain/repositories/ITaskRepository";
import { taskApi } from "../api/taskApi";
 
export class TaskRepository implements ITaskRepository {
  async getAll(): Promise<Task[]> {
    const response = await taskApi.fetchTasks();
    return response.map(this.mapToEntity);
  }
 
  async getById(id: string): Promise<Task | null> {
    const response = await taskApi.fetchTask(id);
    return response ? this.mapToEntity(response) : null;
  }
 
  async create(
    data: Omit<Task, "id" | "createdAt">
  ): Promise<Task> {
    const response = await taskApi.createTask(data);
    return this.mapToEntity(response);
  }
 
  async update(id: string, data: Partial<Task>): Promise<Task> {
    const response = await taskApi.updateTask(id, data);
    return this.mapToEntity(response);
  }
 
  async delete(id: string): Promise<void> {
    await taskApi.deleteTask(id);
  }
 
  // Convert API response to domain entity
  private mapToEntity(raw: any): Task {
    return {
      id: raw.id,
      title: raw.title,
      completed: raw.completed,
      createdAt: new Date(raw.created_at),
      priority: raw.priority,
    };
  }
}

Dependency Injection — Enabling Testable Code

Dependency Injection with React Context

Use React's Context API to make repository and use case implementations injectable:

// di/ServiceContainer.ts
import React, { createContext, useContext } from "react";
import { ITaskRepository } from "../domain/repositories/ITaskRepository";
import { GetTasksUseCase } from "../domain/usecases/GetTasksUseCase";
import { CreateTaskUseCase } from "../domain/usecases/CreateTaskUseCase";
 
export interface ServiceContainer {
  taskRepository: ITaskRepository;
  getTasksUseCase: GetTasksUseCase;
  createTaskUseCase: CreateTaskUseCase;
}
 
const ServiceContext = createContext<ServiceContainer | null>(null);
 
export function ServiceProvider({
  container,
  children,
}: {
  container: ServiceContainer;
  children: React.ReactNode;
}) {
  return (
    <ServiceContext.Provider value={container}>
      {children}
    </ServiceContext.Provider>
  );
}
 
export function useService(): ServiceContainer {
  const context = useContext(ServiceContext);
  if (!context) {
    throw new Error(
      "useService must be used within a ServiceProvider"
    );
  }
  return context;
}

Injecting Mocks for Testing

Thanks to dependency injection, you can inject mock repositories during testing:

// __tests__/GetTasksUseCase.test.ts
import { GetTasksUseCase } from "../domain/usecases/GetTasksUseCase";
import { ITaskRepository } from "../domain/repositories/ITaskRepository";
 
// Mock repository
const mockRepository: ITaskRepository = {
  getAll: async () => [
    {
      id: "1",
      title: "Test Task",
      completed: false,
      createdAt: new Date(),
      priority: "medium",
    },
    {
      id: "2",
      title: "Completed Task",
      completed: true,
      createdAt: new Date(),
      priority: "high",
    },
  ],
  getById: async () => null,
  create: async (data) => ({
    ...data,
    id: "new",
    createdAt: new Date(),
  }),
  update: async (id, data) => ({} as any),
  delete: async () => {},
};
 
describe("GetTasksUseCase", () => {
  it("should filter active tasks", async () => {
    const useCase = new GetTasksUseCase(mockRepository);
    const result = await useCase.execute({ status: "active" });
    // Verify that the completed task is excluded
    expect(result).toHaveLength(1);
    expect(result[0].title).toBe("Test Task");
  });
});

Practical Workflow with Rork

Communicating Architecture Patterns to Rork

When generating apps with Rork, include your design principles in the prompt to get pattern-aligned code from the start:

Create a task management app following these architecture patterns:

1. MVVM Pattern:
   - Business logic goes in custom hooks (viewmodels/)
   - Components are responsible only for display

2. Directory structure:
   - src/domain/entities/ — type definitions
   - src/domain/usecases/ — business logic
   - src/data/repositories/ — API communication
   - src/presentation/screens/ — screens
   - src/presentation/viewmodels/ — custom hooks

3. Dependency injection:
   - Use repositories through interfaces
   - Inject implementations via React Context

Refactoring Existing Code

Here's a step-by-step approach to gradually refactoring Rork-generated code:

Extract Models first: Move type definitions from components to domain/entities/
Create ViewModels: Extract useState and related logic into custom hooks
Introduce Repositories: Centralize API calls in data/repositories/
Add Tests: Write unit tests for use cases and ViewModels

You don't need to change everything at once. Start with one screen, get comfortable with the patterns, and then gradually expand.

A Note from an Indie Developer

Key Takeaways

Architecture patterns are often seen as something only large-scale apps need, but adopting them early brings clearer code organization and significantly reduces the time spent fixing bugs and adding features.

Separate UI from logic with MVVM, clarify layer responsibilities with Clean Architecture, and ensure testability with dependency injection — these three pillars are the foundation for elevating Rork-generated apps to production quality.

Start by separating the ViewModel (custom hook) in just one screen. Combine it with advanced state management patterns and custom hook reuse techniques, and add test automation to complete a robust app architecture.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.