How to troubleshoot a release without guessing
Use evidence from the exact project, build, provider, and attempt before changing code or credentials.
Start with identity
Confirm app name, bundle/package ID, source commit or archive, version/build number, signing team/key, connected store application, and selected platform. Many release problems are identity mismatches rather than code defects.
Read the failing stage
Separate inspection, source checkout, dependency install, web build, native sync, native compilation, signing, validation, upload, provider processing, and review. Fix the stage that actually failed rather than restarting the entire release blindly.
Use provider evidence
For GitHub failures, inspect the specific Actions run. For Apple or Google failures, use the provider response and processing state. For RevenueCat or other integrations, verify project/app/product identifiers and environment before changing code.
Preserve attempts
Do not overwrite the historical record of a failed upload or build. A new attempt should be linked to the previous one so the change and result are auditable.
Retry only after a change or transient failure
If the failure is deterministic—wrong ID, expired profile, missing secret, incompatible dependency—repeating the same inputs will usually repeat the failure. Correct the cause first.
Escalate with a reproducible package
When support is needed, include the project, platform, source identity, version/build, exact failing stage, provider/job ID, error text, and what changed since the last known-good release. Do not include private keys or secrets in screenshots or tickets.