RubyMotion versus Swift for iOS Development
Tags: ruby, ios, mobileappdevelopment, swift
Published: 2019-03-11 20:20:24

---
title: RubyMotion versus Swift for iOS Development
published: true
tags: ruby,ios,mobile-app-development,swift
canonical_url: https://tmarkiewicz.com/rubymotion-versus-swift-for-ios-development/
---

As I worked on the [IBM Watson and Apple Core ML](https://tmarkiewicz.com/video-machine-learning-on-ios-integrating-ibm-watson-with-core-ml-at-altconf/) partnership, I was inspired to explore more ways to showcase machine learning for developers in different ways. One of my ideas was to look into using RubyMotion with [IBM Watson](https://www.ibm.com/watson/).

If you’re not familiar, [RubyMotion](http://www.rubymotion.com/) lets developers quickly write cross-platform native apps for iOS, Android, and OS X using the [Ruby programming language](https://www.ruby-lang.org/en/). The applications are statically compiled and then call into the native platform APIs.

As a Rubyist, when RubyMotion was first released in 2012, I was pretty excited. I had wanted to explore developing apps for iOS, but [Objective-C](https://en.wikipedia.org/wiki/Objective-C) was not clicking for me, and it can be a challenging language to learn. So when Swift arrived, this fundamentally changed the equation as it was now much easier to get started developing for iOS. Swift for many developers was much easier to use while still as powerful.

The rapid advancement of [Swift](https://developer.apple.com/swift/) as the primary language for iOS development has significantly reduced the need as well as the appeal to write iOS applications in Ruby. At this point, it seems the main benefit would be a write-once approach to get iOS and Android support. However, at this point, there are much more popular and widely supported cross-platform mobile development options such as [React Native](https://facebook.github.io/react-native/) (using JavaScript).

However, the biggest issue I saw from the beginning is that to use the various APIs for each operating system, the developer still had to read and understand the APIs (written in the respective languages of Objective-C, Swift, or Java). So while you could write most of your code in Ruby, you’re not insulated from learning and understanding the APIs in their native language. Thus I’ve never been convinced of the actual overall savings at that point for RubyMotion other than a technological curiosity.

Also, if you do a Google search for RubyMotion, you’re not going to find many recent results returned. So while this may look like it’s an opportunity to create tutorials and other content, I think the more significant reason is that RubyMotion was built when only Objective-C was an option for iOS development. Now that that Swift is becoming the primary iOS development language, the need for alternatives is significantly diminished.

Unless there are some significant changes to RubyMotion (it did come under new ownership relatively recently), I’m not optimistic about its gaining any popularity among Ruby developers.

I hope I’m wrong as I enjoy programming in Ruby, but I’ll be looking more to React Native for cross-platform mobile development.

_Originally published at_ [_tmarkiewicz.com_](https://tmarkiewicz.com/rubymotion-versus-swift-for-ios-development/) _on November 26, 2018._