Analytics
Analytics for an Expo app, compared: PostHog, Amplitude, or none - Expo Go support and what each option installs.
Hey - here's how analytics work in ReadyNative.
This category owns product events: the three calls you make from screens, and the automatic screen event the root layout sends on every route change.
@/lib/analytics always exists, whichever option you pick: analytics.track(), analytics.identify() and analytics.screen() read the same in every one of them, and analytics/none is a no-op. Calls you write against the shim keep working when you switch options, and nothing crashes when the key is missing - every option degrades to a no-op.
Pick PostHog if you want events and feature flags from one service with a generous free tier, and the option to self-host later; it's the default here. Pick Amplitude if your team already lives in its funnels and cohorts, or you have an existing project to send to.
This category is part of ReadyNative Pro.
Options
One option per category - --analytics <option> picks it:
bun run setup --analytics posthog| Option | Label | Expo Go | Hint |
|---|---|---|---|
posthog | PostHog (default) | yes | product analytics + feature flags (analytics.isFeatureEnabled / useFeatureFlag) · Expo Go OK |
amplitude | Amplitude | yes | product analytics · Expo Go OK (JS SDK, storage adapter) |
none | No analytics | yes | analytics.track/identify/screen are no-ops, feature flags read undefined |