Reporting Issues
SootSim covers a large surface of React Native and native iOS behavior, and in the public beta some apps will hit a gap: a screen that renders wrong, a package that does not boot, a gesture that misbehaves. When that happens, send a report from inside the sim. A report gives us enough context to reproduce and fix the issue without asking you to write a long repro by hand.
Report from the CLI
When sootsim compat misses a package or the running app exposes a concrete
SootSim compatibility gap, describe the expected and actual behavior:
terminal
The command previews what it will attach and asks before sending. Use
--dry-run to stop after that preview. A non-interactive coding agent cannot
submit from the first invocation: it must show you the finding, ask whether you
want to report it, and only run with --yes after you explicitly agree. Setup
and compatibility scans never submit a report automatically.
The CLI automatically attaches the current app’s local compatibility scan, including React Native ecosystem package names, declared versions, and SootSim support classifications. It also includes the CLI/runtime versions, operating system, and architecture. It does not attach source files, environment variables, terminal output, logs, screenshots, git data, or app data.
Run the command from the app project root, or target it explicitly:
terminal
Report from inside the sim
Open the SootSim devtools (the panel alongside the device) and select the Report tab. Write a short note describing what you expected versus what you saw, then send.
You do not need to leave the sim or file anything by hand. The report goes straight to us and you get back a short report id you can reference later.
What gets captured
The Report pane attaches context as a set of toggles, each on by default and each one you can turn off before sending:
- Note: your description of the problem, in your words.
- Canvas screenshot: the current frame of the device, so we can see the visual symptom.
- Recent logs: the last 50 console/log entries from the running app.
- Bundle info: the loaded app name, the SootSim runtime and CLI versions, and your browser/OS string. This is what tells us exactly what you were running.
Console errors already surfaced in the session are included with the logs so we can line the symptom up against what threw.
What is safe to send
An in-sim report only includes what the toggles above cover, and you can review and trim each one before sending. It does not read your environment variables, config secrets, or app credentials; it sends only the note, the visible frame, recent logs, and version/bundle metadata. If a log line in your app prints something sensitive, turn the Recent logs toggle off before sending.
After you send
Each report is stored durably with its screenshot, logs, and version context keyed to its report id, so we can reproduce the exact case you hit. Keep the id: it is how we track the issue and tell you which version contains the fix.
Getting the fix
SootSim’s standalone runtime checks for a newer runtime on startup and hourly, and hot-swaps a connected sim to the latest one automatically, so a fix published to the runtime reaches a running session without a reinstall. To pull the newest runtime and CLI immediately instead of waiting for the next check:
terminal
When you follow up on a report, include its id and we will point you at the
runtime version that contains the fix and whether you need sootsim upgrade, a
restart, or just a reload.