What Pharen does, exactly.

Captured at crash time. Delivered next launch. Counted once.

A crashing process can’t be trusted to make a network request on its way down. Pharen writes a compact report to disk at crash time and uploads it the next time your app launches. The report file is the durable queue — deleted only when the server confirms a terminal outcome.

Every report gets a deterministic id derived from the report itself, so retries across launches re-send the same id and the server answers duplicate. A crash is counted once, no matter how many launches it takes to get through. Nothing to configure, nothing to clean up.

• Uncaught exceptions and the fatal POSIX signals, with call stack, binary images, and the identity of the build that died — read at crash time, not upload time.
• Handlers chain: existing handlers still run, signals re-raise, the OS crash report is still produced.
• Grouping fingerprints the symbolicated stack and ignores volatile parts. A resolved bug that turns up on a build the crash was never seen on reopens as a regression. Pharen decides that from the build it happened on, never from one build number being higher than another.
• Late dSYMs retroactively re-group issues you already collected, with real function names.

The whole release in one command.

One step archives your app, uploads the build, mints an over-the-air install link, registers the release, and uploads every dSYM the archive produced — so crashes from that build are readable from the moment it’s installed. Send the link; a tester taps it in Safari and the app installs. No App Store, no cable, no login.

• Install links are served from a locked, CDN-fronted edge host at unguessable paths — shareable, not enumerable.
• Builds and dSYMs upload straight to edge object storage over presigned URLs — multi-megabyte artifacts never squeeze through an app server.
• Version, build number, and bundle id are read from the archived Info.plist, so uploaded metadata can never drift from what was built.
• The one secret is an auth token in your CI environment. Org and app live in a committed .pharen.yml that grants nothing on its own.
• Prefer fastlane? The plugin is MIT-licensed and published to RubyGems — one pharen_release call after build_app.

The underlying CLI is provided with your credentials when your application is approved.

One envelope. One timeline. The whole experience.

Sessions manage themselves: start at launch, continue across a short break, end after 15 minutes without activity — no code. Two calls cover your own product analytics: track() for named events, screen() for screen views.

Because every event shares one strict envelope, crashes, screens, and custom events sit in the same timeline in the event explorer, carry the same session id, roll up into session summaries, and filter the same way. A crash isn’t a separate universe from the behavior that led to it.

• Batched and sent off the main thread; persisted to disk as queued, so a killed app delivers on next launch.
• Every event has an id the server deduplicates on — a retry never double-counts.
• Properties are for dimensions and metrics, not people: the SDK drops obvious identifying keys before sending, and the server enforces the rule regardless.

Routing is yours. Telemetry is minimal.

Point your universal links at the SDK — it accepts links on pharen.link and any custom domains you add — and route every recognized link through one onLink hook. Routing always happens for a recognized link: consent gates the telemetry, never your navigation.

The open event is deliberately small. It carries the domain the link arrived on and a deferred flag — never the path or query string, either of which can hide magic-link tokens and PII. Your app still gets the full parse (route, params, source host) for routing; the route and params just never leave the device on the event stream.

• One handler covers universal links and custom-scheme opens; unrecognized hosts are simply not consumed.
• Create campaign-tagged short links on pharen.link to share — creation and opens land in the same event timeline as everything else.
• Deferred opens are flagged as such. Full post-install attribution is roadmap, stated plainly as such.

Know your users without carrying their PII.

Every event carries a stable, pseudonymous install id — no login required. Call identify() and events are also linked to your own user id, connecting one user’s activity across their sessions and installs.

Traits route to a restricted attribute store, separate from events. They are never inlined into event properties and never written to logs. The event stream carries only the pseudonymous id.

Ask it, exactly. It answers about your app.

A query key is read-only, scoped to the apps and the one environment you name, rate-limited, and revocable — tenant and environment derive from the key itself, never from the request. Point any MCP client at mcp.pharen.ai with that key in the header and the tools it lists are the ones the key allows. The host is a thin transport: it keeps no session, adds no privilege, and refuses a missing key before any tool runs.

What is askable is a registry, not a query language. A request names a metric, the dimensions to group by, and the filters — each of which must exist in the registry, or the request is refused. Grouped cells under five are withheld for builds that reached customers; your own development and tester builds answer exactly when the query names its build provenance. Nothing about a person crosses without a grant you chose. On this path Pharen runs no model of its own.

• Aggregates from the SDK: counts and sums grouped by version, build, platform, device model, OS, and build provenance — sessions, crashes, reach, new and retained installs, adoption, thermal load, SDK health, config rollout, funnel volume and reach.
• Your crashes, grouped: each issue with its title, exception, counts, when it was first and last seen, and the representative symbolicated frames — section 07.
• What the store shows: ratings per territory, review text as published, search and chart rank, downloads and engagement, the store’s own launch and hang percentiles — section 08.
• Your configuration, on a connection that presents your control credential: what each build actually enforces, and the revision history behind it.
• Users and installs, only under a grant: A user or an install, what your app said about a user, and the address a reporter left to be reached at cross only on a key you minted with the grant that covers them and a stated purpose, and every such read is recorded: in your identity reads log, or on the issue's history for a reporter's address.
• Never, under any grant: a raw event, a location a device shared, anything from the special-category store, anything under the health purpose. Those are structurally absent from the registry, not filtered out at request time.

The crash your agent can read.

An issue is every crash that shares a cause, grouped: its title and exception, how many crashes were counted into it, when it was first and last seen, the newest build it was seen on, and the frames of one representative crash — symbolicated when that build’s symbols were uploaded. The agent that writes the fix can read exactly that, over the same read-only key, newest activity first.

• Never a single crash row, a device or user identifier, or an install — an issue carries code identifiers, not people. The per-crash handle and the fingerprint the console shows are withheld from the connection.
• No small-cell floor here: a count of crashes grouped by nothing but its cause fingerprints nobody.
• Every build appears, developer builds beside customer builds — a two-part build number such as 731.1 is a developer build — because issues carry no provenance filter. The customer-facing crash count stays crashes.count, which defaults to released builds.
• The most recently active issues, up to a hundred; the console holds the full history.