PostHog in mobile fintech: what it can record

You want to know why people abandon onboarding at step three, right before finishing the document upload. For that you need to see the real session, not just an aggregate funnel that gives you the number but not the cause. The problem is that same screen might have an ID document photo, a bank account number, or a balance on screen, and "record everything" isn't an option at a fintech, it's a security incident waiting for someone to report it. The question that matters isn't what PostHog can measure, but what it can record without capturing what it shouldn't, and how much of that has parity on mobile, because not all of it does.

Session replay works on mobile, but it's not the same everywhere

PostHog's Session Replay is confirmed general availability on Android, iOS, React Native, and Flutter. It records screen recording, network requests, logs, and touches, and the most important masking guarantees are on by default: password inputs are always masked, no exceptions, and text inputs and images are masked by default on both iOS and Android. That default matters: someone has to consciously choose to reveal a field, not the other way around.

Each platform has its own fine-grained control. On iOS, accessibilityIdentifier = "ph-no-capture" blocks an element and ph-no-mask forces the opposite; in SwiftUI there are the postHogMask() and postHogNoMask() modifiers. On Android you use a tag or contentDescription = "ph-no-capture", with ph-no-mask applying to all children of the view, and in Compose the equivalents are postHogMask() and postHogUnmask(). React Native has maskAllTextInputs, maskAllImages, and the PostHogMaskView component. Flutter has maskAllTexts, maskAllImages, the PostHogMaskWidget widget, and something worth flagging: embedded native views are masked by default via maskAllPlatformViews.

That gives you an operating rule for KYC: text and images start out masked, so the real risk is in deciding what to unmask, not in remembering to hide each sensitive field one by one.

The two limits that change the risk analysis

Here's what a feature list doesn't tell you, and it's what matters most for a fintech. On iOS, SwiftUI, custom views, and WebViews only get recorded in detail if you enable screenshotMode, and the documentation itself warns about it: the screenshot can contain sensitive information, use it with caution. Without that mode, the replay stays in wireframe: less faithful, but safer by default. In an app with identity verification screens, deciding whether to enable screenshotMode on KYC screens is the central decision of the whole replay project, not a configuration detail.

The second limit is harder, and it applies differently depending on how the app is built: React Native and Flutter always record in screenshot mode, and it's not configurable. They don't have the wireframe fallback that native iOS and Android do. If the app is built in RN or Flutter, this fundamentally changes the risk analysis, because there's no way to degrade replay fidelity to gain safety by default; the decision instead becomes about carefully defining which screens get excluded from capture entirely. Worth checking versions before instrumenting: iOS SDK ≥3.6.0, Android SDK ≥3.4.0, and Android API ≥26.

Onboarding and activation, measured as a funnel

With what can be recorded settled, the rest is familiar ground. Product Analytics answers what people actually do in the product: trends, funnels, retention, paths, stickiness, and lifecycle on the same events, the layer we covered in our note on product analytics in PostHog. Funnels is the key piece here, because in any product flow more people start it than finish it, and that applies literally to an onboarding flow with identity verification: every step of document upload, selfie, or data validation is a measurable drop-off point, not a hunch. That discipline of deciding with data instead of intuition is what we laid out in our note on the measurement gate.

If the fintech has a B2B product, Group Analytics groups events by entity (organization, account) instead of by individual user, key when the person using the product day to day isn't the one who decided to buy it. It's a paid add-on, up to five group types per project, and there's a billing detail worth being clear on: once subscribed, billing applies to all identified events in the project, not just the ones carrying group properties.

Rolling out features gradually, without a redeploy

For a fintech, changing something in production without being able to switch it off instantly if it goes wrong is a risk not worth taking. That's what PostHog's feature flags are for: ship something to 1% of users, see what happens, and turn it off the moment something looks wrong, without a redeploy or a hotfix. Rollouts accept decimals with up to two places, from 0.01% to 33.33%.

On mobile there's an extra piece that matters because of network latency: bootstrapping, which loads flag values before the SDK finishes initializing. It's confirmed on web JS, React Native, iOS, Android, and Flutter, and it persists identity and flags on the device, so the app doesn't start blind while waiting for the first server response. One nuance: support for this configuration alongside local evaluation varies by SDK, so it's worth checking each platform's specific documentation before assuming the early exit works the same way everywhere.

Errors: useful, but no promise on status

Error Tracking has dedicated installation guides for iOS, Android, and React Native, captures exceptions across the stack, and turns them into prioritizable issues, each with the affected user's session replay and events attached. What needs to be said clearly: PostHog's documentation doesn't label this product as GA or beta on any platform, so it shouldn't be presented as finished without that caveat.

The limits are concrete. On iOS, system symbols and frames (UIKit, Foundation) don't get symbolicated, and Swift crashes show up as SIGTRAP without the real error message. On Android there's still no source code context attached to an exception, though the documentation says it's a planned feature. Minimum versions: iOS SDK ≥3.56.0, Android SDK ≥3.32.0 for error tracking remote config.

Surveys: the product's biggest parity gap

If there's one part of PostHog where mobile clearly lags behind web, it's Surveys. The documentation says it plainly: web has the most complete feature support, while mobile has limitations. What's missing on mobile but exists on web JS is substantial: URL targeting with regex or exact match, feedback-button-style surveys, partial response collection, cancel events, targeting by actions, and shuffling of questions and options. Auto-submit on answer selection reached React Native in version 4.26.0, but it's not on native iOS or Android according to the official support table. To target a survey right after a payment or a transfer, it's worth checking that table before promising the same behavior as on web.

Compliance: what's there, and what's still unclear

PostHog is SOC 2 Type II certified following an external audit, with the report covering controls through May 31, 2026, on an annual June to May cycle. It has a dedicated GDPR guide, a DPA available, and support for the right to be forgotten. For data residency in the European Union, PostHog Cloud EU is hosted on servers in Frankfurt.

The most interesting compliance data point for a fintech isn't about financial data: it's HIPAA. PostHog offers a BAA only on the Boost, Scale, and Enterprise plans, and explicitly excludes AI features from that coverage: PostHog AI and other AI features aren't covered by the BAA and shouldn't be enabled in organizations where any project processes protected health information. HIPAA is about health data, not financial data, so it doesn't apply directly here, but it's the clearest signal that AI features get a different compliance treatment than the rest of the product. It's worth treating as a precedent before assuming PostHog AI runs under the same guarantees as the rest of the platform in a regulated context.

On self-hosting: it exists, it's open source under the MIT license, and it installs with Docker Compose, but all paid-plan features are Cloud-exclusive, and PostHog is explicit that it offers no operating guarantees on self-hosted infrastructure, with no paid support or dedicated CVE patches. For a fintech with strict regulatory requirements, that combination is a decision to make with the compliance team at the table, not just the product team, which is exactly the kind of intersection between product, growth, and technology we discuss in this note.

And a name that changed: what used to be Max AI is now PostHog AI, a product analyst that lives inside the tool, answers in natural language about the project's data, and respects existing access controls, so it only sees what the person asking can see. Where assistance ends and autopilot begins is the distinction we cover in our note on self-driving mode.

Where to start

The order that makes the most sense for a mobile fintech: first, decide the masking policy on KYC and financial data screens, including whether to enable screenshotMode on iOS, accepting that on React Native or Flutter that decision is already made by the platform. Second, instrument Funnels across the full onboarding flow, from signup to the first transaction. Third, turn on Feature Flags with bootstrapping to ship changes gradually without depending on a redeploy. Fourth, add Error Tracking knowing it's neither GA nor beta according to the documentation, so it's worth treating it as a useful tool, not an SLA. Only after that, evaluate Surveys knowing the gap with web, and review SOC 2, GDPR, and the self-host policy with compliance before scaling to production with real user data.

Who this is for

This note is for product and data teams at a fintech with a mobile app who are already evaluating PostHog or have it installed and need to know, before turning on session replay or error tracking on sensitive screens, what's actually masked by default, what changes if the app is native or built in React Native or Flutter, and which parts of the product still don't have the same maturity on mobile as on web. It doesn't replace a formal compliance review or your own security audit, but it gives you the map of what to ask before that review.

This content was developed with AI assistance and reviewed by the Zenda team. The bad ideas are 100% ours.