How it works

The rules

• A block slides horizontally and you drop it with a tap, a click, the space bar or the Drop button. The axis alternates every level: x, then z, then x again.
• Whatever hangs past the block below is sliced off and falls. What is left becomes the new top, and the next block inherits its size.
• Land within 0.03125 of a block-width of the centre and it is a perfect: the block is snapped into place and you lose nothing.
• 8 perfect drops in a row and the block starts growing back by 0.0625 of a width per perfect, up to the width you started with.
• Miss the block below entirely and the run ends.

What is faithful, and what is not

Ketchapp published no specification for Stack - no design document, no post-mortem, no rules page, and no Wikipedia article. So this app is honest about a thin sourcing base: 4 documented facts, every one of them store metadata and none of them mechanical; 12 measured off the publisher's own App Store screenshots; 5 derived, 4 calibrated and 8 reconstructed - which is to say invented, with a reason. 12 of the documented-or-measured entries are marked qualified, because the screenshots on the store listing today belong to the 2026 build, not to the February 2016 one.

The tolerance, the combo threshold, the growth, the speed and the slide range are all reconstructions. Nothing here should be read as "this is how Ketchapp did it".

Is Stack winnable?

This one is answerable exactly, because Stack has no physics: the block width is a random walk on a lattice, so the whole game is a Markov chain that can be solved rather than simulated. Three results, each checked two independent ways:

• Every miss costs more than the perfect tolerance. A drop that is not perfect is by definition further than 0.03125 off centre, so no run can absorb more than 32 imperfect drops on one axis - however skilled the player.
• There is an accuracy at which you cannot die. The offset is speed times timing error, and the speed stops rising at 3.2. A player whose timing jitter never exceeds 9.77 ms can never produce an offset outside the tolerance, so never loses a millimetre. That is a hard threshold, not a limit. No human taps that precisely; a script does.
• The cap is what decides the rest. Remove the ceiling on width restored by a perfect run and the width's drift changes sign at a critical aiming error 0.03958 - 1.267 times the tolerance, which is a player who is perfect 79.0% of the time. Above that accuracy the tower can grow for ever; below it, it cannot. With the cap in place - which is what this app ships - that transition becomes a slow escape instead of a wall.

So "each imperfect drop narrows the block, therefore death is certain" is the right conclusion for the wrong reason. Narrowing alone would not settle it, because perfects give width back. What settles it is the floor on the cost of a miss and the ceiling on the width - and if the speed ramp is capped, the conclusion is false outright for a player accurate enough.

You can check the middle claim yourself: turn on the experiment below and the cap comes off.

Experiment: let a perfect run grow the block past its starting width

What ends a typical run

Measured over thousands of simulated runs at a human timing jitter of 50 ms: the fatal drop almost never comes out of nowhere. 100% of deaths happen with the block already under a quarter of its starting width, at a mean width of 0.039 - about one and a quarter perfect tolerances. The run ends by attrition, not by a blow-out.

The elasticities say the same thing. Doubling the timing jitter costs -0.94 in log score; the starting speed and the per-level ramp together come to the same -0.94, because only the product of speed and timing error matters. The speed ceiling is inert - an ordinary run never reaches it. So is the width restoration: at 50 ms of jitter it fires on 0.11% of drops and moves the mean score by less than one block.

The constants this build runs on

The provenance register

About

Stack was published by Ketchapp (Ketchapp SARL, Paris) and first released on the App Store on 17 February 2016. Ketchapp was acquired by Ubisoft on 27 September 2016.

This page is an independent reimplementation, written from scratch. It is not affiliated with, authorised by or endorsed by Ketchapp or Ubisoft, and it contains no code, art or assets from the original.

What differs from the original

• Every rule constant is reconstructed - the original's tolerance, speed ramp, combo threshold and restoration amount are not published anywhere.
• No accounts, no coins, no seasons, no offline earnings, no advertising, no analytics and no network calls of any kind. Your best score lives in this browser only.
• The camera, the projection, the block proportions and the palette's rate of change are measured off the publisher's own screenshots; everything else about the look is our own.
• It adds an experiment the original does not have: a switch that removes the ceiling on width restored by a perfect run.

Renderer: hand-written WebGL2, no third-party libraries. Engine: a pure, deterministic module with 503 assertions against it, including an exact Markov solve of the game's own width distribution written independently in Python.

Sources and full licence text ship with the page: CREDITS.txt, LICENSE.txt, llms.txt.