Local Testing vs Direct Upload: Safe Rollback After Schema Change

Direct Upload Enables Safe Rollback; Local Testing Does Not Retain History

For schema change rollback in mobile app test configurations, direct upload to distribution services (TestFlight, Play Internal App Sharing, Firebase App Distribution) is the safer choice because it retains historic build artifacts as distinct versions.

How Each Approach Works

1. Local Testing: Serves the current binary from a developer machine via a secure tunnel. It does not retain historic build artifacts—only the current binary is available. A rollback requires manually restoring or rebuilding the previous version.
2. Direct Upload: Each uploaded binary becomes a distinct version stored by the distribution service. You can roll back to any previously uploaded build without re-uploading the entire .ipa/.apk.

Key Trade-offs

• Re-upload frequency: Direct upload requires a fresh upload only when the binary changes. Schema-only changes that don't affect the binary can be deployed without re-uploading.
• Rollback safety: Direct upload provides built-in version history. Local Testing requires manual intervention to restore prior binaries.
• Platform retention: Some services may expire old versions after a time limit. Verify your distribution platform's retention policy.

Recommended Approach

Use direct upload with versioning. Upload the binary once, then deploy schema changes independently. If a rollback is needed, simply switch to the previous version in the distribution service's version history.

Verification Steps

1. Upload two successive builds via the chosen direct upload channel.
2. Attempt to roll back to the first build using the service's version history.
3. Confirm the older binary is served without re-upload.

Important Considerations

The exact retention policy depends on the specific distribution platform; some services may expire old versions after a time limit or storage quota, so verify the platform's version retention settings.