ZeeMee Engineering and the Quest for the Holy (Mobile Dev) Grail
Update (Sept 26, 2016): We’ve now completed the “holy grail”, and it’s been great! iTunes review times are much shorter now (usually about 1 day) and so over-the-air updates are less critical, but still really nice to have as an option.
Free image courtesy of Wunderstock.
We want to streamline our mobile development, integration, and deployment to be as easy to use as our web development workflow. We have identified tools and technologies that allow mobile development to have similar iteration, feedback, and deployment cycles as is the norm for web development.
Web dev tools are streamlined
For our web app, we have a nice Continuous Integration system in place that roughly goes like this:
- A good branching/review model that scales well and is repeatable
- Commits to staging, if tests pass, are pushed live to a staging environment on Heroku via CodeShip
- Features are reviewed in staging and accepted or rejected from Pivotal Tracker
- Once accepted, the code is fair game for going to production. We push to production several times per week
##Mobile dev is more tedious But, for mobile dev, it’s traditionally a lot less streamlined:
- CI tools are less developed and established
- Best practices are harder to pin down
- The mobile dev environment is less prone to rapid development and deployment due to compiled languages
- There is pain in distributing builds to test devices and testers
- And the dreaded wait for the iOS app store review process
##Mobile Dev Holy Grail
- But, there is hope! There are tools available to address the various pain points associated with mobile development. At ZeeMee, we are working towards the Holy Grail of Mobile Development:
- Fast feedback while developing mobile apps
- Shared code between iOS and Android without sacrificing UI/look/feel
- Ability to run tests on every commit
- Ability to deploy changes to staging devices rapidly and frequently
- Ability to push updates directly to mobile clients without going through the app store review process
##Fast feedback while developing mobile apps
Our status: Done
To address this, we’ve drunk the Facebook Kool-Aid and made the switch to React Native . We had already tested React Native in production for a couple months by using it for a few of the features/screens in our iOS mobile app. While there was some pain, overall it’s been a great experience . You can make changes by simply refreshing the app without having to recompile and rerun. We have lots of praise for React Native, but I’ll save that for another blog post (and checkout the Silicon Valley ReactJS Meetup where we discuss some lessons learned)!
##Shared code between iOS and Android Facebook claims that React Native is “learn once, write anywhere” instead of “write once, run anywhere”. But, in practice, our iOS React Native code mostly “just worked” on Android. Some of the components needed to be reworked for layout . And, these are fully native UI components, this isn’t a web-view-wrapper around HTML and CSS, so the user experience is very good.
##Ability to run tests on every commit
Our status: Done
I spent a lot of time researching CI options for mobile dev. A list of tools I explored include: XCode bots running on a Mac Mini at our office, Bitrise, BuddyBuild, CircleCI for mobile, Jenkins on Mac, and Fastlane (not CI, but helper tools).
Ultimately we ended up using Bitrise and have been pretty happy with it. It works like you’d expect hosted CI to work. It has some nice pre-built steps specific to building for mobile (increment build numbers, signing with various provisioning profiles, etc). It also has nice features around workflows, reusing different pipelines, etc. Support is also accessible via their slack team.
##Ability to deploy changes to staging devices rapidly and frequently
Our status: Done
There are several tools available to help you push staging builds of your iOS apps to test devices. I looked at TestFlight, HockeyApp, Crashlytics Beta, and also evaluated Bitrise’s built-in option. Ultimately we decided to use Crashlytics Beta.
TestFlight has a unique advantage in that you can test the exact same archive that you later offer to the public via the app store. So you can “Train Like You Fight.” But, it takes a long time to process and delivery the app OTA compared to Crashlytics.
Crashlytics Beta was a good choice. It’s easy to get test devices set up, and we already use Crashlytics for collecting mobile app crash data. HockeyApp and Bitrise’s option probably also work fine. When a commit is merged to staging branch, tests are run and Bitrise pushes the build to our test phones via Crashlytics Beta automatically. We can then review, and accept or reject the stories as they are completed.
##Ability to push updates directly to mobile clients without going through the app store review process
Our status: Done
After stories are accepted in the staging environment, we push commits to a preproduction branch, where Bitrise builds a production version of the app and again pushes it to our test phones via Crashlytics. We treat these as “release candidates” and might make changes after rigorously testing the app with full regression testing (we’re thinking about plugging in Applause or RainForest QA external testing at this stage, but for now we test in-house).
There are some really good tools available to make mobile development easier and faster. There are various good options, and we’re happy with the choices we’ve made — they’ve allowed us to move much more quickly on our mobile products.