Best strategy to migrate away from Tuist to native Xcode project setup? [closed]

We have a team of ~20 iOS developers, organized into several independent feature teams. We're all actively working on a single, modular iOS codebase that currently uses Tuist to manage the project structure, modules, and dependencies. As a team, we've decided to stop using Tuist and move to a more native Xcode-based approach. Our goal is to: Use an .xcworkspace as the main entry point Have our modules be either framework targets or Swift packages. Completely remove the need for Tuist from our toolchain and onboarding What’s the smoothest strategy to make this transition? Some key questions: How can we safely migrate from Tuist without blocking ongoing development? Is it possible to commit the last generated .xcodeproj or .xcworkspace and treat that as the new source of truth? What’s the best way to replace Tuist-defined modules, helpers, and dependency graphs with native Xcode equivalents? How should we phase out Tuist — should we keep it temporarily while incrementally migrating modules to frameworks/SPM? Are there gotchas we should be aware of when removing the Tuist/ folder or Project.swift files? Any advice, war stories, or tooling suggestions would be much appreciated. We want to ensure a smooth and coordinated migration that doesn’t disrupt the productivity of the individual teams.

May 13, 2025 - 17:30

We have a team of ~20 iOS developers, organized into several independent feature teams. We're all actively working on a single, modular iOS codebase that currently uses Tuist to manage the project structure, modules, and dependencies.

As a team, we've decided to stop using Tuist and move to a more native Xcode-based approach. Our goal is to:

Use an .xcworkspace as the main entry point Have our modules be either framework targets or Swift packages.

Completely remove the need for Tuist from our toolchain and onboarding What’s the smoothest strategy to make this transition?

Some key questions:

How can we safely migrate from Tuist without blocking ongoing development?

Is it possible to commit the last generated .xcodeproj or .xcworkspace and treat that as the new source of truth?

What’s the best way to replace Tuist-defined modules, helpers, and dependency graphs with native Xcode equivalents?

How should we phase out Tuist — should we keep it temporarily while incrementally migrating modules to frameworks/SPM?

Are there gotchas we should be aware of when removing the Tuist/ folder or Project.swift files?

Any advice, war stories, or tooling suggestions would be much appreciated. We want to ensure a smooth and coordinated migration that doesn’t disrupt the productivity of the individual teams.