Reporting Issues

Peach covers a large surface of React Native behavior across iOS and Android, 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. Its screenshot, logs, and version context help us investigate; include reproduction steps in your note.

#Ask for help

When the docs do not answer a question, ask from the CLI:

peach support ask "how do I open a deep link in the simulator?"

The command waits up to 15 minutes and prints the answer. --no-wait returns at once; the answer then shows in peach support status. An ask sends the question, the CLI and runtime versions, and the dependency compatibility scan. It never sends source files, environment variables, logs, or screenshots. Asks need a sign-in (peach login), because the answer comes back to your account.

An account’s first 5 asks are answered right away. Later asks are kept and queued until we approve the account, then answered in order; peach support status shows them as waitlisted meanwhile. Reports and status are never held.

Want onboarding support? Add funds:

peach support fund

The command opens the payment page in your default browser, waits for the payment, and binds the funded account to your login.

#Report from the CLI

When peach compat misses a package or the running app exposes a concrete Peach compatibility gap, describe the expected and actual behavior:

peach support report "react-native-example crashes when its picker opens"

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 and the local project report from peach project-report. The report lists discovered projects, dependency versions, native build settings and machine toolchains. The compatibility scan adds Peach support classifications. Dependency versions state whether they came from installed packages, lockfiles or declared ranges. The report also includes 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:

peach support report --app ./apps/mobile "the sheet renders behind the tab bar"

#Report from inside the sim

Open the Peach 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 Peach 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. Asks and reports sent while signed in belong to your account, so you never need to keep the id:

peach support status        # every ask and report, with our replies
peach support status --new  # only what changed since the last check

A coding agent can run peach support status --new every hour to pick up our replies, the commit that fixed its report, and the runtime release that shipped it.

#Getting the fix

The bridge checks for a newer default runtime on startup and hourly, and updates connected sims that follow that default. A project with a pinned runtimeVersion keeps its selected engine. To pull the newest runtime and CLI immediately instead of waiting for the next check:

peach upgrade

peach support status names the commit that fixed a report and, once it ships, the runtime release; peach runtime notes lists the reports each release fixed. peach upgrade picks it up.

#Related

• +
  Checking compatibility
• +
  Compat overview
• +
  CLI reference