Rewriting an entire native Swift application into a cross-platform Flutter codebase is a massive engineering effort. You duplicate every single existing feature into Dart, modernize the UI to give it a fresh look, and finally have a unified codebase targeting both iOS and Android. But writing the code is only half the battle. The moment of truth arrives when you attempt to deploy that new Flutter build over the existing native Swift application on the App Store. One minor configuration oversight in Xcode, and App Store Connect treats your update as an entirely new entity rather than an in-place upgrade.

To execute a seamless rollout that overwrites your legacy native build without spinning up a brand new listing, you must follow strict release requirements.

Preserving App Identity and Version Hierarchy

The App Store tracks identity through explicit identifiers and monotonic version increments. If your incoming Flutter binary breaks continuity with the native predecessor, the submission fails or fragments your user base.

Migration Parameter	Legacy Native Swift Setting	Required Flutter (iOS Target) Setting	Consequence of Mismatch
Bundle Identifier	Original App ID (e.g., com.company.app)	Exact identical App ID string	App Store flags the build as an entirely different application
Version Scheme	Baseline Version (e.g., 1.0)	Strictly greater increment (1.1 or 2.0)	Rejection due to version collisions or invalid release paths

You must ensure that the Bundle Identifier in your Flutter iOS project matches the exact string used in the previous native Swift app. Alongside the identifier, your version number must increment. If the legacy Swift app was running version 1.0, your initial Flutter replacement must be set to 1.1, 2.0, or higher.

Xcode Signing and Identity Verification

Once your Dart logic is ready and the project is configured, open the native iOS wrapper to adjust code signing and capabilities.

1. Navigate to the General tab and verify that the Bundle Identifier perfectly matches the existing production app.
2. Switch to the Signing & Capabilities tab.
3. Check the box for Automatically manage signing.
4. Confirm that the team profile aligns with the same developer credentials used for the previous Swift app releases.

This configuration allows the system to generate the proper provisioning profiles tied directly to your production identifier, preventing authorization rejections during build ingestion.

Archiving and App Distribution

The final phase takes place in the Xcode Organizer. Creating a build artifact that cleanly overwrites the native app requires meticulous checks before running the upload pipeline.

1. Trigger the Archive Process: Run an archive on the iOS target containing your Flutter engine and Dart assets.
2. Audit Build Metadata: In the Organizer window, review the archive summary. Verify the application name, inspect the Version, and double-check the Build Number. These values must reflect the new version hierarchy over the legacy Swift releases.
3. Execute Distribution: Select Distribute App to transmit the signed archive directly to App Store Connect.

Finalizing the App Store Update

After the distribution workflow completes the upload process, return to App Store Connect. You do not need to register a new application.

Instead, open your existing app dashboard, generate a standard version update, and select the newly uploaded Build Number generated by your Flutter build. Submit this build for the regular review cycle. Existing users will receive the cross-platform Dart rewrite directly as an automatic update over the old Swift binary without service interruption.