How We Picked A Mobile App Framework

Picking a Mobile App Framework

Picking a Mobile App Framework

Note: This is part two in a series.  Part one is here.

There’s no shortage of ways to build a mobile app these days. HTML5 is on the upswing (again), and quasi-native frameworks are popping up almost as often as Javascript libraries.

Here at Contactually, we wanted to take the time to re-evaluate all of the current leaders in the mobile app framework space to give us the most bang for our buck. We were looking for the framework that gave us:

  1. Longevity – we don’t want to have to write from scratch again
  2. Interoperability – we have a dev team of very talented Ruby and web developers that we’d like to use across teams if possible. This also ensures that the mobile devs would be able to troubleshoot anything that goes wrong with our API
  3. Hirability – we want to make sure that we don’t pick a language that’s too specialized, which would make it hard to make any experienced hires (or experienced hires prohibitively expensive)
  4. Developer Happiness – writing for mobile shouldn’t be a burden; we want to pick a language and framework that makes the most sense to the most developers

In this search we looked at several mobile app frameworks, but ended up prototyping with three frameworks based on our initial research:

  • Swift 2.0 – The truly native choice. It’s the only one that we looked at that’s sponsored (and actively promoted) by Apple
  • ReactNative 0.12.0 – Facebook’s newly-published framework that brings React to the native environment, complete with bindings
  • RubyMotion 4.4 – Commercial product that allows you to write in Ruby and compile down to App/Play Store executables

The goal of these prototypes was to get a feel for what it would be like to be writing in these languages/frameworks every day, and to get a better feel for the ecosystems that surround them. A language with lots of available talent is great, but not if that talent dislikes working on it every day. In a similar vein, just because we could write some code once and deploy it to multiple places doesn’t mean that we can do all the things in all the places and might end up with our hands tied after getting out any more than the standard TODO app. To really understand the limits of these candidates (and if you’ll realistically hit them), we had to try to build the same non-trivial thing in the same timeframe. In our examples, we built apps that would log in a user and pull down their current task list. Not super hard, but enough to demonstrate the utility of each option.

Swift 2.0

The Good:

  • Official Apple
  • Much easier to work with than Objective-C, and faster too
  • Large repository of common components via Cocoapods and Carthage
  • Most commonly-used framework of those examined
  • Lots of established patterns, large developer community

The Bad:

  • Leads to siloing of developers, not many are Ruby/Swift/Javascript devs
  • Requires use of Xcode, which is often buggy and crashes, hurting productivity

The Ugly:

  • No native support for components, Cocoapods is not official
  • “Just enough to be annoying and break things” changes between 1.2 and 2.0
  • Swift upgrade forced with operating system

For the always-important smell test, here’s what it looks like:

ReactNative 0.12.0

The Good:

  • Sponsored by a large company (Facebook)
  • Write once, deploy everywhere – the siren song of developers everywhere
  • Components are just NPM modules

The Bad:

  • Completely new way of thinking about interfaces coming from JQuery/Backbone/Marionette
  • Very much pre-1.0
  • JS framework, could shift dramatically and quickly
  • No real established best practices

The Ugly:

  • Android support only added recently (~1 month at time of writing)
  • Few people with experience writing in it

Show me the code!


The Good:

  • Writing in Ruby, same as the backend
  • Can reuse common model code
  • Super helpful community
  • Established best practices
  • Cross-platform from the model/network layer
  • Can leverage Cocoapods and other 3rd party Objective-C code*

The Bad:

  • Smallest sponsoring group
  • Could become invalid for the App Store at Apple’s decision
  • Only paid solution ($199/year)

The Ugly:

  • Few people have used it before
  • Can use Cocoapods, but requires bindings*

*RubyMotion doesn’t actually require bindings, you can use any Objective-C library, though you’ll probably want to write a wrapper to make it more “rubyish” like the rest of your app, thanks @MarkVillacampa!

Give me a sample:

And now, as slides!

Here at Contactually we have long-term planning sessions every two weeks to highlight a certain portion of our engineering effort and solicit thoughts/reactions on how we plan on moving that section forward. At a recent meeting we presented the above via a quick set of slides followed by some code walkthroughs. Feel free to use these as the basis of your own planning, we’d love to hear your experiences if you try something similar!

Our (Not Yet Made) Decision

Given React Native’s pre-1.0 status and only ~20 days of Android support as of this writing, we eliminated it from consideration first, even though we think it has tremendous promise.  We’re currently weighing the Swift-vs-RubyMotion decision.  Have thoughts?  Comment away!

We’ll come back with our final decision in part three of this series.

The following two tabs change content below.

Jonathan Bender

Full stack engineer working primarily on APIs and the integration of remote systems into Contactually.

Latest posts by Jonathan Bender (see all)


  1. Have you considered Xamarin? It works fairly well with high code reuse between iOS, Android, & Windows/Windows Phone.

    • Hey there Chris, we did look at Xamarin a bit, but found it to not be a great fit for our team. Everyone here is a full stack/Ruby developer and we wanted to keep the barriers between the apps as low as possible if we were going to opt in to a non-traditional solution. Having everyone learn a new language didn’t feel the best way to do that, even if it does allow for greater code reuse. Instead we weighed our options based on what we know and can get out the door as soon as possible without retraining or new hires that would have to learn our codebase if not the language. This decision is one that I think you should make for your own team, as everyone has different requirements/specialties available to them, YMMV.

  2. Hi, How about Qt5/Qml? Check out the apps at, all in QML with some bits of native code.

    • Hey there Vlad, I’ll admit that we didn’t initially explore Qt5, but after taking a look at the docs I’d have to conclude about the same as what I said to Chris, which is that Qt represents too much of a departure from what our team normally builds on. While a robust solution, it also seems to require a lot of setup to get the ball moving, which makes it less appealing as a group looking to set a foundation quickly and iterate from there. The technology does look pretty cool though, and I’ll definitely try building something on it sometime in the near future as an experiment. Thanks for the heads up!

  3. Hi, which tool you finally choose. And how is it going?

    • Hi there Jialei,

      We ended up going with RubyMotion, largely because it’s a language that our entire team is familiar with and because it has an awesome community around it that was super helpful whenever we had any questions. The decision is panning out very well so far, with v3.0, 3.1, and 3.1.1 all released in the App Store. We’ve also been able to publish a few updates to the many community gems and even created one of our own to improve the testing suites available. We hope to write up a fuller post on our experience in the future, but have been a bit busy publishing the v2 of our API (stay tuned for more on that soon!).



Submit a Comment

Your email address will not be published. Required fields are marked *