Reference

Troubleshooting & FAQ

The questions that come up most, and the honest answers.

I don't see any events

Almost always one of three things:

  • The ingest key is missing or a placeholder. If PharenIngestKey isn't set to a real key, the SDK stays completely off — it's the intended way to disable Pharen in local builds. Set a real phi_test_… / phi_live_… value.
  • The purpose isn't granted. Consent is opt-in, so a started SDK with no purposes drops every event. Crashes need telemetry; sessions and track() events need behavioral. Grant them via PharenConsentGranted or at runtime. In a Debug build, the SDK prints a warning at start when nothing is granted — check the console.
  • You're looking at the wrong environment. A Debug build carrying your phi_test_… key lands in development, not production. Confirm which ring you're viewing.

My test crash didn't show up

  • Relaunch the app. Fatal crashes are written at crash time and uploaded on the next launch — the crash won't appear until you reopen the app once.
  • Run on a device, without the debugger. An attached debugger intercepts the signal before Pharen's handler sees it. Launch the app from the home screen, not from Xcode's run button.
  • Check telemetry consent. Without it, crash reports are kept on disk (not discarded) and upload once consent exists — so they may be waiting rather than lost.

Crashes aren't symbolicated

Unsymbolicated crashes mean Pharen doesn't have the build's dSYMs. Upload them — with the fastlane plugin, the Xcode run script, or pharen upload-symbols directly — and confirm your Release configuration keeps DEBUG_INFORMATION_FORMAT = dwarf-with-dsym.

Is it safe to re-run an upload or retry?

Yes — always. Symbols deduplicate by debug id (a re-run reports “already present” and exits cleanly). Builds, events, and crashes deduplicate by id on the server, so a retried upload, a relaunch that re-sends a queued event, or a crash report that takes several launches to get through are each counted once. There is nothing to reset between runs.

The CLI printed “using API …”

That's PHAREN_API_URL announcing an active override. It exists only for platform development; unset it to target the default control plane. The notice is deliberate — a stale override should never silently redirect a run.

Where do my key and token come from?

Both are provisioned when we onboard your team (contact us). Your ingest key goes in PharenIngestKey — it's public by design, so commit it. Your auth token is a secret: keep it in PHAREN_AUTH_TOKEN in your CI environment, never in source.