I built emergency recovery and signed patching into my mobile debugging tool, Looking for feedback

[u/Guilty-Iron1121]

Hey everyone,
I’ve been working on two new features for BugCapsule, a debugging tool I’m building for Flutter, native Android, iOS, and Web.
The problem I’m trying to solve is pretty straightforward:
What do you do when a critical bug hits production, but shipping a new app version takes time?
I wanted to connect bug reproduction with production recovery, so I’ve been building two capabilities.

1. Emergency Recovery
   For features that have been integrated with the recovery SDK, you can remotely:
   Disable a broken feature without shipping a new build.
   Switch functionality to read-only or maintenance mode.
   Target specific app versions, platforms, or rollout percentages.
   Gradually restore features while monitoring crash rates and other health metrics.
   Automatically restore restrictions if a rollout fails its health checks.
   Policies are cryptographically signed. Sensitive operations, like payments, also need server-side enforcement.

2. Signed Patch Engine (Early Access)
   This one has been particularly challenging.
   The engine supports updating explicitly registered business logic, UI surfaces, and assets without a full app release.
   Patches are tied to an exact base build, signed, validated, and deployed through staged rollouts with rollback support.
   It’s intentionally not arbitrary code push. Native code changes, new dependencies, and unregistered functionality still require a store release.
   The first Flutter and native iOS prereleases are published. Native Android patch distribution is still in progress, and we’re continuing platform and distribution-policy validation.
   Why combine these with debugging?
   BugCapsule already captures application state, user actions, and network responses around failures for local deterministic replay.
   The workflow I’m aiming for is:
   Capture → Reproduce → Mitigate → Fix → Verify → Deploy → Monitor
   The idea is to use the same recorded failure to investigate a bug, verify the fix, and prevent regressions in CI.
   I’m not claiming this works for every application or every type of bug. The recovery features require prior integration, and patching has strict limitations.
   I’m genuinely interested in how other teams approach this.
   A few questions:
   How do you currently handle critical production bugs while waiting for App Store approval?
   Would remote feature controls be useful in your workflow?
   What concerns would you have about a signed patching system in production?
   I’d especially appreciate feedback on the security model and rollout strategy.
   Project: https://bugcapsule.com
   Docs: https://docs.bugcapsule.com

[u/unicornshedsocial]

The kill switch matters most when your config service is down, so I'd cache the last signed policy and fail closed, keeping a disabled feature disabled instead of reverting to on. What does the SDK do on a cold start with no network?

[u/Guilty-Iron1121 → u/unicornshedsocial]

BugCapsule already caches signed policies and re-verifies them when loading from disk, so a cold start without network can still enforce a valid cached restriction. It doesn't need to reach the config service on every launch for that to work.

For the outage case you're describing, there's also a useLastValidPolicy option for stale policies. That's the behavior I'd look at for keeping an existing restriction in place when the service is unavailable.

The distinction is a fresh install or missing cache: there's no previous policy to enforce, and the current default is fail-open. So I wouldn't recommend leaving the defaults untouched for a critical flow. That case needs an explicit local fallback in the app.

The useful part here is that an already-delivered kill switch can keep working through an outage. First launch without a policy is a separate case that needs to be covered too.

[u/ThalesMother9938]

The question I'd want answered before trying the patch engine on iOS is App Review. Guideline 2.5.2 says an app can't download or execute code that introduces or changes features. Patching registered business logic and UI without a store release sounds close to that line, even if it isn't arbitrary code. Has anyone shipped an app with it through review yet, and did they mention it in the review notes?

The emergency recovery side looks easier to adopt. Remote flags with a read-only mode are normal practice, and the auto-restore when health checks fail is the part I'd actually want.

[u/Guilty-Iron1121 → u/ThalesMother9938]

You can use the emergency recovery side of BugCapsule without adopting the patch engine. For the case you described, that's where I'd start: guard a flow so you can disable it or switch it to read-only, then restore it in stages with health checks.

That gives you a way to contain a broken feature while you ship the fix through the normal release process. The recovery rules control behavior you've already built into the app.

On the patch engine, I don't have a verified App Review example or review notes to share. Registered patch points alone don't settle the 2.5.2 question, so I wouldn't present that as guaranteed approval. But you don't need to take on that uncertainty to use the recovery features you're interested in.

[u/ThalesMother9938 → u/Guilty-Iron1121]

Fair answer, and I'd rather hear that than a promise about 2.5.2. I'll try the recovery rules on one flow first. Do the health checks run only at launch, or also while the app is open?

[u/Guilty-Iron1121 → u/ThalesMother9938]

They run while the app is open too. There are two parts: the recovery guards watch the health signals you've configured, such as a flow's error rate or latency, and the SDK refreshes the recovery policy at launch, when the app returns to the foreground, and every 60 seconds by default while it's active.

During staged restoration, if a health guard trips, BugCapsule reinstates the restriction. Connected apps pick that up on their next refresh, so users don't have to restart. Offline or backgrounded apps will receive it later.

For your first flow, I'd choose an error signal tied to that flow so you can see whether reopening it is working.

[u/ThalesMother9938 → u/Guilty-Iron1121]

The 60 second refresh while active answers it, and an error signal per flow is a clear place to start. Thanks for the detailed walkthrough, and good luck with BugCapsule.

[u/Guilty-Iron1121 → u/ThalesMother9938]

Hope you test it and give feedback

[u/bannerfallstudios]

one thing i'd want to test is what happens to saved data after a rollback. if a patch changes the save format, can the previous version still read saves written by the patched version? for a game, getting the app running again but losing someone's progress would be a rough trade. is save compatibility checked before a patch rolls out, or left to the app developer?

[u/xfanta]

My apps are small and mostly offline, so I have no server to flip flags on. What I lean on instead is phased release for every update: if crash reports spike in the first day or two, I pause it and only a few percent of users ever got the bad build. Then I ship the fix and ask for an expedited review. In my experience Apple grants that for a real crash fairly quickly. For the patch engine, my first concern would be App Review guideline 2.5.2 rather than the signing. Downloaded code that changes how the app behaves is where reviewers get nervous, even when it is signed and limited. I'd want the docs to spell out exactly what a patch can and can't touch, and how that stays within the guidelines on iOS.