---
title: "Rebuild an existing app"
description: "Use a working product as the specification for a cleaner native Swift version."
---
Rebuilding is a product migration, not a file conversion. Preserve what users value, discard accidental complexity, and prove each native journey against the existing app.

## Create a migration inventory

-   Every screen, route, empty state, error, and permission request.
-   Authentication providers, account lifecycle, roles, and access rules.
-   Database entities, APIs, file storage, scheduled work, and notifications.
-   Purchases, subscriptions, entitlements, trials, and restoration behavior.
-   Analytics events, deep links, widgets, and other system integrations.

### 1. Choose the first complete journey

Rebuild one end-to-end outcome before copying every settings screen. A narrow working path exposes architectural differences early.

### 2. Bring reliable references

Attach screenshots, design files, data models, API documentation, and acceptance criteria. Never include production credentials or real customer data.

### 3. Connect existing services

Reuse a backend only after documenting its contracts and permissions. Keep the old app live while the native client is tested against a safe development environment.

### 4. Compare and cut over

Test old and new versions side by side, migrate or preserve user data, distribute a TestFlight beta, and release only when core behavior is equivalent or intentionally improved.

:::note
Keep the existing app and its production backend recoverable until the new App Store version has been installed and verified by real users.
:::