Introducing Observe

Masonry Okay, so Expo just shipped this thing called Observe, and… my first reaction is just relief? Like, somebody finally named the gap.

Eyre Which gap is that?

Masonry The one between your dev tools and your crash reporter. You've got React Native DevTools and Expo Atlas while you're building, you've got Sentry and Bugsnag when something breaks. But the app that doesn't crash, it's just… slow? Nobody's been answering that question.

Eyre Right.

Masonry And it's the question that actually costs you users. How long does cold launch really take in the field? Did that dependency bump add four hundred milliseconds to startup?

Eyre Okay, that's a real gap. I'll give you that one. So what'd they actually ship?

Masonry Five built-in metrics from real production sessions. Cold launch, warm launch, time to first render, time to interactive, and bundle load. And they report the full distribution — median, average, min, max, P90, P99.

Eyre The P99 is the part that actually matters. If you're only looking at the median, you're looking at the happy path. The slowest ten percent of sessions is where your churn is hiding.

Masonry Yeah, and each data point carries context — device model, OS version, app version, region, network type, even thermal state and low-power mode. So 'startup is slow' becomes 'startup is slow on older Android devices on cellular.' That's a problem you can actually fix.

Eyre That's good engineering. The thermal state and low-power-mode context especially — those are the confounders nobody tracks, and they're exactly why you see a regression in your dashboard and can't explain it.

Masonry And the release comparison thing is slick too. They overlay your builds and OTA updates directly on the timeline. So a regression isn't a mystery, it's a vertical line you point at.

Eyre Okay.

Masonry You can compare version to version, build to build, even embedded JS against an OTA update, then drill down to a specific build number.

Eyre That's the part I genuinely like. The version-overlays-on-timeline approach — that's the thing you'd otherwise build by hand with a spreadsheet and a prayer. Having it baked in means teams actually look at it instead of meaning to look at it.

Masonry Exactly. And per-screen navigation metrics for both Expo Router and React Navigation. That part's opt-in through the config object.

Eyre Makes sense to keep it opt-in — not every screen needs that overhead. They separate initial renders from subsequent ones too, which is a good call. Opening a modal and closing it back to the previous screen is a fundamentally different render cost than mounting fresh.

Masonry Right, and there's a markInteractive call you add so you get TTI per screen, not just for the app launch.

Eyre The markInteractive placement is going to be the tricky part. You have to call it after auth, data loading, splash screen hidden — and if you put it in the wrong spot, you're measuring your own instrumentation, not real interactivity.

Masonry True, but the setup is like five minutes. Install expo-observe, wrap your root layout with ObserveRoot, call markInteractive where your app's actually ready, ship a production build. Metrics just start flowing.

Eyre And it's SDK fifty-six plus. That's a reasonable floor — most active Expo projects should be there by now.

Masonry Oh — and here's the part where I know what you're going to say. They built it with agents in mind from day one.

Eyre Of course they did.

Masonry Every metric is queryable from the EAS CLI. Like, 'eas observe metrics-summary dash dash days seven.' And they all have dash dash json output. So you can pipe that straight into an agent for analysis.

Eyre That's… actually clever. The JSON output on every command means an agent can pull the data, do the regression analysis, and tell you which route is slow and why. Instead of a human staring at a dashboard guessing.

Masonry There's an expo-observe skill that includes instructions for agents on how to install, configure, and analyze the metrics. You literally say 'please set up Observe on this project' and it handles it.

Eyre Okay, I'm somewhat won over. The agent-first design isn't just a buzzword here — they actually structured the CLI surface so an agent can do something useful with it. That's different from slapping 'AI-powered' on a dashboard.

Masonry I knew you'd come around.

Eyre Don't push it.

Masonry But here's the thing people should know — it's free during open beta, first ten thousand MAUs. But it goes GA on August twentieth, and after that there's a free tier up to one thousand MAUs, then paid plans that scale on usage.

Eyre So the ten-thousand-MAU free beta is the window. After August twentieth it shrinks to one thousand. That's a meaningful change for anyone who's been testing this.

Masonry They're giving sixty days notice before pricing kicks in. So it's not a surprise, but if you're sitting on a beta app and you haven't checked your MAU count… maybe do that.

Eyre The one thousand MAU free tier keeps all five metrics though, right?

Masonry Yeah, all five. So smaller apps aren't getting a crippled version. You just hit the ceiling sooner.

Eyre That's a reasonable free tier. Not a bait-and-switch. The question is whether the paid pricing is sane — and we don't have those numbers yet, which is the one thing I'd flag.

Masonry Fair. But Eyre — for a five-minute integration that tells you how your app actually performs in the field? This is the thing the ecosystem's been missing. The gap was real, and they filled it.

Eyre Yeah, I'll give you this one. The gap was real and they filled it. Don't make it a habit.