Skip to content
Everee · Mobile · 2020

Putting my own skepticism to the test.

I had already moved one company off a hybrid mobile framework. When the technology changed, I ran a structured evaluation and de-risked the decision with a proof of concept. Then I moved a payroll app from two native codebases to one in React Native.

My role
Ran the evaluation, made the case, led the migration
Timeline
Evaluation in 2020, migration Aug to Nov 2020
Stack
React Native, Expo, Swift, Kotlin, Sentry
Shipped
October 20, 2020

The situation

Everee’s mobile app was two native codebases. I built the Swift app for iOS from the first commit, and a contract engineer I managed built the Kotlin app for Android. I was responsible for keeping both at feature parity and getting them through the app stores.

With the React web app alongside them, every feature was planned, scoped, and built three times, then kept in sync by hand. iOS and Android drifted apart on features, and keeping three implementations in sync was a constant cost.

Why I was skeptical

I’d been burned by cross-platform tools twice. A university independent study on location-aware cross-platform apps taught me how brittle and hard to debug those frameworks were. At InMoment, our app started as a PhoneGap hybrid that proved just as bug-prone, and I moved it to native Swift and Kotlin.

I didn’t come to React Native as a believer. I came to it with a list of the ways the last two frameworks had failed me.

Autolinking changed my mind enough to look again. It removed most of the native-module linking and build pain I had hit before.

The decision

I ran a feasibility evaluation first, then a proof of concept aimed squarely at the places cross-platform apps had broken for me before.

What the proof of concept had to prove
  • Authentication
  • Authorization
  • Network transport
  • Caching
  • State management
  • Navigation

It passed, and I came back with a positive recommendation. Right as I finished, our contract Android engineer moved on. Rather than backfill a native Android role, I made the case to go all in on React Native. That meant one codebase, and a stack our web engineers could share. Leadership approved.

The migration

I built the foundation first: stack and drawer navigators, a company picker, avatar menus, a date range picker, and a shared button. Then I ported the app one area at a time, so each slice could be checked against the native version it replaced.

  1. 1 · Login
  2. 2 · Profile
  3. 3 · Earnings
  4. 4 · Payments
  5. 5 · Time
  6. 6 · Time off
  7. 7 · Time clock

Along the way I wired in analytics, Crashlytics, in-app messaging, remote config, push notifications, and Sentry. I also built the handling for finished Expo builds. The work ran 24 stories across two epics and shipped in October 2020.

The outcome

  • One codebase shipped to both iOS and Android, ending the parity drift.
  • A smaller team could own mobile. I onboarded our web engineers and taught them React Native, so they could contribute to the app.
  • Expo, adopted during the migration, later made over-the-air updates possible. I went on to own every Expo upgrade that followed.
What I took from it

Strong opinions are worth re-testing when the facts change. A proof of concept aimed at your own doubts is the fastest way to find out whether you’re still right.