Ask HN: RubyMotion or Swift?

It really depends on what sort of games you are trying to build. If you want to use SpriteKit or SceneKit (both of which are iOS only), you will probably need to learn Swift. But it's possible you might want to use a cross-platform third-party engine like Unity or Cocos2D, in which case you'd be doing most of your work in C# (for the former), or C++/Objective-C (for the latter).

I don't know what the state of game development support for RubyMotion is, though, so take my advice with a grain of salt.

This is a bit of a false dichotomy. You have more than two choices, and you don't have to pick just one. I'd try both and see which you prefer. Or use whatever's preferred on the platform that you're more familiar with, at least to start.

Unity (C#) / Cocos2D (C++)

I've released apps in RubyMotion and am currently making apps in Swift, however, I don't really see these languages as good fits for game dev, I guess it depends on what kind of games you want to make, and whether you want performance or ubiquity of your codebase.

C++ will give you performance and ubiquity (Cocos2D), Unity is a little slower but runs everywhere.

I'd worry far more about finding cross platform libs than the language. Find the libs, write in whatever languages work best with the libs.

Also, do you want a job making games (use whatever employers use), or do you want to be an indie dev?

If it's just for learning a language, flip a coin.

Not so much a matter of the language as learning the frameworks but I'd stick to c objective-c swift c++ - you will probably have to deal with all four for a good while.

You're going to have to learn Swift, and probably at least the mechanics of Obj-C anyway. I've worked with PhoneGap, RubyMotion, and even a bit of Ruboto when it first came out. All of the documentation is written for Swift, and the examples are, or were, in Obj-C (though I haven't seen it in a while so I assume they converted all that to Swift by now?).

It's not a question of "which one should I learn"? You'll have to learn Swift, or at least a little bit of it, eventually to stay up-to-date with the API docs. RubyMotion can certainly be an easier (and maybe more stable?) way to express what you're doing, but you're going to have to learn the mechanics of the base system in order to work with it, eventually.

So, as a Rubyist who love's Laurent's work even back to MacRuby, and mostly programs in Ruby these days, I say just learn Swift. From a pure language-appreciation perspective, as opposed to the practical perspective illustrated above, it's in Apple's best interest to make Swift easy to work with for app developers, because that's Swift's target market. Ruby, on the other hand, does not have that same guarantee.

Go with the natural promoted option by Apple.

Why? Because game development is hard enough in its own, you will have tons of questions and I bet the official language will have more blogs, FAQs, stack overflow, etc.

Just a twist, I think at this moment, obj-c is actually more supported. Swift is in beta.

I bet if got to use RubyMotion or Swift, in both cases you will end up needing to learn obj-c.

Neither. If you have to ask this question, it's likely you aren't experienced in game dev in general. You should work on the fundamentals of building games for desktop first where the constraints of the mobile platform and build process won't get in your way.

Just some random thoughts...

I've been working with Swift since it was offered in Xcode 6 Beta 1. I'm having a blast with it, but it probably goes without saying that I've also experienced my share of frustration each time a new beta is released; however, that is to be expected, as it is beta, after all. So, until it's officially launched, just be prepared for issues.

Also, if you are not aware, you won't be able to deploy to an actual device until you enroll as an Apple Developer. It's $99 US per year. Until then, you can work with the simulator, but you will want to work on hardware to get the "Full Effect"... I mean, when you see your game on hardware, with full touch capability, music playing and all of the trimmings, you will find it extremely gratifying.

I've mentioned this before [1], but I think you are going to find more support from Apple with regard to game development. We all know games are big-business, but it's interesting to note that Apple has really stepped up within the last 2 years.

Take SpriteKit. It didn't exist until it was announced at WWDC 2013. Up until that point, the functionality offered by it was largely either hand-rolled by the developer, or achieved via framework (e.g., Cocos2D). I think Apple realized that they could capture more mind-share and confidence if they offered their own first-party framework offering.

Fast-forward a year later, and we have an enhanced SpriteKit (i.e., light sources, field forces, per-pixel physics, inverse kinematics), and of course the newly-announced SceneKit (3D scene rendering for casual games), Swift and Metal... all within a year!

I'll caveat that I haven't used RubyMotion, so I can't speak about it directly. You will have to do some research to find out how easily it integrates with Apple's frameworks, particularly SpriteKit and SceneKit. Maybe I missed it, but it doesn't immediately appear that they offer a free option, but it looks like they do have a return policy, so that would give you an opportunity to see if it is right for you.

I know you didn't mention it as a potential tool, but you might want to look into Marmalade [2]. It's a cross-platform option. There is a free option, but it does have limitations (e.g., on-device debugging is unsupported with the free license). Here's a matrix that compares the different pricing and feature tiers [3].

Whatever you pick, you won't go wrong. It's all about having fun, experimenting, and learning. Enjoy the journey!

* * *

[1] https://news.ycombinator.com/item?id=7841744

[2] https://www.madewithmarmalade.com

[3] https://www.madewithmarmalade.com/shop

For game programming where you might want cross platform look at C++ and Cocos2D-x.

Otherwise my advice is to learn Objective C, even if you learn Swift you really still need to know Objective C. Swift is not really ready for production apps and learning new stuff is hard enough without having to sort out bugs in the language that you don't really understand complete alongside your own bugs. There's tons of information on how to do things in Objective C not so much with Swift, it's still too new.

I used Rubymotion for a year, and just renewed my license... BUT! I'd recommend Swift and Obj-C over RM. I think RM is a great tool for quick prototyping, experimenting, and learning the Cocoa APIs (the biggest challenge).

In general though, I do feel some pain being outside of Xcode as somethings aren't as intuitive to bridge into RM like Core Data or Storyboards (both of which are amazing; especially with all the different dimensions one must target now).

Overall, RM is a great product it gets my recommendation but I wouldn't really call it an alternative to learning Swift/Obj-C and Cocoa.

There is 30 days money back guarantee..

Don't go with Ruby for game development. Much less with RubyMotion.

I love Ruby, I have made games with Ruby using Gosu and it simply wouldn't work on a mobile device. The GC will kill you app and create random frame drops.

For games, I highly recommend you check out Unity. My background is strongly ObjC/C++, but I still found that Unity was definitely the way to go when making my game (after first trying UIKit, then C++/OpenSceneGraph):

1. It is widely used in the gaming industry, including by big names like Blizzard.

2. The tools are pretty fantastic. I was (am) a huge fan of Interface Builder, but the visual tools in Unity blow it away (at least for games). It can import from the 3d graphics programs (we used Cinema4D, and thats the least supported one I think), so if you are working with an artist it really is living the dream of importing their models/movies and scripting them.

3. I am a complete C# convert. Generics, lambdas, and GC, all at 60fps! The Unity framework is also very sensible to work with, and designed specifically with games in mind.

4. Apple has a bad track record with high level gaming tech. Sure, they are doing more now (SpriteKit, SceneKit), but ultimately the motivation is to get you stuck on iOS. That was maybe OK back when paid gaming was a viable revenue model, but today the only revenue models that really work are free to play. In that world you definitely want the option to be able to ship on Android (with its higher market share). And here's the kicker: Gaming is the one place where "native controls" are meaningless, so theres no "aesthetic" quality loss in not using "native" frameworks. The place Apple is actually impressively advancing gaming is with Metal, and Unity is on it getting it to compile to Metal instead of OpenGL ES. That's the beauty of tools like that, its in their interest to make you worry about the "art" while they worry about the tech.

Sorry, this doesn't really address the OP question.

But this discussion got me wondering. If Apple's claims that Swift is faster than obj-c actually prove to hold up, would it be possible/worth-it for something like RubyMotion to compile down to Swift/native instead of obj-c (at least for the "good" parts)?

I'll jump on the "use Unity" bandwagon.

I've written mobile games with Flash/Air, natively (Obj-C), RubyMotion, and Unity. I enjoyed RubyMotion more than Obj-C but I'm currently using only Unity.

Do you know ruby already? I particularly like RM b/c I have a ton of experience writing ruby code already... but ultimately for game dev the portability of Unity is just the best right now. I like ruby more than C#, but it's not a wide margin like it would be for Ruby vs Obj-C.

Given the two options, I would say go with Swift. As others have stated, lately Apple has been dumping some resources into improving their gaming SDK. With iOS7, SpriteKit was introduced making it a bit easier to do 2d gaming. Now there's Metal coming out with iOS8. However, if you are truly looking to do mobile gaming, it's probably best to invest your time into learning Unity.