Why Relay Local starts with the real device
Desktop development environments hide behaviour that only appears on a physical phone. Relay keeps the workflow small.
The desktop hides things
A responsive preview in a desktop browser is a useful approximation, and it is only ever an approximation. Touch behaviour, on-device fonts, viewport chrome, real network conditions, memory pressure and the browser's own quirks all live on the phone, not in a resized window.
Most of the time the approximation holds. The problems that matter are the ones that only appear on the physical device, usually late, usually when the fix is expensive.
Keep the workflow small
Relay Local exists so that testing on a real Android device costs almost nothing in effort. Run the app, point Relay at the port, scan the pairing code, and the local site opens on the actual phone over your local network.
There is no deployment step, no tunnel to configure, no SDK to install and no change to the project. Relay works with whatever your dev server is already serving.
npx --package @paddy-systems/relay-cli relay 3000A clear division of labour
The most useful decision in Relay's design was refusing to make the phone into a workstation. Small screens are bad places to read stack traces.
Phone: render, reproduce and capture. Computer: inspect, control and debug.
What that rules out
Drawing the line this way means Relay Local deliberately does not try to be everything a browser's developer tools already are.
- It is not a full Chrome DevTools replacement.
- It is not a DOM inspector.
- It is not a breakpoint debugger.