Pharen tells you how your iOS app is really doing — crashes symbolicated end-to-end, builds on testers’ phones in one command, sessions and events with consent stamped on every one, and deep links that route your app without leaking a query string. Installed with one line of code and two Info.plist values. And with one read-only key, the AI agent you already work with can ask it what your app is doing in production.
iOS first, by design. Access is by application — reviewed for approval, with the outcome by email.
// Package.swift
.package(
url: "https://github.com/pharen-ai/sdk-ios.git",
from: "2.0.0")
// Info.plist — your key + the purposes you grant
PharenIngestKey YOUR-INGEST-KEY
PharenConsentGrantedAtBuild [telemetry]
// One line of code
import PharenSDK
Pharen.start()Mint a read-only key and point any MCP client at mcp.pharen.ai. The questions you would open three dashboards to answer become questions your agent answers from your app’s own data: which version is crashing, and on which devices; how many installs are on the build you shipped this morning; whether the store rating moved after it; whether a config change actually reached anyone. The connection lives on the server — nothing is added to your app.
Your agent reads what your app does, which crashes are grouping and where, and what your store shows. Nothing about a person crosses without a grant you chose by name, and every read of a user or an install is recorded; no grant reaches a raw event or anything under the health purpose. Small groups are withheld, and on this path Pharen runs no model of its own — your agent does the reasoning, over exactly what your key is allowed to reach.
youIs 9.9.9 okay? Anything crashing that wasn’t before?
→ pharen_query · crashes.count · by app_version, device_model · 7d
→ pharen_query · sessions.count · by app_version · 7d
→ pharen_issues · sample-app · production
agent9.9.9 has 14 crashes across 6 installs this week, all iPhone14,5 — about 1% of its 1,240 sessions, and 9.9.8 had none in the same window. One issue, new since this release: SIGSEGV in SampleStore.load(fixture:). Want the frames, or the store rating since it shipped?
$ pharen query-keys create --environment production --app your-app
→ phq_live_… (shown once)
# Streamable HTTP
URL https://mcp.pharen.ai/mcp
Header Authorization: Bearer phq_live_…No grab-bag of half-features. Each capability runs the whole distance — capture to console — and they share one SDK, one event envelope, one consent model.
Fatal crashes are written to disk at crash time and delivered on the next launch — duplicate-safe, so a retry can never double-count. Symbolicated end-to-end on device builds, grouped into issues. Upload dSYMs late and existing issues re-group with real function names.
Pharen.shared?.crashReporting.recordError(
"Checkout failed: gateway timeout",
stack: Thread.callStackSymbols,
breadcrumbs: ["tapped_pay", "network_slow"]
)Upload an .ipa and get back an over-the-air install link served from edge storage — tap it in Safari, the app installs. The same step registers the release and uploads every dSYM, so crashes from that build are readable from the moment it’s installed. Or use the fastlane plugin (MIT).
$ bash release/release-lane.sh
→ archive · symbols upload · builds upload
itms-services://…/manifest.plistSessions start and end themselves — 15 minutes of inactivity ends one, no code. Add track() and screen() for your own events. Everything shares one strict envelope, so crashes, screens, and custom events sit in the same timeline, roll up into sessions, and filter the same way.
Pharen.shared?.track("checkout_completed",
properties: ["order_value": 49.99])
Pharen.shared?.screen("Cart")Accept universal links on your domains and pharen.link, route them through one hook, and create campaign-tagged short links to share. Routing always happens — consent gates the telemetry, not your navigation. And the open event reports only the domain the link arrived on; the path and query, which can hide tokens and PII, never leave the device.
Pharen.shared?.deepLinks.onLink = { link in
router.open(link.targetPath, link.params)
}Connect an App Store Connect key once, and the store’s view of your app arrives beside the SDK’s. Ratings per territory, reviews as published, search rank as a proxy, downloads, and Apple’s own launch percentiles sit next to your crash and session data — a read-only import, nothing written back.
$ pharen_store_overview
→ rating 4.8 (n=126) · search rank #38 (proxy) · 1,240 downloadsA reporting build sends the configuration it resolved at startup; the platform applies your current remote document over it, once, server-side. Read the result per build in the console or over a control credential — a build that has not polled is still on the previous document, and the read says so rather than guessing.
$ pharen_get_effective_config
→ control credential · sample-app · production · 9.9.9 (999)
{"feature_flags": {"new_checkout": true}}Not a setting bolted on — enforced at the point of collection. Purposes are opt-in; an ungranted event is dropped at the boundary, before it’s stored or sent. Personal traits route to a restricted attribute store and never travel on the event stream or appear in logs. Your tenant and environment are stamped server-side — the client can’t spoof them.
The same rule holds over the agent connection: it reads what your app does and what your store shows, and nothing about a person without a grant you chose.
This architecture is built to make GDPR- and CCPA-style privacy obligations tractable. Whether your use complies is a legal determination that stays with you — Pharen gives you the mechanism, honestly.
How the consent model works →Pharen runs in production apps. Every capability on this page has carried real releases — the crash pipeline has caught real crashes, the install links have delivered real betas. What gets in a team’s way is found and fixed in production before it reaches you.
Your data stays portable: versioned contracts and an export-ready event log. If Pharen ever isn’t right for you, your history leaves with you.
Where Pharen stands today: iOS, in production. An Android SDK, built on the same event contract, is on the roadmap. Your agent reads your app’s data, and nothing about a person without a grant you chose. Deletion and export are on request, inside the windows the DPA sets.
If that scope fits, start with Pharen. Bringing a larger team? What is already in place →
Access is by application: choose a tenant name, sign in with GitHub, accept the agreements. Applications are reviewed for approval, and the outcome arrives by email.