Rebuild an existing app

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.