Daniel Spector

Swift Will Only Benefit RubyMotion

Some of you may know that I'm a huge RubyMotion fan. The clean syntax, the DSL's, the community... it's fantastic. Last week at WWDC, Apple announced Swift, a brand-new programing language for iOS and OSX development. Many in the RubyMotion community have taken this as a sign that RubyMotion is headed for demise and I think that's completely untrue.

I started taking a look at Swift using the official Swift book as a guide and it's fantastic. The syntax is clean, there's type-safety (fortunately or unfornately missing from Ruby, depending on your perspective.) and you get the feeling of using a powerful, modern language.

Thinking that Swift will be the end of RubyMotion means that you only value the syntax of Ruby rather than understanding why developing in RubyMotion is so powerful. I'll admit that Ruby syntax is so much more approachable than Objective-C but I use RubyMotion for many more reasons.

  1. Terminal and Editor over an IDE - I do most of my work on a daily basis in iTerm and Sublime Text with a little Vim sprinkled in. It's a comfortable environment and I can smoothly navigate between different panes, pull up an endless amount of helpful hotkeys and shortcuts and customize my environment to my liking. Therefore, I'm not the biggest fan of Xcode. There are many great reasons to use Xcode but I feel much more productive with my current environment. If you're programming in anything other than Objective-C all day (you're a web developer and you're working with iOS on the side, for example), you're going to have a huge context-switch penalty everytime you change projects. Obviously there are a lot of benefits to using Xcode and certain tasks like Interface Builder are impossible without it (although you can use them for your RubyMotion projects as well), but on the whole I feel much more productive wtih my current workflow than in an IDE.

  2. DSL's - The iOS SDK is incredibly verbose. MethodNamesUsuallyLookSomethingLikeThis and there's a ton of boilerplate code for setting up seemingly trvial tasks. Obviously iOS is endlessly customizable but some tasks should be easier to accomplish instead of writing the same code over and over again. Luckily, Ruby is an incredibly popular language for creating DSL's or Domain Specific Languages. These DSL's put a layer of abstraction over your iOS code which makes creating applications incredibly intuitive. Gems like BubbleWrap, Sugarcube and motion-kit make iOS development extremely pleasant. RMQ gives you the jQuery-like abilities with your code and Promotion is a complete framework that makes your life much easier. All of these combine to make a development experience that is much closer to Ruby or Rails than it is to iOS and Objective-C. The learning curve is substantially shortended because you have a bunch of really convenient helpers. With Swift, you still have to manually type out all of the boilerplate code that you did with Objective-C. While that code may look prettier than Objective-C, you lose the power of the DSL's created for RubyMotion.

  3. Language - I work in a company that primarily codes in Ruby. I use Rails on a daily basis and am very comfortable with the Ruby language. Using RubyMotion, I'm able to transfer all of my knowledge over to mobile development. At the end of the day, programming is universal across all languages and differences among languages just boil down to syntax but for maximum productivity, I'm going to stick to what I know best. With Swift, even though the language is clean, it's still a new language to learn. By using RubyMotion I can build on my Ruby skills and produce mobile apps in record time.

  4. Docs - Even if you are using RubyMotion, you need to be comfortable enough with Objective-C in order to read the docs/Stack Overflow posts to debug your code. Luckily Objective-C is conceptually similiar to Ruby so while it's not a very pleasant language to write, it's easy enough to understand once you get the hang of it. However, Apple's long-term goal is to move all of Cocoa into Swift which means that the docs will be much more approachable for someone using RubyMotion. You'll be able to apply answers from Stack Overflow much easier when you can just scan the code instead of spending time deconstructing it. This may be the biggest win over the long-term. And finally...

  5. Android! - At the annual #inspect conference, the RubyMotion team announced that the new version would support native Android development in addition to iOS. This is a huge win for a number of reasons. While all of the issues that we discussed above, you can now truly unify your platform by developing in Ruby for your web, iOS and Android applications. No longer will you have to hire seperate Ruby, Objective-C/Swift and Java developers. This is a huge plus to new startups who are looking to take on entrenched incumbents but don't have the resources to build out an entire team.

Even though I plan on sticking with RubyMotion, I'm still going to learn Swift. Learning new languages is exciting and there is no one correct answer in programming (or anything in life for that matter). What's important is that you are open to new ideas and enjoy learning new things. I'm excited to learn Swift but I plan on sticking with RubyMotion for my day-to-day mobile development.

If you have any comments or questions, please feel free to hit me up on Twitter or shoot me an email.

Thanks for reading!