I was the lead mobile engineer for Earn.com. I started the project from scratch, using React Native to create a cross-platform mobile client for Earn.com. Over time, we brought in more developers to work on the mobile app, and I led the team up to the acquisition event. Earn.com was acquired by Coinbase in 2018.

As the team grew, I gravitated towards mobile DevOps as my primary role, managing the CI infrastructure and ensuring successful deployments. I developed advanced Fastlane automation for all deployment types, allowing for automated build, test, and delivery of binaries and OTA Javascript.

When the project started, react-native was at version 0.27 with bi-weekly release cycles. The alpha-ness of the framework was apparent, and many resources went into keeping up with breaking changes. Driven by the constantly changing stack, one of my major focus areas was creating a automated CI pipeline for code delivery.

One of the more challenging aspects about mobile development is the lack of good container support for the build process. Since iOS builds must be on OSX, and containerization of OSX is not mainstream, we had to use a local machine setup for Jenkins agents. I set up 5 OSX Agents for use with Jenkins, set up as follows:

Each machine had physical phones attached, and I wrote bash connector code to automatically deploy new binaries to the phones for quick local testing. In addition, I created a fork of a early-on react native integration testing library, cavy, which would allow our team to write integration tests that could be automatically deployed to the CI cluster.

We had two delivery mechanisms for new code - binary releases, and Codepush (OTA Javascript bundle update). I wrote code supporting an automated delivery for both release types using Fastlane. Delivery builds were triggered by a manual job in Jenkins, running test, build, and validation of products, before uploading to the respective app stores.

Having a local Fastlane architecture allowed me to take the deployment code to Jenkins agents fairly easily. The biggest hurdle I faced in repeatability was lack of build environment containerization. This meant lots of local work to keep the CI machines up to date and running the same versions of all the build tools.

You can read more about my approach to React Native DevOps and Delivery in my Medium series, React Native DevOps Guide.

The app's goal was to be a mobile client for the 21.co web interface. All of the major features of the web were mirrored in the mobile app. We used a shared JS library between web and mobile to access and interact with the 21.co API.

App state was managed by react-redux, with async calls handled through redux-saga. Forms were written with redux-form. We used a lot of third party libraries to bring in feature support, like external OAuth providers, linking with major apps (Facebook, Twitter, LinkedIn), and device specific features.