October 16, 2015
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:
In this search we looked at several mobile app frameworks, but ended up prototyping with three frameworks based on our initial research:
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.
The Good:
The Bad:
The Ugly:
For the always-important smell test, here's what it looks like:
The Good:
The Bad:
The Ugly:
Show me the code!
The Good:
The Bad:
The Ugly:
*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:
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
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.