React Native Tracking

Anyone have luck setting-up a Snowplow tracker within React Native?

We use Snowplow for our web applications and are looking for tracking within our mobile app but coming-up empty. We don’t want to go with an alternative like Segment but it seems like that might be the only reliable choice.

So far, we’ve seen:

  • This unofficial snowplow-react-native library. It is not maintained by Snowplow and hasn’t seen activity since 2017.
  • This react-native-snowplow library from Datacamp which only has 10 commits.
  • This (abandoned?) library on npm

After reading through this issue in Snowplow’s GitHub repo, the official recommendation seems to be to use their snowplow-nodejs-tracker library. This is also not promising — this package seems totally unmaintained, and the last commit was back in 2017.

This comment on a related GitHub PR seems to imply that snowplow-nodejs-tracker won’t work at all with React Native, because that library does not use axios

Hi @tfinkel!

We do have our own React Native tracker in our incubator project, but we’re aware of issues with it. It worked when we built it, but something has changed in the interim and we’re trying to figure out what.

We will be focussing on this more in the next quarter or two and are bringing in more expertise to support the push to making this a fully functional tracker.

Thanks @stevecs , that is helpful. Does this mean the tracker doesn’t work at all right now, or just that some folks have issues with it?

Hey @tfinkel,

I’m actually in the middle of digging into this. It definitely works (100% confirmed for iOS, untested for android but high degree of confidence), but in its current iteration it needs a lot of manual configuration & can be painful. The readme as it stands doesn’t look like it covers everything required (I hope to update this once I’m on top of it).

One of the causes of this is that react-native and react-native-cli updates have introduced breaking changes to how to automatically import it. I’ve not yet verified it for RN 0.60.x but I suspect there will be a bit of work in updating it for that, since native module imports have changed in that release.

We’d welcome contributions and suggestions on how to go about improving it, especially from people who know their way around react native - for now we’re keen to get the current functionality into a stage where it’s as automatic and easy to use as possible.

Even reporting back any issues you face in trying to use it would be really helpful to us at this point.

It’s in early stage development but having navigated some of the complexities I’m feeling confident in the outlook for the tracker once we get it into shape. (I’m not the one to say how that’s roadmapped, but it looks feasible to eventually land in a place where all the functionality of the native mobile trackers are available).

Here’s a dump of my notes on steps to get it running in for iOS for the demo app in the repo, hopefully that’d be a good starting point towards getting it sorted for another project:

From the DemoApp folder:

npm install
npm audit fix (this may not be necessary but it’s a good idea regardless - the next version of the tracker should update the package.json)
cd ios && pod install (may not be necessary in all cases)

The above steps ensure that all dependencies are present. However the Xcode project may not have the dependencies linked correctly (there’s been a change to how linking is handled in the cli since the tracker was built, so using the react-native method of autolinking appears not to work).

xed DemoApp.xcodeproj/ to open the project in xcode.

Navigate to DemoApp > Targets - DemoApp > Build Phases > Link Binary with Libraries

Everything in there should be a framework. Remove all the files, then + and Add Files in the drop down.

Add DemoApp/ios/Pods/Pods.xcodeproj .

Add all the frameworks that aren’t there already (I’m assuming all are necessary, yet to test what might be stripped out).

Once you’ve done that, your project should build on cmd+B . If you’re using Xcode < 11, I believe you should also be able to run with cmd+R or react-native run-ios from the DemoApp folder (I’m on Xcode 11 so I haven’t verified this - let me know if it doesn’t).

However Xcode11 introduced a bug which was fixed in the next version of react native, so if you’re on Xcode11, you’ll need these additional steps:

  • Bump the react-native dependency in package.json to ^0.59.9 (I’m yet to test any later versions)
  "dependencies": {
    "@snowplow/react-native-tracker": "0.1.0-alpha.9",
    "react": "^16.8.3",
    "react-native": "^0.59.9"
  • From the DemoApp folder, rm -rf node_modules && npm install

react-native run-ios should now run successfully and send data. (It’s best to terminate the metro server & iOS simulator first, and perhaps to clean the build in xcode with cmd+opt+k to ensure a clean build from first principles).

Thank you so much @Colm ! I personally do not know my way around React Native, but I will share this with the engineers on my team and share our findings here.

:+1: Hope it’s helpful, I’d prefer to be showing you a much smoother experience but we’ll get there!

Yeah any feedback your team might have would be appreciated. :slight_smile:

thanks for your help here @Colm.

@tfinkel and i are teammates - we have this working on iOS for react native 0.61. the only thing blocking our android build is something that it appears you’re in the process of fixing within AndroidManifest.xml (

do you have a sense for when you expect that branch will be merged in?

thanks again!

1 Like

I’m working on the PR at the moment, just have some cleanup to do and will merge once I have it in a nicely auditable shape.

I’ve already published a new alpha version to npm (0.1.0-aplha.12) - it’s tagged as latest. You should be able to use it now & Andorid should build out of the box.

On the ios side, the latest alpha now works close to out of the box - if you add use_frameworks! to your app’s Podfile and pod install from the ios folder it should then work too.

TBH I’m not 100% certain that manually changing the Android Manifest is a legitimate solution in the long term - for purposes of getting a functional alpha out the door it’ll do, but please do let me know if you know of a better way to handle that problem. :slight_smile:


amazing thanks for the help!

i’ll talk to the team and let you know if there’s a better way to handle that problem. for now this is great :slight_smile:

Hi @Colm,

We are doing React Native implementation and while going thought the code - I cannot see any mentions of Session Context, Lifecycle Events and Background/Foreground timeouts. Are they set somewhere? Or is it safe to assume that tracker just defaults to not setting them?


Hey @mbondarenko!

Currently, no these haven’t been added yet so the tracker will just default to not setting them.

The react native tracker is on the agenda for late Q2/early Q3- so we will be paying some attention to it soon.

If you’d like to create issues on the repo to log the request, we can see where we get to when it’s a focus.

If you’re keen to get those methods in the shorter term, I think we should be able to review a PR and push another alpha release before then. Happy to advise on it if that’s what you want to do. :slight_smile:


Thanks Colm! I’ll log a request to clarify approach to implementing these features and then create PR for that request.

1 Like