Skill 82 · Instrument Product Analytics
Subchapter 82.51
references/react-native.mdMarkdown56 KBView on GitHub
AI agents: this is one page from PostHog’s docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt (opens in a new tab)
Our React Native enables you to integrate PostHog with your React Native project. For React Native projects built with Expo, there are no mobile native dependencies outside of supported Expo packages.
To install, add the posthog-react-native package to your project as well as the required peer dependencies.
Terminal
npx expo install posthog-react-native expo-file-system expo-application expo-device expo-localizationTerminal
yarn add posthog-react-native @react-native-async-storage/async-storage react-native-device-info react-native-localize
# or
npm i -s posthog-react-native @react-native-async-storage/async-storage react-native-device-info react-native-localizeIf you’re using React Native Web (opens in a new tab) or React Native macOS (opens in a new tab), do not use the expo-file-system (opens in a new tab) package since the Web and macOS targets aren’t supported, use the @react-native-async-storage/async-storage (opens in a new tab) package instead.
The recommended way to set up PostHog for React Native is to use the PostHogProvider. This utilizes the Context API to pass the PostHog client around, and enables autocapture (opens in a new tab).
To set up PostHogProvider, add it to your App.js or App.ts file:
App.js
// App.(js|ts)
import { usePostHog, PostHogProvider } from 'posthog-react-native'
...
export function MyApp() {
return (
<PostHogProvider apiKey="<ph_project_token>" options={{
// usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
host: 'https://us.i.posthog.com',
}}>
<MyComponent />
</PostHogProvider>
)
}Then you can access PostHog using the usePostHog() hook:
React Native
const MyComponent = () => {
const posthog = usePostHog()
useEffect(() => {
posthog.capture("event_name")
}, [posthog])
}If you prefer not to use the provider, you can initialize PostHog in its own file and import the instance from there:
posthog.ts
import PostHog from 'posthog-react-native'
export const posthog = new PostHog('<ph_project_token>', {
// usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
host: 'https://us.i.posthog.com'
})Then you can access PostHog by importing your instance:
React Native
import { posthog } from './posthog'
export function MyApp1() {
useEffect(() => {
posthog.capture('event_name')
}, [])
return <View>Your app code</View>
}You can even use this instance with the PostHogProvider:
React Native
import { posthog } from './posthog'
export function MyApp() {
return <PostHogProvider client={posthog}>{/* Your app code */}</PostHogProvider>
}The optional @posthog/react-native-plugin package adds native features such as session replay and native crash capture. Install it as described in the guide for the feature that you use. Then choose one iOS dependency path:
| Path | Requirements | What it resolves |
|---|---|---|
| CocoaPods | A React Native project that uses CocoaPods | CocoaPods resolves the plugin and posthog-ios. This remains the default path. |
CocoaPods with posthog-ios through Swift Package Manager | React Native 0.75 or later and a CocoaPods project with dynamic frameworks | CocoaPods resolves the plugin. Swift Package Manager resolves posthog-ios. |
| Full Swift Package Manager | Verified with an iOS-only React Native 0.87.1 app and React Native Community CLI 20.2.0. Requires @posthog/react-native-plugin 2.4.0 or later, Xcode 16 or later, and an iOS 15.1 or later app deployment target. | React Native’s experimental Swift Package Manager integration resolves the plugin and posthog-ios. This path does not use CocoaPods. |
This verification does not cover Expo or other React Native versions. Use CocoaPods or the hybrid path unless you validate the full Swift Package Manager path for your configuration.
Use the standard React Native CocoaPods flow:
Terminal
cd ios
pod installThe plugin podspec adds posthog-ios as a CocoaPods dependency. You do not need to add posthog-ios separately.
Add the following property to ios/Podfile.properties.json:
JSON
{
"posthog.useSpm": "true"
}Add dynamic frameworks to your ios/Podfile:
Ruby
use_frameworks! :linkage => :dynamicThen install the pods:
Terminal
cd ios
pod installThis setting changes only how the plugin resolves posthog-ios. The plugin and other React Native dependencies still use CocoaPods.
This path uses React Native’s experimental CocoaPods-free iOS integration. Every native dependency in your app must support React Native’s full Swift Package Manager integration. Use CocoaPods or the hybrid path if a dependency does not support it.
Install your JavaScript dependencies first. Make a clean commit or a backup of your iOS project before the conversion. Then run this command from the ios directory:
Terminal
npx react-native spm add --deintegrate --yesThe --deintegrate option removes the complete CocoaPods integration from the iOS project. React Native then finds the plugin’s ios/Package.swift manifest. Swift Package Manager resolves the plugin and posthog-ios. Do not run pod install for this path.
PostHog CI verifies this path with the configuration in the requirements table. The verified app sets its deployment target to iOS 15.1. The plugin package manifest has a separate iOS 15 minimum. The CocoaPods and hybrid paths keep the plugin podspec’s iOS 13 minimum.
Set up a reverse proxy (recommended)
We recommend setting up a reverse proxy (opens in a new tab), so that events are less likely to be intercepted by tracking blockers.
We have our own managed reverse proxy service (opens in a new tab), which is free for all PostHog Cloud users, routes through our infrastructure, and makes setting up your proxy easy.
If you don’t want to use our managed service then there are several other options for creating a reverse proxy, including using Cloudflare (opens in a new tab), AWS Cloudfront (opens in a new tab), and Vercel (opens in a new tab).
Grouping products in one project (recommended)
If you have multiple customer-facing products (e.g. a marketing website + mobile app + web app), it’s best to install PostHog on them all and group them in one project (opens in a new tab).
This makes it possible to track users across their entire journey (e.g. from visiting your marketing website to signing up for your product), or how they use your product across multiple platforms.
Add IPs to Firewall/WAF allowlists (recommended)
For certain features like heatmaps (opens in a new tab), your Web Application Firewall (WAF) may be blocking PostHog’s requests to your site. Add these IP addresses to your WAF allowlist or rules to let PostHog access your site.
EU: 3.75.65.221, 18.197.246.42, 3.120.223.253
US: 44.205.89.55, 52.4.194.122, 44.208.188.173
These are public, stable IPs used by PostHog services.
PostHog captures heatmap screenshots using Browserless (opens in a new tab), which has its own IP addresses. Browserless publishes the current list here (opens in a new tab).
An allowlist does not help when your app has a private address. For apps on an internal network, see internal and intranet applications (opens in a new tab).
You can further customize how PostHog works through its configuration on initialization.
| Attribute | Description |
|---|---|
host Type: String Default: https://us.i.posthog.com | PostHog API host (usually https://us.i.posthog.com by default or https://eu.i.posthog.com). Host is optional if you use https://us.i.posthog.com. |
flushAt Type: Number Default: 20 | The number of events to queue before sending to PostHog (flushing). |
flushInterval Type: Number Default: 10000 | The interval in milliseconds between periodic flushes. |
maxBatchSize Type: Number Default: 100 | The maximum number of queued messages to be flushed as part of a single batch (must be higher than flushAt). |
maxQueueSize Type: Number Default: 1000 | The maximum number of cached messages either in memory or on the local storage (must be higher than flushAt). |
disabled Type: Boolean Default: false | If set to true, the SDK is essentially disabled (useful for local environments where you don’t want to track anything). |
defaultOptIn Type: Boolean Default: true | If set to false, the SDK will not track until the optIn() function is called. |
sendFeatureFlagEvent Type: Boolean Default: true | Whether to track that getFeatureFlag was called (used by experiments). |
preloadFeatureFlags Type: Boolean Default: true | Whether to load feature flags when initialized or not. |
bootstrap Type: Object Default: {} | Seeds identity (distinctId, isIdentifiedId) and feature flag state (featureFlags, featureFlagPayloads) during initialization. See SDK bootstrapping (opens in a new tab). |
disableRemoteFeatureFlags Type: Boolean Default: false | When true, the SDK never fetches or evaluates feature flags from PostHog, and identify(), group(), and reset() stop triggering /flags requests. Supply flag values yourself via bootstrap (at startup) and updateFlags() (at runtime). Available in version 4.49.0+. |
fetchRetryCount Type: Number Default: 3 | How many times HTTP requests will be retried. |
fetchRetryDelay Type: Number Default: 3000 | The delay between HTTP request retries. |
requestTimeout Type: Number Default: 10000 | Timeout in milliseconds for any calls. |
featureFlagsRequestTimeoutMs Type: Number Default: 10000 | Timeout in milliseconds for feature flag calls. |
sessionExpirationTimeSeconds Type: Number Default: 1800 | For session analysis, how long before a session expires (defaults to 30 minutes). |
persistence Type: String Default: file | Allows you to provide the storage type. file will try to load the best available storage, the provided customStorage, customAsyncStorage, or in-memory storage. |
customAppProperties Type: Object or Function Default: null | Allows you to provide your own implementation of the common information about your App or a function to modify the default App properties generated. |
customStorage Type: Object Default: null | Allows you to provide a custom asynchronous storage such as async-storage, expo-file-system, or a synchronous storage such as mmkv. If not provided, PostHog will attempt to use the best available storage via optional peer dependencies. If persistence is set to memory, this option is ignored. |
captureAppLifecycleEvents Type: Boolean Default: true | Captures app lifecycle events such as Application Installed, Application Updated, Application Opened, Application Became Active, and Application Backgrounded. Enabled by default since version 4.39.0. |
disableGeoip Type: Boolean Default: false | When true, disables automatic GeoIP resolution for events and feature flags. |
enableSessionReplay Type: Boolean Default: false | Enable Recording of Session replay for Android and iOS. |
sessionReplayConfig Type: Object Default: null | Session replay configuration. See the replay install docs (opens in a new tab) for more details. |
enablePersistSessionIdAcrossRestart Type: Boolean Default: false | When true, persists the $session_id across app restarts. If false, $session_id always resets on app restart. |
evaluationContexts Type: Array of Strings Default: undefined | Evaluation context tags that constrain which feature flags are evaluated. When set, only flags with matching evaluation context tags (or no evaluation context tags) will be returned. This helps reduce unnecessary flag evaluations and improves performance. See evaluation contexts documentation (opens in a new tab) for more details. Available in version 4.21.0+. The legacy parameter evaluationEnvironments (version 4.10.0+) is also supported for backward compatibility. |
addTracingHeaders Type: Array of Strings Default: undefined | Hostnames for which PostHog should add tracing headers to outgoing fetch requests. Matching requests include X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID, which lets backend events, errors, and LLM traces link back to frontend sessions and replays. Use hostnames only, without the protocol or path. |
before_send Type: Function Default: undefined | A callback function that is called before each event is sent to PostHog. You can use it to modify, filter, or suppress events. Return null to drop the event, or return the modified event to send it. See customizing exception capture for details. |
capturePushNotificationSubscriptions Type: Boolean Default: true | Whether to automatically register this device’s push token so Workflows (opens in a new tab) can target it. Requires @posthog/react-native-plugin. See push notifications. Available in version 4.62.0+. |
capturePushNotificationOpened Type: Boolean Default: true | Whether to automatically capture $push_notification_opened when the user taps a push notification. Requires @posthog/react-native-plugin. See push notifications. Available in version 4.62.0+. |
pushIdentityProvider Type: Function Default: undefined | Supplies a signed identity-verification token for push subscription requests. Only needed when your push channel requires identity verification. See identity verification. Available in version 4.62.0+. |
Use addTracingHeaders to connect React Native network requests to backend events, errors, and LLM traces captured by a server-side PostHog SDK:
typescript
const posthog = new PostHog('<ph_project_token>', {
host: 'https://us.i.posthog.com',
addTracingHeaders: ['api.example.com'],
})Hostnames are matched exactly. The SDK patches global fetch and sends X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID on matching requests when those values are available.
You can send custom events using capture:
React Native
posthog.capture('user_signed_up')Tip: We recommend using a
[object] [verb]format for your event names, where[object]is the entity that the behavior relates to, and[verb]is the behavior itself. For example,project created,user signed up, orinvite sent.
Optionally, you can include additional information with the event by including a properties (opens in a new tab) object:
React Native
posthog.capture('user_signed_up', {
login_type: "email",
is_free_trial: true
})When using @react-navigation/native (opens in a new tab) v6 or lower, screen tracking is automatically captured if the autocapture (opens in a new tab) property is used in the PostHogProvider:
It is important that the PostHogProvider is configured as a child of the NavigationContainer:
React Native
// App.(js|ts)
import { PostHogProvider } from 'posthog-react-native'
import { NavigationContainer } from '@react-navigation/native'
export function App() {
return (
<NavigationContainer>
<PostHogProvider apiKey="<ph_project_token>" autocapture>
{/* Rest of app */}
</PostHogProvider>
</NavigationContainer>
)
}When using @react-navigation/native (opens in a new tab) v7 or higher, screen tracking has to be manually captured:
React Native
// App.(js|ts)
import { PostHogProvider } from 'posthog-react-native'
import { NavigationContainer } from '@react-navigation/native'
// Using `PostHogProvider` is optional, but needed if you want to capture touch events automatically with the `captureTouches` option.
export function App() {
return (
<NavigationContainer>
<PostHogProvider apiKey="<ph_project_token>" autocapture={{
captureScreens: false, // Screen events are handled differently for v7 and higher
captureTouches: true,
}}>
{/* Rest of app */}
</PostHogProvider>
</NavigationContainer>
)
}Check out and set it up the official way for Screen tracking for analytics (opens in a new tab).
Then call the screen method within the trackScreenView method.
React Native
const posthog = usePostHog() // use the usePostHog hook if using the PostHogProvider or your own custom posthog instance
// you can read the params from `getCurrentRoute()`
posthog.screen(currentRouteName, params)First, simplify the wrapping of your screens with a shared PostHogProvider:
React Native
import PostHog, { PostHogProvider } from 'posthog-react-native'
import { Navigation } from 'react-native-navigation';
export const posthog = new PostHog('<ph_project_token>');
export const SharedPostHogProvider = (props: any) => {
return (
<PostHogProvider client={posthog} autocapture={{
captureScreens: false, // Screen events are handled differently for react-native-navigation
captureTouches: true,
}}>
{props.children}
</PostHogProvider>
);
};Then, every screen needs to be wrapped with this provider if you want to capture touches or use the usePostHog() hook
React Native
export const MyScreen = () => {
return (
<SharedPostHogProvider>
<View>
...
</View>
</SharedPostHogProvider>
);
};
Navigation.registerComponent('Screen', () => MyScreen);
Navigation.events().registerAppLaunchedListener(async () => {
posthog.initReactNativeNavigation({
navigation: {
// (Optional) Set the name based on the route. Defaults to the route name.
routeToName: (name, properties) => name,
// (Optional) Tracks all passProps as properties. Defaults to undefined
routeToProperties: (name, properties) => properties,
},
captureScreens: true,
});
});Check out and set it up the official way for Screen tracking for analytics (opens in a new tab).
Then call the screen method within the useEffect callback.
React Native
const posthog = usePostHog() // use the usePostHog hook if using the PostHogProvider or your own custom posthog instance
posthog.screen(pathname, params)If you prefer not to use autocapture, you can manually capture screen views by calling posthog.screen(). This function requires a name. You may also pass in an optional properties object.
JavaScript
posthog.screen('dashboard', {
background: 'blue',
hero: 'superhog',
})PostHog autocapture can automatically track the following events for you:
@react-navigation/native (v6 or lower) or react-native-navigation), check out the capturing screen views (opens in a new tab) section⚠️ React Navigation v7 users
React Navigation v7 restricts navigation hooks (such as
useNavigationState) to components rendered inside a Screen that belongs to a Navigator.Because of this change, automatic screen tracking may throw errors if PostHog is initialized outside a screen context. This commonly affects apps upgrading from React Navigation v6 to v7.
For React Navigation v7, we recommend disabling automatic screen capture for screens and manually calling
posthog.screen()inside each screen component. See the Capturing screen views (opens in a new tab) section below.
Application lifecycle events are enabled by default. Screen capture is enabled by default in PostHogProvider unless you set captureScreens: false. Touch capture is disabled by default and requires captureTouches: true.
When touch capture is enabled, touch events for children of PostHogProvider are tracked, capturing a snapshot of the view hierarchy at that point. This enables you to create insights (opens in a new tab) in PostHog without adding custom events.
PostHog will try to generate a sensible name for touched elements based on the React component displayName or name. If you prefer, you can set your own name using the ph-label prop:
React Native
<View ph-label="my-special-label"></View>React Native
<PostHogProvider apiKey="<ph_project_token>" autocapture={{
captureTouches: true, // Disabled by default
captureScreens: true, // Enabled by default
ignoreLabels: [], // Any labels here will be ignored from the stack in touch events
customLabelProp: "ph-label",
maxElementsCaptured: 20,
noCaptureProp: "ph-no-capture",
propsToCapture: ["testID"], // Limit which props are captured. By default, identifiers and text content are captured.
navigation: {
// By default, only the screen name is tracked but it is possible to track the
// params or modify the name by intercepting the autocapture like so
routeToName: (name, params) => {
if (params.id) return `${name}/${params.id}`
return name
},
routeToProperties: (name, params) => {
if (name === "SensitiveScreen") return undefined
return params
},
},
}}>
...
</PostHogProvider>If there are elements you don’t want to be captured, you can add the ph-no-capture property. If this property is found anywhere in the view hierarchy, the entire touch event is ignored:
React Native
<View ph-no-capture>Sensitive view here</View>With captureScreens: true (the default in PostHogProvider), PostHog captures a $screen event automatically when the user navigates, provided you’re using @react-navigation/native (v6 or lower) or react-native-navigation.
To manually send a screen capture event, use the screen method:
React Native
posthog.screen('Dashboard', { fromIcon: 'bottom' })React Navigation v7 users: automatic screen tracking may throw errors if PostHog is initialized outside a screen context. For v7, disable automatic screen capture (
captureScreens: false) and callposthog.screen()manually inside each screen component.
You can stop specific screens from being autocaptured by filtering them in your before-send hook. Return null for any $screen event whose $screen_name matches a screen you don’t want to track, and it’s dropped before being sent – keeping unwanted screen views out of your event log.
Because it’s just a function, you can filter however you like – an ignorelist (drop the screens you name), an allowlist (invert the check to capture only the screens you name), or any custom rule such as a name prefix, a regex, or a check against the event’s properties.
before_send is a client option, so pass it via the provider’s options prop (or to new PostHog(...) if you create the client yourself):
React Native
const IGNORED_SCREENS = new Set(['Splash', 'Debug'])
<PostHogProvider
apiKey="<ph_project_token>"
autocapture={{ captureScreens: true }}
options={{
host: 'https://us.i.posthog.com',
before_send: (event) => {
if (event?.event === '$screen') {
const screenName = event.properties?.['$screen_name']
return IGNORED_SCREENS.has(screenName) ? null : event
}
return event
},
}}
>
{/* app */}
</PostHogProvider>Swap the check for an allowlist (return TRACKED_SCREENS.has(screenName) ? event : null) if you’d rather capture only a specific set of screens.
before_send accepts a single function or an array of functions that run in order, so you can compose several small hooks. Filtering screens is one use – here are a few others.
Drop a specific event. Stop an internal or debug event from ever being sent:
React Native
const posthog = new PostHog('<ph_project_token>', {
before_send: (event) => {
if (event?.event === 'debug_only_event') {
return null // never send this event
}
return event
},
})Log events instead of sending them. Handy while debugging what would be captured:
React Native
const posthog = new PostHog('<ph_project_token>', {
before_send: (event) => {
console.log('[PostHog] would send', event?.event, event?.properties)
return null // drop everything
},
})Redact sensitive properties. Strip a value before it leaves the device:
React Native
const posthog = new PostHog('<ph_project_token>', {
before_send: (event) => {
if (event?.properties?.email) {
event.properties.email = '***'
}
return event
},
})For more examples, see the JavaScript Web SDK docs (opens in a new tab).
We highly recommend reading our section on Identifying users (opens in a new tab) to better understand how to correctly use this method.
Using identify, you can associate events with specific users. This enables you to gain full insights as to how they’re using your product across different sessions, devices, and platforms.
An identify call has the following arguments:
React Native
posthog.identify('distinctID',
{ // ($set):
email: 'user@posthog.com',
name: 'My Name'
}
)$set_once works just like $set, except that it will only set the property if the user doesn’t already have that property set. See the difference between $set and $set_once (opens in a new tab)
React Native
posthog.identify('distinctID',
{
$set: {
email: 'user@posthog.com',
name: 'My Name'
},
$set_once: {
date_of_first_log_in: '2024-03-01'
}
}
)You should call identify as soon as you’re able to. Typically, this is after your user logs in. This ensures that events sent during your user’s sessions are correctly associated with them.
When you call identify, all previously tracked anonymous events (opens in a new tab) will be linked to the user.
You may find it helpful to get the current user’s distinct ID. For example, to check whether you’ve already called identify for a user or not.
To do this, call posthog.get_distinct_id(). This returns either the ID automatically generated by PostHog or the ID that has been passed by a call to identify().
Sometimes, you want to assign multiple distinct IDs to a single user. This is helpful when your primary distinct ID is inaccessible. For example, if a distinct ID used on the frontend is not available in your backend.
In this case, you can use alias to assign another distinct ID to the same user.
React Native
// Sets alias for current user
posthog.alias('distinct_id')We strongly recommend reading our docs on alias (opens in a new tab) to best understand how to correctly use this method.
Person properties enable you to capture, manage, and analyze specific data about a user. You can use them to create filters (opens in a new tab) or cohorts (opens in a new tab), which can then be used in insights (opens in a new tab), feature flags (opens in a new tab), and more.
To set a user’s properties, include the $set or $set_once property when capturing any event:
JavaScript
posthog.capture('some_event', { $set: { userProperty: 'value' } })$set_once works just like $set, except it only sets the property if the user doesn’t already have that property set.
JavaScript
posthog.capture('some_event', { $set_once: { userProperty: 'value' } })You can also use setPersonProperties() and unsetPersonProperties() to manage person properties directly. See person properties (opens in a new tab) for examples.
Super properties are properties associated with events that are set once and then sent with every capture call, be it a $screen, an autocaptured touch, or anything else.
They are set using posthog.register, which takes a properties object as a parameter, and they persist across sessions.
For example:
JavaScript
posthog.register({
'icecream pref': 'vanilla',
team_id: 22,
})The call above ensures that every event sent by the user will include "icecream pref": "vanilla" and "team_id": 22. This way, if you filtered events by property using icecream_pref = vanilla, it would display all events captured on that user after the posthog.register call, since they all include the specified Super Property.
This does not set the user’s properties. This only sets the properties for their events. To store person properties, see the setting person properties section.
Super Properties are persisted across sessions so you have to explicitly remove them if they are no longer relevant. In order to stop sending a Super Property with events, you can use posthog.unregister, like so:
JavaScript
posthog.unregister('icecream pref'),This will remove the super property and subsequent events will not include it.
If you are doing this as part of a user logging out you can instead simply posthog.reset() which takes care of clearing all stored Super Properties and more.
You can completely opt users out from data capture by default or on a per-person basis. See Opt in/out for the current React Native API.
You can configure how many events queue before flushing with flushAt. Setting this to 1 will send events immediately and will use more battery. The default is 20.
You can also configure the flush interval with flushInterval, in milliseconds (default 10000), after which queued events are sent regardless of how many have been gathered:
JavaScript
const posthog = new PostHog('<ph_project_token>', {
flushAt: 20,
flushInterval: 10000,
})You can also manually flush the queue to start sending events immediately instead of waiting for the next batch:
JavaScript
await posthog.flush()If a flush is already in progress, it returns a promise for the existing flush.
Flushing is best-effort and asynchronous – it starts sending queued events in the background but doesn’t wait for the request to finish, so it isn’t a delivery guarantee.
To reset the user’s ID and anonymous ID, call reset. Usually you would do this right after the user logs out.
JavaScript
posthog.reset()The PostHog React Native SDK will continue to capture events when the device is offline. When persistence is set to file (by default), the events are stored in a queue in the device’s file storage. Even when the app is closed, the events are persisted and will be flushed when the app is opened again.
maxQueueSize in the configuration.By default, PostHog has tracking enabled unless it is forcefully disabled by default using the option { defaultOptIn: false }.
You can give your users the option to opt in or out by calling the relevant methods. Once these have been called they are persisted and will be respected until optIn/Out is called again or the reset function is called.
To opt in/out of tracking, use the following calls.
JavaScript
posthog.optedOut // See if a user has opted out
posthog.optIn() // opt in
posthog.optOut() // opt outIf you still wish capture these events but want to create a distinction between users and team in PostHog, you should look into Cohorts (opens in a new tab).
PostHog’s feature flags (opens in a new tab) enable you to safely deploy and roll back new features as well as target specific users and groups with them.
There are two ways to implement feature flags in React Native:
React Native
import { useFeatureFlag } from 'posthog-react-native'
const MyComponent = () => {
const booleanFlag = useFeatureFlag('key-for-your-boolean-flag')
if (booleanFlag === undefined) {
// the response is undefined if the flags are being loaded
return null
}
// Optional use the 'useFeatureFlagWithPayload' hook for fetching the feature flag payload
return booleanFlag ? <Text>Testing feature 😄</Text> : <Text>Not Testing feature 😢</Text>
}React Native
import { useFeatureFlag } from 'posthog-react-native'
const MyComponent = () => {
const multiVariantFeature = useFeatureFlag('key-for-your-multivariate-flag')
if (multiVariantFeature === undefined) {
// the response is undefined if the flags are being loaded
return null
} else if (multiVariantFeature === 'variant-name') { // replace 'variant-name' with the name of your variant
// Do something
}
// Optional use the 'useFeatureFlagWithPayload' hook for fetching the feature flag payload
return <div/>
}React Native
// Defaults to undefined if not loaded yet or if there was a problem loading
posthog.isFeatureEnabled('key-for-your-boolean-flag')
// Defaults to undefined if not loaded yet or if there was a problem loading
posthog.getFeatureFlag('key-for-your-boolean-flag')
// Multivariant feature flags are returned as a string
posthog.getFeatureFlag('key-for-your-multivariate-flag')
// Optional: fetch the payload (returns 'JsonType' or undefined if not loaded yet or if there was a problem loading)
posthog.getFeatureFlagResult('key-for-your-multivariate-flag')?.payloadYou can inspect all currently loaded feature flags with getAllFeatureFlags(). It returns each flag’s key, enabled state, variant, and payload, and does not send a $feature_flag_called event, so calling it won’t affect your experiment results or flag usage analytics:
React Native
for (const flag of posthog.getAllFeatureFlags()) {
console.log(flag.key, flag.enabled, flag.variant, flag.payload)
}Every time a user opens the app, we send a request in the background to fetch the feature flags that apply to that user. We store those flags in the storage.
This means that for most screens, the feature flags are available immediately — except for the first time a user visits.
To handle this, you can use the onFeatureFlags callback to wait for the feature flag request to finish:
React Native
posthog.onFeatureFlags((flags) => {
// feature flags are guaranteed to be available at this point
if (posthog.isFeatureEnabled('flag-key')) {
// do something
}
})PostHog loads feature flags when instantiated and refreshes whenever methods are called that affect the flag.
If want to manually trigger a refresh, you can call reloadFeatureFlagsAsync():
React Native
posthog.reloadFeatureFlagsAsync().then((refreshedFlags) => console.log(refreshedFlags))Or when you want to trigger the reload, but don’t care about the result:
React Native
posthog.reloadFeatureFlags()The React Native SDK caches feature flag values in AsyncStorage. Cached values persist indefinitely with no TTL until updated by a successful API call. This enables offline support and reduces latency, but means inactive users may see stale flag values from their last session.
For example, if a user last opened your app when a flag was false, that value remains cached even after you roll it out to 100%. When they reopen the app, the SDK returns the cached false first, then fetches the fresh true value from the API.
To ensure fresh flag values:
React Native
// Force refresh on app start
await posthog.reloadFeatureFlagsAsync()Or clear cached values for inactive users:
React Native
if (lastActiveDate < migrationDate) {
posthog.reset() // Clears all cached data
}You can configure the featureFlagsRequestTimeoutMs parameter when initializing your PostHog client to set a flag request timeout. This helps prevent your code from being blocked in the case when PostHog’s servers are too slow to respond. By default, this is set at 10 seconds.
React Native
export const posthog = new PostHog('<ph_project_token>', {
// usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
host: 'https://us.i.posthog.com',
featureFlagsRequestTimeoutMs: 10000 // Time in milliseconds. Default is 10000 (10 seconds).
})When using the PostHog SDK, it’s important to handle potential errors that may occur during feature flag operations. Here’s an example of how to wrap PostHog SDK methods in an error handler:
React Native
function handleFeatureFlag(client, flagKey, distinctId) {
try {
const isEnabled = client.isFeatureEnabled(flagKey, distinctId);
console.log(`Feature flag '${flagKey}' for user '${distinctId}' is ${isEnabled ? 'enabled' : 'disabled'}`);
return isEnabled;
} catch (error) {
console.error(`Error fetching feature flag '${flagKey}': ${error.message}`);
// Optionally, you can return a default value or throw the error
// return false; // Default to disabled
throw error;
}
}
// Usage example
try {
const flagEnabled = handleFeatureFlag(client, 'new-feature', 'user-123');
if (flagEnabled) {
// Implement new feature logic
} else {
// Implement old feature logic
}
} catch (error) {
// Handle the error at a higher level
console.error('Feature flag check failed, using default behavior');
// Implement fallback logic
}Sometimes, you might want to evaluate feature flags using properties that haven’t been ingested yet, or were set incorrectly earlier. You can do so by setting properties the flag depends on with these calls:
React Native
posthog.setPersonPropertiesForFlags({'property1': 'value', property2: 'value2'})Note that these are set for the entire session. Successive calls are additive: all properties you set are combined together and sent for flag evaluation.
Whenever you set these properties, we also trigger a reload of feature flags to ensure we have the latest values. You can disable this by passing in the optional parameter for reloading:
React Native
posthog.setPersonPropertiesForFlags({'property1': 'value', property2: 'value2'}, false)At any point, you can reset these properties by calling resetPersonPropertiesForFlags:
React Native
posthog.resetPersonPropertiesForFlags()The same holds for group (opens in a new tab) properties:
React Native
// set properties for a group
posthog.setGroupPropertiesForFlags({'company': {'property1': 'value', property2: 'value2'}})
// reset properties for all groups:
posthog.resetGroupPropertiesForFlags()Note: You don’t need to add the group names here, since these properties are automatically attached to the current group (set via
posthog.group()). When you change the group, these properties are reset.
Automatic overrides
Whenever you call posthog.identify with person properties, we automatically add these properties to flag evaluation calls to help determine the correct flag values. The same is true for when you call posthog.group().
Default overridden properties
By default, we always override some properties based on the user IP address.
The list of properties that this overrides:
This enables any geolocation-based flags to work without manually setting these properties.
Since there is a delay between initializing PostHog and fetching feature flags, feature flags are not always available immediately. This makes them unusable if you want to do something like redirecting a user to a different page based on a feature flag.
To have your feature flags available immediately, you can initialize PostHog with precomputed values until it has had a chance to fetch them. This is called bootstrapping. After the SDK fetches feature flags from PostHog, it will use those flag values instead of bootstrapped ones.
Pass bootstrap in the initialization options to seed identity and flag values:
React Native
<PostHogProvider
apiKey="<ph_project_token>"
options={{
host: 'https://us.i.posthog.com',
bootstrap: {
distinctId: 'distinct_id_of_your_user',
isIdentifiedId: true,
featureFlags: {
'flag-1': true,
'variant-flag': 'control',
},
},
}}
>
<MyComponent />
</PostHogProvider>See bootstrapping Feature Flags (opens in a new tab) for server-side evaluation and flag lifecycle, and SDK bootstrapping (opens in a new tab) for cross-SDK identity behavior.
If you evaluate feature flags outside the SDK – for example on your own server with posthog-node local evaluation (opens in a new tab), then pass the results into your app – you can have the SDK use those values and never fetch flags itself.
Set disableRemoteFeatureFlags: true so the SDK never requests /flags (including the refetches that identify(), group(), and reset() normally trigger), then push your evaluated flags at runtime with updateFlags(flags, payloads?, { merge }):
React Native
const posthog = new PostHog('<ph_project_token>', {
host: 'https://us.i.posthog.com',
// Don't fetch or evaluate flags on-device – we supply them ourselves.
disableRemoteFeatureFlags: true,
// Optional: values that must be available at startup, before updateFlags() runs.
// Without this, reads return their not-loaded defaults until you push flags.
bootstrap: {
featureFlags: { 'my-flag': true },
featureFlagPayloads: { 'my-flag': { color: 'blue' } },
},
})
// Later – e.g. after login, once your backend has evaluated flags for this user:
posthog.updateFlags(
{ 'my-flag': true, 'my-variant-flag': 'test' },
{ 'my-flag': { color: 'blue' } }
)
posthog.getFeatureFlag('my-variant-flag') // 'test'
posthog.getFeatureFlagResult('my-flag')?.payload // { color: 'blue' }updateFlags replaces the stored flags by default; pass { merge: true } to merge into the existing set instead. Values persist across app restarts, and getFeatureFlag() / getFeatureFlagResult() read them back like any other flag.
Note that reset() (called on logout) clears the supplied flags, so re-push them with updateFlags() after the next identity change. Use bootstrap for any flag values that must be available at startup before updateFlags() runs.
Since experiments (opens in a new tab) use feature flags, the code for running an experiment is very similar to the feature flags code. See adding experiment code (opens in a new tab) for React Native examples.
It’s also possible to run experiments without using feature flags (opens in a new tab).
Group analytics allows you to associate the events for that person’s session with a group (e.g. teams, organizations, etc.). See Group Analytics (opens in a new tab) for implementation details.
Note: This is a paid feature and is not available on the open-source or free cloud plan. Learn more on the pricing page (opens in a new tab).
To set up error tracking in your project, see the error tracking docs (opens in a new tab).
The JavaScript-level autocapture only covers exceptions thrown in your JS/TS code. To also capture native iOS and Android crashes – for example, a crash inside a native module or the platform runtime – install the optional @posthog/react-native-plugin package and enable errorTracking.autocapture.nativeCrashes. Native capture is gated by your project’s Enable exception autocapture setting, and crash reports need native debug symbols uploaded at build time to produce readable stack traces.
Follow the React Native installation guide (opens in a new tab) for the full setup, and native crash symbolication (opens in a new tab) to upload symbols.
You can use the PostHogErrorBoundary component to capture React rendering errors thrown by components:
React Native
import { PostHogProvider, PostHogErrorBoundary } from 'posthog-react-native'
import { View, Text } from 'react-native'
const App = () => {
return (
<PostHogProvider apiKey="<ph_project_token>">
<PostHogErrorBoundary
fallback={YourFallbackComponent}
additionalProperties={{ screen: "home" }}
>
<YourApp />
</PostHogErrorBoundary>
</PostHogProvider>
)
}
const YourFallbackComponent = ({ error, componentStack }) => {
return (
<View>
<Text>Something went wrong!</Text>
<Text>{error instanceof Error ? error.message : String(error)}</Text>
</View>
)
}The fallback prop accepts a component to render when an error occurs. The additionalProperties prop lets you add custom properties to the captured error event.
Duplicate errors with console capture
If you have both PostHogErrorBoundary and console capture enabled in your errorTracking config, render errors will be captured twice. This is because React logs all errors to the console by default. To avoid this, set console: [] on errorTracking.autocapture (for example, errorTracking: { autocapture: { console: [] } }) when using PostHogErrorBoundary.
You can use the before_send callback to modify, filter, or suppress exception events before they are sent to PostHog. This is useful for:
React Native
const posthog = new PostHog('<ph_project_token>', {
host: 'https://us.i.posthog.com',
before_send: (event) => {
if (event.event === '$exception') {
const exceptionList = event.properties?.['$exception_list'] || []
const exception = exceptionList.length > 0 ? exceptionList[0] : null
if (exception) {
// Add custom properties
event.properties['custom_property'] = 'custom_value'
// Override fingerprint for custom grouping
event.properties['$exception_fingerprint'] = 'MyCustomGroup'
}
// Suppress specific exception types
if (exception?.['$exception_type'] === 'IgnoredError') {
return null // Drop the event
}
}
return event
},
})You can also use before_send to sample or filter other event types. See the JavaScript Web SDK documentation (opens in a new tab) for more examples.
To set up logs (opens in a new tab) in your React Native app, follow the React Native logs installation guide (opens in a new tab). The SDK exposes posthog.captureLog, posthog.logger.{trace,debug,info,warn,error,fatal}, and posthog.flushLogs for sending structured records to PostHog Logs.
Minimum version:
posthog-react-native@4.44.0or later.
To set up session replay (opens in a new tab) in your project, all you need to do is install the React Native SDK and the Session replay plugin, then follow the instructions to enable Session Replay (opens in a new tab) for React Native.
To set up surveys, follow the additional installation instructions for React Native (opens in a new tab). Surveys launched with popover presentation (opens in a new tab) are automatically shown to users matching the display conditions (opens in a new tab) you set up.
Note: URL and CSS selector targeting are not supported in React Native. Surveys that rely on these conditions will not appear.
The React Native SDK can register a device for Workflows (opens in a new tab) push notifications and capture when a user opens one. For setup, including automatic and manual registration, capturing opens, opting out, and identity verification, see Push notifications (opens in a new tab).
If you’re not seeing the expected events being captured, the feature flags being evaluated, or the surveys being shown, you can enable debug mode to see what’s happening.
You can enable debug mode by setting the debug option to true in the PostHogProvider options. This will enable verbose logs about the inner workings of the SDK.
React Native
<PostHogProvider
debug={true}
apiKey="<ph_project_token>"
options={{
host: "https://us.i.posthog.com",
}}
>You can also call the debug() method in your code.
React Native
posthog.debug()You may want to disable PostHog when working locally or in a test environment. You can do this by setting the disable option to true when initializing PostHog. Helpfully this allows you to continue using usePostHog and safely calling it without anything actually happening.
React Native
// App.(js|ts)
import { usePostHog, PostHogProvider } from 'posthog-react-native'
...
export function MyApp() {
return (
<PostHogProvider apiKey="<ph_project_token>" options={{
// Disable PostHog in development (or whatever other logic you choose)
disabled: __DEV__,
}}>
<MyComponent />
</PostHogProvider>
)
}
const MyComponent = () => {
const posthog = usePostHog()
useEffect(() => {
// Safe to call even when disabled!
posthog.capture("mycomponent_loaded", { foo: "bar" })
}, [])
}V1 of this library utilised the underlying posthog-ios and posthog-android SDKs to do most of the work. Since the new version is written entirely in JS, using only Expo supported libraries, there are some changes to the way PostHog is configured as well as actually calling PostHog.
For iOS, the new React Native SDK will attempt to migrate the previously persisted data (such as distinctId and anonymousId) which should result in no unexpected changes to tracked data.
For Android, it is unfortunately not possible for persisted Android data to be loaded which means stored information such as the randomly generated anonymousId or the distinctId set by posthog.identify will not be present. For identified users, the simple workaround is to ensure that identify is called at least once when the app loads. For anonymous users there is unfortunately no straightforward workaround they will show up as new anonymous users in PostHog.
Events such as Application Installed and Application Updated that require previously persisted data were unable to be migrated, the side effect being that you may see much higher numbers for Application Installed events. This is due to the fact that there is no native way of detecting a real “install” and as such, we store a marker the first time the SDK loads and treat that as an install.
JSX
// DEPRECATED V1 Setup
import PostHog from 'posthog-react-native'
await PostHog.setup('<ph_project_token>', {
// usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
host: 'https://us.i.posthog.com',
captureApplicationLifecycleEvents: false, // Replaced by 'PostHogProvider'
captureDeepLinks: false, // No longer supported
recordScreenViews: false, // Replaced by 'PostHogProvider' supporting @react-navigation/native
flushInterval: 30, // Stays the same
flushAt: 20, // Stays the same
android: {...}, // No longer needed
iOS: {...}, // No longer needed
})
PostHog.capture("foo")
// V2 Setup difference
import PostHog from 'posthog-react-native'
const posthog = await Posthog.initAsync('<ph_project_token>', {
// usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
host: 'https://us.i.posthog.com',
// Add any other options here.
})
// Use created instance rather than the PostHog class
posthog.capture("foo")
// V3 Setup difference
import PostHog from 'posthog-react-native'
const posthog = new PostHog('<ph_project_token>', {
// usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
host: 'https://us.i.posthog.com',
// Add any other options here.
})
// Use created instance rather than the PostHog class
posthog.capture("foo")
// V4 Setup difference
import PostHog from 'posthog-react-native'
const posthog = new PostHog('<ph_project_token>', {
// usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
host: 'https://us.i.posthog.com',
// captureAppLifecycleEvents is enabled by default since version 4.39.0 (previously named `captureNativeAppLifecycleEvents` or `autocapture={{ captureLifecycleEvents: true }}`)
// captureMode: 'json', // No longer supported
// maskPhotoLibraryImages: true, // No longer supported
})
posthog.setPersonPropertiesForFlags(...) // instead of `personProperties`
posthog.setGroupPropertiesForFlags(...) // instead of `groupProperties`Ask PostHog AI
HelpfulCould be better
This file