Measure: a self-hostable crash and ANR tracker for Android, iOS, Flutter and React Native

The problem Measure targets: mobile context scattered across tools

A crash report on its own tells you a stack trace and a device model. It rarely tells you what the user did in the ten seconds before the crash, which HTTP call was in flight, or whether the same screen is failing for everyone. The README states the goal directly: mobile developers need to use a variety of different tools to stitch context together, and Measure wants to be a single source of truth for mobile app production observability. That is the pitch. The audience is mobile teams, not backend or web teams. The supported platforms are Android, iOS, Flutter and React Native, and the README says more platforms may be supported in the future, which is a way of saying they are not supported now. If your product is a web app or a Kotlin Multiplatform shared layer with no Flutter or React Native wrapper, the SDK list is the first thing that rules Measure out.

What the repository actually contains

The default branch is main and the primary language is TypeScript, which is a useful signal about where the bulk of the code lives. The install badges point at four separate distribution channels: sh.measure:measure-android on Maven Central, measure_flutter on pub.dev, @measuresh/react-native on npm, and a Swift package indexed by the Swift Package Index. So this is a multi-SDK project with a TypeScript dashboard and backend around it, not a single library. The release tags follow the same split: v0.13.0 for the core, ios-v0.13.2, rn-v0.3.1. The version numbers are not aligned across platforms, and the React Native package is an order of magnitude behind the iOS SDK. Treat that as a maturity signal per platform rather than a project-wide one: an iOS team is looking at a 0.13 line, a React Native team at 0.3.

Session replay, traces and the capture pipeline

The feature list is the architecture, read in order. Session replays capture clicks, navigations and HTTP calls automatically, which means the SDKs instrument the UI and network layers rather than waiting for you to add manual breadcrumbs. Bug reports can be triggered by a device shake or an SDK call, and the README says they carry the full history of user actions leading to the bug, so the same event stream feeds both automatic and manual reporting. Performance traces are modelled as traces and spans, the standard parent-child shape. Network performance is reported per endpoint, and user journeys visualise which screens are most affected by issues. The one piece that changes the operational shape of all this is Adaptive Capture: the README says data collection parameters can be adjusted without rolling out an app update, so you can turn collection up during a release and down afterwards to save on storage and costs. In practice that turns sampling into a server-side setting, which is the difference between a fixed data bill and one you can dial. The Measure Agent exposes the same data in natural language from Slack or a coding agent over MCP.

Getting it running: cloud signup or self-hosted stack

The README gives two paths and no more detail than that. You either sign up to Measure Cloud at measure.sh, or you self host on your own servers, with the hosting documentation linked at measure.sh/docs/hosting. After login, the SDK integration docs at measure.sh/docs cover wiring up a client. The README does not reproduce any install command, Gradle coordinate, Podfile line or npm invocation, so the exact steps for each platform have to come from those docs rather than from this page. What is confirmed from the repository is where the artifacts live: Maven Central for Android, pub.dev for Flutter, npm for React Native, and a Swift package for iOS. The dashboard assets sit under frontend/dashboard, and the contribution guide is CONTRIBUTING.md at the repository root. If you are evaluating self-hosting, the hosting page is the document that decides it, because the README only tells you the option exists.

Where Measure is the wrong tool

Self-hosting is the obvious cost, and the README does not hide it: you are running the collector, the dashboard and whatever backs session replay storage. Replay data is heavier than a crash list, and the fact that Adaptive Capture exists as a feature is an admission that volume is a real budget line. A small team without anyone who wants to own that stack will be better served by the hosted plan or by not adopting Measure at all. The second limitation is platform coverage. Android, iOS, Flutter and React Native are supported; anything else is explicitly deferred to a future that the README does not schedule. The third is version skew. If you ship both a native iOS app and a React Native app, you are tracking two SDK lines with different version numbers and, presumably, different release cadences. There is no statement in the README about a shared release train or a compatibility matrix between the dashboard and older SDK versions, so pin your SDK versions and check the release notes for the specific tag you are on before upgrading the server side.

Firebase Crashlytics and Sentry as the comparison points

The README names Firebase Crashlytics as the thing Measure is an open source alternative to, and that framing is accurate about the difference in approach. Crashlytics is a managed Google service: you add the SDK, crashes land in the Firebase console, and you never think about the backend. Measure's default is the same shape via Measure Cloud, but the Apache-2.0 licence means the whole pipeline is also something you can run yourself, which is the reason a team with data residency constraints or a preference for owning production telemetry would look here. Sentry is the closer comparison on feature surface, since it also combines error tracking with performance traces and session replay, but Sentry's centre of gravity is web and backend SDKs with mobile as one target among many, while Measure's SDK list is only mobile. That narrower scope cuts both ways: fewer integrations to reason about, and no help if your stack reaches beyond the four supported platforms. The honest summary is that Measure competes on mobile-specific context (ANRs, user journeys, shake-to-report bug reports) and on self-hosting, not on breadth.

Licence, maintenance and what you are signing up for

Measure is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files, and it includes a patent grant. That is a permissive licence, and it is the reason self-hosting is a realistic option rather than a grey area. It also means you can fork the SDKs if a fix is not landing on your schedule. This is not legal advice; read the LICENSE file and your own counsel's view if you are embedding the SDK in a shipped product. On maintenance, the repository is active rather than archived, with the most recent push in September 2026 and releases across the core, iOS and React Native lines in the same week. The heavier ongoing cost is not the code, it is the operational side of self-hosting: storage for replay data, the dashboard, and server-side configuration changes through Adaptive Capture. Budget for that before you budget for integration work.

Editorial conclusion

Adopt Measure if you ship native Android, iOS, Flutter or React Native apps, you want session replay and performance traces in the same tool as your crash list, and you have either accepted the hosted plan or someone who can run the self-hosted stack. Do not adopt it if your app is a web app, if you need a platform the SDK list does not cover, or if nobody on the team will own the collector and its storage. Verify three things before you commit: the exact installation steps for your platform in the SDK integration docs, the resource requirements and upgrade path documented under self hosting, and whether the retention and adaptive capture settings can keep replay data inside your budget.

Official sources

1. License: Apache-2.0
2. measure-sh/measure on GitHub
3. Project website
4. README
5. Releases