Replay features mobile parity tracker-otron

[pauldambra]

We've got varying support for replay features across our SDKs and no one place to keep track of them.
Let's have this one place

(not all of these will make sense on all SDKs maybe)

feature	web	android	ios	RN	flutter	notes
debug properties on events	✅	[]	[]	[]	[]
log capture	✅	✅	✅	✅	[]
canvas capture	✅	N/A	N/A	N/A	✅	If you're using the canvaskit renderer on Flutter Web, you must also enable canvas capture
network call capture	✅	✅	✅	✅	[]	RN only on iOS
header/body capture	✅	[]	[]	[]	[]
remote masking config	✅	[]	[]	[]	[]
manual start/stop	✅	✅	✅	✅	✅
start on URL match	✅	[N/A]	[N/A]	[N/A]	[]
start on event	✅	✅	✅	[]	[]
sampling	✅	✅	✅	✅	✅
start on linked flag	✅	✅	✅	✅	✅
minimum duration	✅	PR	✅	[]	[]
maximum duration (24 hours)	✅	PR	✅	✅	[]
active idle tracking session rotation	✅	✅	✅	✅	[]
pause on URL match	✅	N/A	N/A	N/A	[]

[marandaneto]

@ioannisj do we have minimum duration on iOS?

[ioannisj]

@ioannisj do we have minimum duration on iOS?

No, but we do have max recording duration. Added it to the table above

[pauldambra]

i think i'm right in saying the web sdk is the most active at tracking user idleness to proactively rotate session id

[ioannisj]

On iOS session will be rotated or cleared if > 30mins passed from one user interaction to the next. User interaction here is when the user actively touches the screen and not any background app activity. In that sense I think iOS does some tracking on user idleness as well, so I would check that box?

[pauldambra]

@ioannisj

so I would check that box?

well, the "bug" we found on web was with apps where the user was active but that might not trigger the mutation observer e.g. a canvas game

so in the web we actively check for session expiry - e.g. we don't only wait for user activity but also check on a timer

that meant that we avoid a race condition where a couple of events/snapshots leak into the previous session as the web wakes up from idle

no idea if that's even applicable in mobile though

[ioannisj]

Not sure I completely understand the web bug you are describing, but this is how it roughly works on iOS:

• When a user lands on a screen that has ongoing animations or auto-refreshing content, it will trigger screen changes/mutations. These screen changes trigger snapshots to be taken (throttled to 1s)
• If the user doesn't actively interact with the screen (e.g no touches), then the session will expire after 30 mins, and session id will rotate. We are looking for active UI events/touches so that we filter out noise or passive activity that will generate a snapshot. So if a user remains idle on a screen that fires screen changes constantly, the session will still expire in 30 mins
• The moment the user interacts with the app (even if that doesn’t trigger a visual change), the inactivity timeout resets, and the session will then expire when it hits the maximum session length.

There's a small deviation from the UI events/touches rule above - When the user backgrounds the app and when the user foregrounds the app (i.e taps on the app switcher or home screen icon). In both cases, we consider this to be an explicit action on the app, so we'll mark it as a user activity.

• So user backgrounds the app -> last user activity is set -> 30 mins of inactivity remaining for future snapshots.
• User opens the app within those 30 mins -> last user activity is set -> user gets 30 more mins of inactivity for the same session.

I'd want to avoid using timers on mobile since they can be pretty heavy on performance. Based on the above, and assuming things work as intended, do you think we cover those edge cases you see on web?

[pauldambra]

so if we come back from background after 30 mins we would rotate session before emitting any events or snapshots?

[ioannisj]

Yeah, that should be the expected behavior but I'll double check with a shorter interval and get back to you here.

[ioannisj]

Pushed a small fix here

[pauldambra]

PostHog/posthog-js#2169