October 16, 2015

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

1. 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

1. 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)

1. 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!

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!

http://www.slideshare.net/JonathanBender/mobile-architecture-comparison

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.