See what your last release did to hangs, launch time and memory.
Apple's MetricKit already collects this from your users' devices: hangs, slow launches, memory kills, CPU and disk-write exceptions, crashes. It arrives as raw addresses, one device at a time, and stops. MetricLens collects the reports, turns your app's frames into function names, groups them into issues, and compares each release with the one before.
Symbolication is checked against Apple's own atos on every instruction of a test binary: 99.93% of functions match. · The SDK has no dependencies and installs no crash handler; it will be published as open source under the MIT licence before anyone is asked to install it. · Raw reports are stored unmodified and you can download them.
The part MetricKit leaves to you
Every report arrives as addresses, not function names, one device at a time. Making that useful means a backend, a symbolicator, grouping, and release comparison. Most teams never build it.
Symbolicated
Upload dSYMs from CI. Frames from your app and its frameworks become functions, files and lines, including inlined frames. Apple system frames are shown as library and offset for now. A frame with no matching symbols is marked missing, never guessed. Symbols that arrive late are applied to reports already received.
Grouped
Reports with the same cause become one issue, with counts, the releases it appears in, and (if you leave the optional install number on) affected installs. Each issue shows exactly what it was grouped on.
Release by release
New, regressed and resolved issues for each version, and launch time, hang time, memory and exits compared with the one before.
More than crashes
MetricKit reports hangs, CPU and disk-write exceptions, slow launches and memory terminations, plus daily histograms. MetricLens takes all of it.
- Flame graph and call tree for sampled diagnostics, merged across reports
- Histograms merged bucket by bucket; percentiles are never averaged
- Both the original API and the one rebuilt for iOS 27
- Works alongside Crashlytics or Sentry; it does not replace them
Three kinds of evidence. Three kinds of marks.
MetricKit reports a moment, a set of samples, and a distribution. Most tools draw all three as a count or a line. MetricLens draws each as what it is, so a chart cannot claim more than the data does.
A needle per report
A crash happened once, at one place. Each report is one needle, and the stack points at the line.
Never a share. A count of crashes is not a percentage of anything.
A dot is 1% of samples
MetricKit takes stack samples while the app is busy. The field shows where those samples landed, merged across devices, and marks frames it cannot name.
Never time or bytes. Samples say where the app was seen, not what a function cost.
A percentile is a bracket
Histograms are merged bucket by bucket across devices. A percentile is drawn over the whole bucket it falls in, with the estimate marked inside.
Never an average of percentiles. Two p90s do not average to a p90.
Every view reads through one release and the one before.
- Rates, per 1,000 device-days, so a small rollout is not a lucky release.
- Thin data looks thin. Under 30 device-days a release is drawn stippled, with counts instead of rates.
- Missing symbols stay hatched, as binary and offset. They are never given a made-up name.
Segment width follows device-days. Illustration with sample data.
What is verified today
MetricLens is being built in the open about its own state. This is what has been checked against a real device, and what has not.
Crash reports
in both MetricKit formats, including iOS 27's
- Documented
- Decoded
- Seen on a device
- Matches Apple's tool
Verified on real crashes from an iPhone on iOS 27.0: function, file and line, inlined calls included, matching Apple's atos.
Hang, CPU, disk-write, launch and memory diagnostics
- Documented
- Decoded
- Seen on a device
- Matches Apple's tool
Decoded from Apple's documented format. Not yet captured from a device, so not yet verified.
Daily metric reports
(launch time, hang time, memory, exits)
- Documented
- Decoded
- Seen on a device
- Matches Apple's tool
The iOS 27 report shape was learned from Apple's own decoder. Real values have been seen for disk-space metrics only. Release comparison is built and runs on sample data.
As of October 2026. The private beta exists to verify the rest with real apps.
If you already use…
MetricLens sits beside what you have. It does not replace your crash reporter.
Xcode Organizer
What you have
Apple's aggregate view, free. No alerts, no export, no history of your own.
Your own history, per-issue call trees, and release-by-release changes you can link to in a pull request.
Crashlytics
What you have
Crashes and non-fatals. Nothing from MetricKit: no hang call stacks, no launch or memory histograms, no CPU or disk-write exceptions.
All of those, next to Crashlytics. No second crash handler is installed, so the two cannot conflict.
Sentry
What you have
Crashes, plus MetricKit hang, CPU and disk-write diagnostics as individual events. No daily metric histograms and no release comparison built on them today; capturing MetricKit crashes is in review there.
Histograms merged correctly across devices, and one release compared with the last.
Your own MetricKit code
What you have
JSON in a bucket.
The symbolicator, grouping and dashboard you did not want to build.
Checked October 2026. These tools change; tell us if a row is out of date.
Three steps
No swizzling, no dependencies, no crash handler.
A Swift package with no dependencies. To be published as open source (MIT).
MetricLens.start(key: "ml_ingest_…", endpoint: …)
Uploads debug symbols after each build, the way Crashlytics does. It never fails your build.
"${BUILD_DIR%/Build/*}/…/metriclens-ios/run"Reports arrive within a day of use. Open the dashboard and compare the release with the last one.
What leaves the device
Only what MetricKit itself reports. The package will be open source, so you can read exactly what is sent.
Sent
- MetricKit's reports, unmodified: call stacks as addresses, histograms, counts
- App version, OS version, device model
- Optionally a random per-install number, to count affected installs. It can be turned off.
Not sent
- Names, emails, account or advertising identifiers
- Screen contents, network requests, logs
- Anything from outside your app
Pricing
Not available yet. There is no beta to join today; the waitlist is how you hear when there is. These are the prices we are testing, and they will change based on what the waitlist tells us.
Free
Trying it on one app
- 1 app, 14 days of history
Indie
Solo developers
- 3 apps, 90 days, alerts for new issues
Team
Small teams
- 10 apps, 1 year, alerts to Slack or a webhook, members
Business
Companies
- Unlimited apps, single sign-on, API and export
Questions
Does it replace my crash reporter?
No. MetricKit delivers reports up to a day late and without your logs or breadcrumbs. Keep your crash reporter for crashes; use MetricLens for what it cannot see.
What does the SDK do in my app?
It subscribes to MetricKit, writes each report to disk, and uploads it in the background. No swizzling, no crash handler.
Who can see my dSYMs?
Only members of your project. They are stored privately and are never shared between customers.
What if MetricLens shuts down?
The SDK will be open source and the payloads are Apple's own format. Each report's raw payload can be downloaded as received.
Which apps does it suit?
Native iOS apps with at least a few hundred daily users. Below that, MetricKit sends too few reports for trends to mean much.
Who makes it?
An independent developer. It is not affiliated with Apple or with any crash-reporting vendor.
Help decide what gets built first
A two-minute survey about how you track performance today. No account, and every question but one is optional.