Introduction

Ripstop decides whether an install of your app is allowed to run, and tells it so before it gets a chance to break. Force update, soft update, maintenance mode and remote config: one signed payload, served from the edge.

The problem it solves

Six months after you ship, a backend change breaks every install older than 3.3.0. Those users are not on your release schedule and cannot be reached by a deploy. Without a way to stop them, your options are to keep the old API alive forever or to let a slice of your users hit errors until they happen to update.

With Ripstop you open the panel, set the oldest version you still support, and within seconds every stale install shows a wall pointing at the store. That moment is the whole product; everything else here exists to make it trustworthy.

How it works

• You publish rules in the dashboard. Publishing serializes them once, signs those exact bytes with Ed25519, and pushes the result to the edge.
• Your app asks cfg.ripstop.dev for its config on launch. The response is a few hundred bytes from a cache near the user.
• The SDK verifies the signature before parsing, then evaluates the rules locally and returns a decision. No round trip per screen, no server in your hot path.

The four decisions

Every check resolves to exactly one of these, in this order; first match wins. The order is part of the protocol, not an implementation detail: an app that is down on purpose must not nag its users to update into the outage.

What integration looks like

final ripstop = await Ripstop.init(apiKey: 'rs_pub_your_key');

runApp(RipstopShell(gate: ripstop, child: MyApp()));

Where to go next

Quickstart gets you to a first decision. If you are evaluating rather than building, read what happens when it breaks first. It is the page that should decide whether you trust this in production.