Picking a Mobile App Framework

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:

Longevity - we don't want to have to write from scratch again

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

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)

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

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

ReactNative 0.12.0

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!

RubyMotion

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!