Mobile: There is no over-the-air update, staged rollout or crash reporting, so a bad mobile release is unrecoverable

[Emmy123222]

Goal this serves — Shipping fixes to donors' phones without waiting on store review

Why this matters

The mobile app handles the donation flow, including transaction signing. If a release contains a defect on that path — and this repository has already shipped one that made the donate screen unusable — there is currently no way to respond quickly. A fix waits on store review, and in the meantime every user has a broken app with no way to roll back.

There is also no crash reporting, so a defect that does not produce a support message is simply invisible.

Evidence

mobile/eas.json now defines development, preview and production build profiles, which is the prerequisite for this work and is in place.

What does not exist: no expo-updates configuration, so no over-the-air delivery; no runtimeVersion policy, so no way to express which native binary an update is compatible with; no staged rollout, so a release is all-or-nothing; and no crash or error reporting integration anywhere in the mobile tree.

The consequence is concrete: the donate screen defects fixed recently would have reached every user and stayed there until a new store submission was reviewed.

Why this is hard

Runtime version compatibility is the trap. An over-the-air bundle that assumes native modules not present in the installed binary crashes on launch, and a crash on launch cannot be fixed over the air — the recovery channel is exactly what breaks. The policy must make that impossible by construction.

Rollback needs to be instant and tested. A rollback path first exercised during an incident is not a rollback path.

Staged rollout needs a signal. Releasing to a small percentage only helps if something detects that the cohort is failing, which requires crash reporting and a defined abort threshold.

Reports must not leak keys. The app handles secret keys and signed envelopes; a crash reporter that captures state indiscriminately is a serious hazard, so scrubbing has to be structural.

Store policy applies. Over-the-air updates are permitted within limits that the rollout process must respect.

Suggested approach

Adopt over-the-air updates with a runtime version policy that makes an incompatible bundle impossible to deliver rather than merely unlikely.

Add crash and error reporting with structural scrubbing of key material, verified by test.

Define staged rollout with an explicit abort threshold driven by the crash signal, and rehearse rollback before relying on it.

Acceptance criteria

• Over-the-air updates are configured with a runtime version policy that prevents delivering a bundle incompatible with the installed binary.
• Rollback to a previous bundle is possible and has been rehearsed, with the procedure documented.
• Releases roll out in stages with a defined abort threshold, not all at once.
• Crash and error reporting is integrated, with symbolication working for release builds.
• Reports are structurally scrubbed of secret keys and signed envelopes, proven by a test.
• The crash signal drives the rollout abort decision rather than being informational.
• Store policy constraints on over-the-air updates are documented and respected.
• A release runbook covers shipping, staging, aborting and rolling back.

Scope

Roughly 5,000–7,000 lines, including tests.

Relevant files

• mobile/eas.json
• mobile/app.json
• mobile/app/_layout.tsx
• .github/workflows/mobile.yml

[BigFundz]

Hello maintainer, I'd love to work on this issue, I’ll build the mobile release flow around safe OTA delivery, staged rollout, and a tested recovery path. I’ll first configure expo-updates and establish an explicit runtimeVersion policy so an update can only be delivered to a compatible native binary, preventing incompatible bundles from reaching devices.

I’ll then implement staged releases with a defined rollout and abort threshold based on crash/error signals. Crash reporting will be integrated with release symbolication, while applying structural scrubbing before data leaves the app so private keys, signed envelopes, transaction data, and other sensitive material cannot appear in reports. I’ll add tests that attempt to exercise these sensitive paths and verify the resulting reports are clean.

For recovery, I’ll configure and document an immediate rollback procedure and rehearse it before relying on it operationally. I’ll also validate the failure path where a rollout exceeds the defined crash threshold and confirm that the release is automatically or operationally stopped rather than continuing to the remaining users.

Finally, I’ll update the mobile CI/release workflow and run the complete production-like release journey: build, publish, staged rollout, crash-signal evaluation, abort, and rollback. I’ll document the relevant store-policy constraints and provide reproducible commands, release identifiers, test results, and evidence in the PR.

[grantfox-oss]

🦊 GrantFox — @BigFundz has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #508)
2. Your PR will be reviewed by the Stellar-Search maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@BigFundz's PR #548 was approved and merged by @Manuelshub.

🏆 @BigFundz: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (258 total points). Track your full progress on GrantFox.

👏 Great work, @BigFundz! Keep contributing to Stellar-Search.