RubyMotion Success Story: Contactually

A few months ago, the Contactually team decided to revisit their mobile experience, and to evaluate alternative means of developing the next version. In the end, they decided to build their app in RubyMotion. They did this for a variety of reasons, but they largely boiled down to familiarity with the language and available libraries (both Ruby and Cocoapods).

We sat down with Jonathan Bender, of Contactually, to discuss their experience building the app.

---

Can you give a brief introduction about what Contactually does?

Contactually is a tool for relationship management. We help our customers keep in touch with the people in their network that matter most to them and to follow up at the right time in order to stay top of mind or close more business.

What can users accomplish with the iOS app?

Our app enables our users to complete all their daily tasks on the go by bringing in their overdue tasks, reminders to follow up, and all their contact’s information straight to their dashboard. From there, users can navigate onto their contact’s profiles to view more information, log previous interactions, schedule future tasks, or write notes. We’ve also enabled editing of people’s buckets, a grouping mechanism in Contactually, to let people quickly adjust their followup frequencies and categorize their contacts on the go.

What background did you come from when you started to build the Contactually iOS app?

Contactually is primarily a Ruby shop, with our main application built in Ruby on Rails with a Backbone/Marionette front-end. Our team has experience in a variety of languages and frameworks, however, including PHP, Clojure(script), NodeJS, ReactJS, and AngularJS. We were looking for a language and framework that allowed our developers the ability to quickly jump between different portions of the stack to allow them to not only build the interface, but to ensure that the backend endpoints were available as well so that no one would be blocked by another teammate.

An earlier version of the Contactually iOS app was already available. Why did you decide to build the new version in RubyMotion instead?

Our earlier version of the iOS app was written in Objective-C, which created a bit of a divide between those who knew the language and the rest of the team (who were building out the API to support it). We recognized that the old app’s performance was struggling due to its architecture, and rather than simply rearchitecting it as it stood, we opted to take the opportunity to step back and build something we felt would be more sustainable for the team as a whole. We evaluated several options including Swift, ReactNative, and RubyMotion as we felt those were the strongest options available right now and eventually settled on RubyMotion as the best fit for us. We wrote a blog post about the selection process.

How did RubyMotion help accelerate your development?

Using RubyMotion we found 3 main advantages that helped us move quickly and ship the app within 3 months of start. First, we were able to leverage lots of community code. Not only could we use RubyMotion specific gems, but we were able to leverage Cocoapods as well. Between the two communities, we found few problems that no one had come across before. Secondly, the RubyMotion community was extremely receptive through both the official forums as well as the Motioneers Slack channel. There seems to be something about Rubyists, we may be few, but we’ll help each other out! Finally, familiarity with Ruby really helped. You have to make calls down to Objective-C functions every now and then, but for the most part when you do you wrap it in a ruby function and never look back. This had the added advantage of being able to onboard a new team member and have them pushing code to production within their first two weeks.

Did you take advantage of any third party gems or CocoaPods?

We used lots of gems and pods! We try to abide by the rule of “if you don’t have to write it yourself, don’t,” and trust that the community has run into the same problem, and work to improve the known solution if you find any weaknesses. We’ve open sourced our testing suite with motion-spec and have opened PRs against ProMotion and motion-support and hope that our patches serve others well. Also on our highlight reel are redpotion, motion-kit, and ProMotion-XLForm, which allowed us to move much faster than writing it ourselves. For CocoaPods we’re leveraging Google/SignIn, NewRelicAgent, and DeviceUtil to provide some more core add-ons like crash reporting and device information (model, OS, etc.).

What parts of RubyMotion development would you like to see improved?

Deploying to development/staging/production took a little bit of back-bending where we’re setting environment variables and uploading different builds to various places (e.g. QA needs the build to be for development in order to load it in the simulator, Apple needs the production build, and NewRelic needs the dsym for the production build). All doable, just a little disjoint at the moment. Also had to write a custom rake task to build for all the devices and OSes that should be baked in IMHO.

How did you get help when you ran into a stumbling block?

Aside from Googling for the error, I always have the Motioneers Slack open, and if no one knows there I generally go to the official forums or StackOverflow and try to phrase the question in a more “Objective-C” manner.

Are there any features or aspects of RubyMotion that you haven’t used yet but expect to look into in the near future?

Haven’t had a chance to look at the Android side of things, but we’re going to be looking to dig into that in Q2/3 of this year and while there have been some “growing pains” that I’ve heard about, I’m hoping that it’ll become more stable (along with bluepotion) and we’ll be able to replicate our success with the iOS app again with Android and even get some reuse of our back-end/networking code.