Need help with Meter?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

132 Stars 2 Forks BSD 3-Clause "New" or "Revised" License 28 Commits 1 Opened issues


Library for interacting with MetricKit

Services available


Need anything else?

Contributors list

Github CI Carthage compatible


Meter is a companion library to MetricKit. It aims to provide the following capabilities:

  • API for
  • Types for
    emulation and coding
  • MXMetricManager
    -like interface for unsupported platforms
  • On-device symbolication (still under investigation)


Swift Package Manager

dependencies: [
    .package(url: "")


github "ChimeHQ/Meter"

Expanded API

The MetricKit API for crash reporting is unwieldy. In particular,

lacks any kind of interface for interacting with its structure. Meter includes some classes that make it easier to work with. In addition to providing an API for
, Meter includes types to emulate and parse MetricKit diagnostics.
let data = mxTree.jsonRepresentation()
let tree = try CallStackTree.from(data: data)

for frame in tree.callStacks[0].frames { print("(frame.address) (frame.binaryName) (frame.binaryUUID)") }

MXMetricManager and Diagnostics Polyfill

MetricKit's crash reporting facilities require iOS 14, and isn't supported at all for tvOS, watchOS, or macOS. You may want to start moving towards using it as a standard interface between your app and whatever system consumes the data. Meter offers an API that's very similar to MetricKit's

to help do just that.
// adding a subscriber

extension MyObject: MeterPayloadSubscriber { func didReceive(_ payloads: [DiagnosticPayloadProtocol]) { // this will be called for both simulated payloads and MeterKit payloads on OSes it supports print("received payloads (payloads)") } }

// posting diagnostics MeterPayloadManager.shared.deliver(payloads)

This makes it easier to support the full capabilities of MetricKit when available, and gracefully degrade when they aren't. It can be nice to have a uniform interface to whatever backend system you are using to consume the reports. And, as you move towards an iOS 14 minimum, and as (hopefully) Apple starts supporting MetricKit on more platforms, it will be easier to pull out Meter altogether.

Backwards compatibility is still up to you, though. One solution is ImpactMeterAdapter, which uses Impact to collect crash data for OSes that don't support


If you're also looking for a way to transmit report data to your server, check out Wells.

On-Device Symbolication

The stack traces provided by MetricKit, like other types of crash logs, are not symbolicated. There are a bunch of different ways to tackle this problem, but one very convenient option is just to do it as a post-processing step on the device where the crash occurred. The

family of APIs could be one approach. It has had some real limitions in the past, particularly on iOS. But, still worth a look.

Right now, this functionality is still in the investigation phase. But, if you have thoughts, please get in touch!

Suggestions or Feedback

We'd love to hear from you! Get in touch via twitter, an issue, or a pull request.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.