Why mobile SDK health monitoring matters
A mobile attribution SDK is one of those things that's either working or it isn't — and when it isn't, you usually find out the slow way: installs that never attribute, in-app events that never arrive, an app release that quietly shipped before the deep linking integration was finished. By the time the numbers look wrong, the cause is buried weeks back, in a build most of your users have already moved past.
SDK Health turns that guesswork into a single readout. It tells you, at a glance, whether your app's LinkForty integration is alive, which SDK version it's running, and whether anything needs attention — before a gap in your mobile attribution data costs you a campaign's worth of installs. It's the monitoring layer on top of the LinkForty mobile SDKs for React Native, Expo, iOS, Android, and Flutter.
SDK Health status at a glance
Open the SDK Health panel for a workspace and you get a clear integration status, derived from your install and in-app event data:
- Not installed — no install has ever been recorded. The SDK isn't reporting yet.
- Installed — installs are on record, but no in-app events have arrived in the last 7 days. The SDK is present but may not be sending events.
- Events flowing — at least one in-app event in the last 7 days. Everything's reporting as expected.
Alongside the status is the SDK inventory: every SDK and version actively sending events across your React Native, Expo, iOS, Android, and Flutter apps, with each one's event count and the last time it was seen. Because the inventory is built from the live event stream, the SDK version you're looking at is the one your users are actually running right now — not whatever was current when the app was first installed. This is what makes the readout a true monitor rather than a snapshot.
SDK version diagnostics with the Doctor
Run the SDK Doctor and each SDK in the inventory is graded against the latest published release of that package — npm for the React Native and Expo SDKs, GitHub releases for the iOS, Android, and Flutter SDKs:
- Current — you're on the newest SDK release.
- Recent — slightly behind, but fine.
- Outdated — far enough back that you're missing fixes and improvements; time to upgrade.
- Unavailable — the registry couldn't be reached for a verdict.
The Doctor also flags SDK version fragmentation — when more than one version of the same SDK is sending events at once, which usually means a partial rollout or stragglers stuck on an old build. Fragmentation is one of the quietest sources of inconsistent attribution, because different app versions can behave differently. Need a fresh verdict on demand? A re-scan busts the 24-hour cache and re-checks every package against its registry.
How SDK Health works
Health is derived purely from the timestamps already in your data — installs and in-app events — so there's nothing new to instrument and no performance cost to your app. The SDK identity that each SDK now reports with every event (its name and version) powers the inventory and the version grading; this is the same identity reporting that brought the iOS, Android, and Flutter SDKs to parity with React Native and Expo.
Everything is scoped strictly to your own workspace — you only ever see your organization's integration, never another tenant's. For a deeper look at how the readout is computed, see the SDK Health guide.
Get started with SDK Health and Doctor
SDK Health and the Doctor diagnostic live in your dashboard, per workspace — no setup required beyond having a recent LinkForty SDK installed (the versions that report SDK identity). Open the panel, read the integration status, and run the Doctor whenever you ship a new app version or want to confirm a release is reporting cleanly.
New to the SDKs, or want to verify your install and deep linking setup first? Start with the platform guide for your app — React Native, Expo, iOS, Android, or Flutter — then come back to SDK Health to watch your integration report in.