Critical operations
Respond to production incidents without a release
Three levers. One audit trail. No fake promises about delivery time — real behavior is bounded by network state and app foreground.
Three levers
Kill · Block · Force update
Per-control kill
Disable a single UI control. Users keep using the rest of the app. The next successful sync on each device applies the kill.
Docs →App-wide session block
Refuse a session at launch with an operator-authored message. Use when the whole app is unsafe to run.
Docs →Force update
Return a minimum required version from the session endpoint. The SDK gates the session until the user updates.
Docs →Timing
Online and offline, honestly
We do not promise magic delivery times. Here is what actually happens on the wire.
Device is online
- 1Operator saves the change in the dashboard.
- 2Device polls (or reconnects to the streaming channel) on its normal cadence.
- 3SDK applies the new decision on that sync and caches it.
- 4Impression / delivery event is reported back for the audit view.
Device is offline
- 1SDK keeps enforcing the last state it successfully synced.
- 2New operator changes cannot reach the device while it is offline.
- 3On the next successful sync after reconnect, the SDK adopts the current server state.
- 4Delivery is reported at that point.
Audit & rollback
Reversible where the model supports it
Rollback restores the previous state for supported changes. It cannot un-deliver a push or in-app message that already went out, and it cannot undo events the user already generated.
- Destructive actions require a reason on save.
- The audit view captures operator, timestamp, and the previous value where the model stores one.
- You can revert a supported change from the history view.
- Deletes may be recoverable while the underlying record still exists — this is not a universal, unbounded undo.
- Push and in-app messages that already left the platform cannot be recalled.
- Impression counters and analytics preserve the historical event, not the reverted state.
Screen protection
Only the OS can actually block screenshots
| Platform | Mechanism | Guarantee |
|---|---|---|
| Android | FLAG_SECURE on the window | Native only |
| iOS | Capture masking + background snapshot overlay | Native only |
| Web | CSS visual mask | Web · best-effort |
Checklist
Before you rely on CtrlApp in production
- 01Wire the SDK behind a real network with a real API key on staging.
- 02Add one kill-switch to a screen you can safely disable.
- 03Verify the offline path: enable airplane mode, force-quit, relaunch.
- 04Rehearse a rollback from the history view.
- 05Configure a webhook or on-call route for critical events.
- 06Add screen capture protection on Android and iOS if you handle sensitive data.