React Native Android Launch

Yesterday, we launched our updated Tasker app to our Android community. As noted before on the iOS launch, this is the app that Taskers use to get their work done. This completes our migration to React Native.

All of the credit goes to the team that made this happen, especially JR and Jeremy. It was a lot harder than expected to get everything working on both platforms and they showed great dedication and persistence.

Approach

The goal of the last release was for the iOS users to not even notice. Mission (more or less) accomplished! However, for this one, it didn’t make sense to fork the code by platform without a good reason. So admittedly, the app looks more like an iOS app and than an Android one. However, we did go screen by screen looking for places where Android-specific attention would help the user.

Differences

I’ll let JR do a followup to his previous post of all the differences, but the biggest ones in my mind were the handling of the hardware back button and different pickers (date, for example) in the forms. The Platform directory strategy we had put in place during the first cycle worked out pretty well.

We also really struggled with getting push notifications right. This is key for our business and there were many more nuances on the Android platform to work out. We hope to publish what we came up with.

Of course, there was also the more extensive testing to do. Our Android pile:

Stats

• App Javascript: 302 files with 21515 lines of code
• Test Javascript: 47 files with 5708 lines of code
• iOS Javascript: 19 files with 449 lines of code
• Android Javascript: 19 files with 770 lines of code
• Objective C: 17 files with 885 lines of code
• Java: 15 files with 912 lines of code
• iOS Config files: 18 files with 2538 lines of stuff
• Android Config files: 16 files with 1106 lines of stuff
• React Components: 124
• Screens (addressable url patterns): 25
• Avg. components per screen: 5
• Dispatcher Events: 55
• Shared JS (vs. Platform JS) percentage: 94%
• JS (vs. Native ObjC/Java) percentage: 92%
• Total shared code percentage: 87%
• Total shared (including config) percentage: 75%

Next steps

Now, we certainly didn’t do this engineering project because the tech was cool (even though it is). We did it to create a foundation that allows us to deliver value more effectively to our community. So that’s the next order of business. Time to get rolling! I estimate that we can ship features to both platforms at least twice as quickly with half the engineers than we had before.

Too long, but did read anyway: For you execs out there that somehow read this far (even past lines of code counts!), I’d say that we’ve found React Native to be at least 5x more productive than traditional mobile development.