Sadly, after a long year of using RubyMotion, I've decided not to renew my subscription, and have instead returned to native Swift development. I am disappointed in this outcome because I thought very highly of RubyMotion, and developing iOS/Android apps in Ruby, but found the experience to be lacking in quite a few ways.
Rather than drudge on about my personal reasons for too long, let me concisely provide you my reasoning:
1) Weak documentation
Yes, the documentation is rather short. While the introductory material is just fine, there is not enough intermediate or advanced level of documentation. The documentation does not touch on extremely customized functionality, nor does it touch on how to integrate third party frameworks, CocoaPods, or things that are common now in iOS development.
It does not walk developers through the flow or process of developing an app throughout the various stages. It does not really go into depth about how to use the Storyboard flow, nor how to do common types of integrations.
While documentation is never fun to create or maintain, it is vital and is the most impactful way that the RubyMotion core team could grow RubyMotion -- which would in turn end in significant developer growth.
2) Double Knowledge Requirement
You ultimately need to understand the iOS frameworks in order to develop in Ruby on RubyMotion. These frameworks are used in Objective-C and Swift, and thus to truly understand how they are implemented and used, you need to understand how they are used in Objective-C or Swift. And to do that, you need to understand some things about those languages.
What this effectively means is that you can't come in and develop in Ruby/RubyMotion without knowing Objective-C or Swift, and thus you need to learn one of them (at least at a basic level). If you're already going to take time to learn Swift, you might as well just develop in Swift. A common argument for developing in Ruby is that it makes Ruby developers feel more comfortable, but they would still need to learn the frameworks and at least some fundamental understanding of one of those Apple sanctioned languages. Another argument for Ruby is that those languages are cumbersome and Ruby is easier (which is many ways is true!), but sadly you have to develop in Ruby using Objective-C styles and interfaces. This is problematic because ultimately it's just a Ruby wrapper, not a Ruby port. You lose a lot of the "Ruby way" in the process.
Lastly, one of the arguments for developing iOS and Android apps in Ruby in RubyMotion is code reuse. But as many, many posts in the RubyMotion Community reveal, there is no chance in hell that you are sharing code between platforms. They are fundamentally so different, and not all of the add-ons are supported. While you may be able to share basic model classes, the meat and potatoes of your application (all the UI magic) can not be.
3) Dwindling Community
I hope I'm wrong about this one. But based on the response rate of my posts and the posts of others that often ask, I see a very high delay in the post/respondtime ratio, and in many cases no clear answers or solutions are provided. This is not always the case, but since this is the official place to get peer support, it is interesting that such turnaround exists. And sadly, there aren't big communities of support for this elsewhere.
Ultimately it doesn't feel like the actual Ruby and Ruby on Rails communities, which are very vibrant and abundant. This community, while well intentioned, is rather immature (read: small and focused, not childish) and needs to develop. But rather than grow, it feels like it is stuff in a holding pattern.
4) Not enough big apps
There just aren't enough well known apps out there using this. There are a ton of little indie-style apps out there, which is fantastic. But there aren't any significant well-known publishers/developers using it. And while this of itself isn't important to me, the result of it is. It means that there aren't any larger players who have a stake in the platform and community; which means that there is less community "give back" involved. This means the community grows much, much more slowly.
Small indie devs usually don't have the time or energy (and potentially experience/knowhow) to give back. That's not exclusive of course, there are lots of amazing indie devs. And I'm not trying to be critical of indies. It's just that they are usually too busy trying to carve out a living and don't have the budgets to give back in significant ways.
5) Slow to adopt new features
While it was really cool that initial Apple Watch (watchOS) support was brought in (during the Xcode betas), it never matured. The documentation never grew significantly, and there was no sense of "true support" ... and not until much, much later, when the "Apple Watch land grab" was long over. That's OK, because RubyMotion has never been about that, but it's frustrating when people just learning Swift are already building Apple Watch apps, and you're futzing with RubyMotion's unique way of doing things and can't get a Watch app to sign and build, much less understand how to build it out to have meaningful features.
Forget about tvOS, it's going to take some time for that.
OK so if you don't care about expanding to those platforms, then maybe it doesn't matter. But I'd venture to say a lot of us need to. Even if it's just the next version of iOS, there's always this huge delay in official support. It's the nature of the beast, you have to follow Apple's moves first, then learn how they implemented the framework foundations and way of doing things, and then expand RubyMotion to support it. I get that. But it means big delays for the developer.
6) Weird quirks
I don't even know how to explain this, other than to say all sorts of "things that shouldn't be happening but are happening" occur. And it makes the development flow frustrating and painful. And then it means you know you have to waste a week trying to solve it, instead of making strong progress moving forward.
This is not meant to be a gripe but more an explanation. My motivation for posting this is in hopes that RubyMotion will continue to improve, grow, and eventually become a tool that thrives (and something I may return to).
I am grateful for the opportunity to have developed with Ruby, a language I use professionally daily for my projects and the projects of my clients. And I really do hope that these things are solvable.
Because if they are... and then they get solved... I'll be back.