Phonegap vs Rubymotion :

One Project, Two Methods

The research for this article is premised on our simple application that we've written in both PhoneGap and Rubymotion, called Chatoms.  The base concept of this application is fun enough to keep us developing it, but technologically simple enough to serve as an excellent example and exercise.

If you're not familiar with our Chatoms application, it's an app that provides you with simple conversation starters, so you can chat up a car ride or an outing with friends.  We've written several hundreds of conversation starters and broke them into categories so our app can serve them one at a time randomly with a category filter.  To see it in action, here's the website Chatoms.com (unless you use Internet Explorer... because we've yet to care about that).  So essentially it's a little thicker than your traditional Magic 8 Ball application because you don't want heavy repetition, you need a database, app storage, network calls, etc.

If you're interested in investigating the projects yourself, we've made the source code for the Chatoms app available online. Of course we've limited the conversation starters to a small data set, since the data is really the only valuable part of it.

• Chatoms written in PhoneGap Source
• Chatoms written in RubyMotion Source

On-boarding

PhoneGap has a wide variety of options for getting started.  So many options, it actually hinders your setup.  You can develop from within DreamWeaver, download the native starter for whichever platform you're planning on developing for, or use their PhoneGap Build option. Unfortunately it's the situation that mandates this variety and since it's catering to many types of people, one approach may be more familiar to someone than another, given their background. There's no other way to get past this slightly complicated setup which ironically defies the goal of easy development once and deploying to 7 platforms.

Ultimately the simplest option is their Automated Build System which helps alleviate the complexity, but is also a payed service (once you go over 1 application or 1 collaborator).

RubyMotion on the other hand, is limited but upfront about what it's providing. You're looking at a whopping $150 (at the time of this writing, $200 later) financial splash on top of the paid Apple Developer Account, but the rest of the on-boarding process is very smooth.  After a download and an install, you're set to start using RubyMotion immediately.  If you have any complications, it's also nice to know you've got access to the private ticket system, as well.  You're limited to iOS and it requires developing on OSX, but setup is as straight forward as it could get.

Platforms

PhoneGap definitely wins on platforms supported.  But it's worth mentioning that there are a few caveats with that statement.  Though PhoneGap allows you to deploy your application to 7 different platforms, you're held back by the following:

• You don't have direct access to the API of every platform.  Ultimately you have to hope PhoneGap has supported the ability to do what you want, or you're writing plugins for it outside of HTML/JS. So your project and it's growth is limited by the support of PhoneGap API, and not native API. This not only has possible performance limitations, but also makes updating your apps to the latest SDKs dependent on a third party.
• You'll still need a Mac if you want to do iOS.  It would appear at a glance that you could use PhoneGap to make iPhone applications without ever necessitating a Mac.  Upon closer inspection though, to deploy iOS apps (building, testing, signing keys, etc) you're going to need a Mac for PhoneGap.

RubyMotion is limited to iOS development on a Mac. A major advantage over PhoneGap is the RubyMotion gives you direct API access and is statically compiled to native binaries. There's no performance impact (PhoneGap runs inside a browser view and is limited to a single thread) and you're calling Objective-C APIs directly. 

Coding / Debugging

PhoneGap leverages your existing knowledge of web development. If you're very familiar with HTML5, CSS, jQuery etc. then you can quickly adapt that knowledge into building an app.  Additionally, it's easy to call PhoneGap API from inside the application.  If you're familiar with JavaScript then your API calls into PhoneGap are as easy as looking up what you can do.

Though PhoneGap makes it easy for you to use your knowledge of the web, it adds an intermediate level of complexity for debugging.  When we first migrated Chatoms the website to PhoneGap it began easily enough, because we were able to reuse a lot of our web code.  What we quickly found was that once you add code that cannot be run in a browser (any code that depended on PhoneGap's abilities), your debugging options quickly grew into advanced debugging issues, and what was previously done on the server had to be ported to client side equivalents (database calls, randomization, etc).

RubyMotion is a dialect of Ruby with a few exceptions and additions, but is absolutely stuffed with Objective-C and UIKit API calls. Since we're not Objective-C programmers, the bleeding edge RubyMotion experience has been a hurry-up/stop endeavor for us. Do some awesome stuff until we hit a weird syntactical translation problem, then bang our heads against the wall for an hour. Fortunately several helpers are in development like Bubblewrap and Tips and Tricks to lead the way, but until there are Ruby DSLs around the majority of the APIs, it will feel very much like writing Objective-C in Ruby and not like writing idiomatic Ruby (yet). Ultimately, with the currently available tools, there's no way of abstracting away the knowledge of conventional iOS development.

Debugging in RubyMotion, on the other hand, is a pleasure.  Due to RubyMotion's REPL in the console, you can truly communicate with your running application in a way that makes development a lot easier the PhoneGap.  Running code and UI tweaks are extremely easy.  You can even command click elements in your simulator to change to their scope in the Ruby console, creating a two-prong debugging tool.

Documentation and Support

PhoneGap has a large documentation advantage.  Not only did PhoneGap start in 2008, giving it about a 4 year head start, but it's based on front-end web technology, which is significant if you're a developer transitioning from web development. Given that the two dominant phone platforms employ Webkit, there's a large amount of HTML5 features available to you. PhoneGap also has an amazing Wiki and lots of code samples that clearly identified with exactly what platforms each API supports, and given it's age, a much larger community that follows.

RubyMotion is too new to fairly compare in documentation, but for now, PhoneGap's documentation is vastly superior. However, Ruby communities have often shown excellent support, testing, and documentation, so it's safe to say the documentation will follow if RubyMotion gains traction. The motion command allows you to create a support ticket directly from the command line.  Additionally, if you do learn how to translate Objective-C into RubyMotion, then you've unlocked a massive supply of books and tutorials that were originally intended for iOS.  As we've stated before, we're not Objective-C experts, so we're doing our part to translate Objective-C code into usable, bitesized RubyMotion examples for community benefit.

Speed

PhoneGap acts as a layer between your app code and the device, and therefore pays the price of lost speed and limited API reach. All of your code is ran at run time instead of being compiled. It's APIs are nearly the lowest common denominator of features among multiple platforms.  Phones are getting faster and faster, but you'll absolutely notice the difference using PhoneGap. It may be acceptable as a prototype, but Apple users will probably notice the difference. Using simple jQuery transitions pales in comparison to the smooth flow of a native application.  We saw significant UI responsiveness let downs even on an iPhone 4S and considering how simple our Chatoms application is, we can only expected that performance problems will grow as an app becomes more complex and that development time will be spent tracking down problems and optimizing the code is ways that native development doesn't require. Though it's easy set up your initial UI in Phonegap, you're unable to use iOS's excellent default UI elements which means reinventing wheels or bringing in something like jQuery Mobile.

RubyMotion actually gets compiled to native binaries. With RubyMotion doing memory management for you, the code is fast and you don't really need to think about it  (yet?).  You're employing native UI elements and the iOS MVC design model, so the application looks and feels like it's an native app because it is.

RubyMotion also supplies you with the ability to work with concurrency since nothing from the API is off-limits. Now that most phones are shipping multi-core processors this will probably grow in importance for app development. This is a pretty big concern for processor intensive apps or apps that process anything in the background. PhoneGap runs inside the single thread of the web view, and even then, performs worse than Mobile Safari since the Nitro JS engine isn't available for apps.

Deploying

PhoneGap's deployment depends heavily on how you chose to on-board, so it's a blessing and a curse.  Ultimately you'll still need to do key-signing in order to export your finalized product.  For all the benefits of PhoneGap development, your deployment process is not nearly as simple as you may have hoped.  Deploying to different environments requires a bit of research for each environment still.  PhoneGap does a great job of bringing you to the doorstep of your individual platform, but definitely doesn't assist as much as one might like, once inside. As newbie app developers, we probably spent about 10 hours combined for the process of setting up each platform's build environment, configuring and building submittable app packages, navigating the app submission process for Android, Amazon and Apple, and all the other little things outside of actual programming. The second time around will obviously be quicker, but it's still a bit of a headache that they can't abstract away.

Another key deficit of PhoneGap is that regardless of what features you choose to utilize, your application needs ALL PhoneGap permissions (we'd love to be wrong and for someone to correct us on this).  So our simple Chatoms application, that didn't even need an network connection, displayed needs of the following permissions: take pictures and videos, change your audio settings, record audio, fine (GPS) location, full Internet access, read contact data, write contact data, modify/delete USB storage contents modify/delete SD card contents! Many users don't care, but there's certainly a segment that will refuse to buy and install our Android app because of it's overreaching permission requirements.

RubyMotion is able to bypass some of the headaches of XCode development (and XCode itself, mostly). As Rubyists, we're much more comfortable working directly from the command line. The rake device task builds and uploads a development archive of the application to an iOS device.  The rake archive task can be used to generate .ipa archives for both development and release modes. An .ipa archive is suitable for ad-hoc distribution and can also be used for a submission to the App Store.  Though RubyMotion only supports one platform, it's already making development and deployment on the platform easier.

One of the things that's most exciting about RubyMotion is the ability to wrap UIKit in DSLs. The future is hopefully a terse yet expressive development language for iOS. We'd love to stop writing Ruby-flavored Objective-C sooner rather than later.

In Summation

It's always a cop-out when comparative blogs say "it depends on your situation" so rest assured, I'm not going to do that to you. That answer works for nearly any comparison.  PhoneGap is quick, it's easy, and it's initially attractive... and it's also the clear loser in my opinion. Yes, it's great for rapid cross-platform development but if you're doing much outside of porting a simple webapp, well, I'm going to paraphrase the great Ron Swanson and say don't half-ass many things, just whole-ass one thing. If you want to write iOS apps, write specifically for iOS. PhoneGap feels like half-assing it. It's the same feeling we get from Java desktop applications: write once, feel wrong everywhere.

RubyMotion is still new and has its share of blemishes, but it doesn't feel lacking in the ways PhoneGap does. The obvious downside is that you'll still have to write and maintain a separate Android version if you need it. And from a strictly business perspective, it may still make sense to use PhoneGap if you've got to deploy to both. Writing an app twice has it's costs and that's understandable.

I'm reminded of Alan Cooper's "Dancing Bear" analogy, in where people are just impressed that they could rather than if they should. In other words, you'll need to actually provide value in your application and be proud of the results to stand above the rest and in my opinion, only one of the above tools will take you to that level.