News

 
  • 13 May

    RubyMotion Moving Forward - One Year Later

    It's been a full year since I acquired RubyMotion and became its steward. Over this time, RubyMotion has pushed thirteen releases (and is about to push number fourteen). Throughout this process, I have genuinely listened to the community's feedback and incorporated it within each release. Here are some highlights of what's changed.

    RubyMotion Applied

    The RubyMotion Applied GitHub Repo launched to provide a bit more visibility on what's being worked on, what can be picked up by community members (in exchange for a free RM license), and more advanced issues that will significantly increase a developer's mobile development chops.

    Starter License Includes MacOS

    The Starter License now includes MacOS High Sierra. This change removes all financial barriers to entry for building Android, iOS, and MacOS apps. Once you've dipped your toes into the waters, you can then decide on getting a full-blown Indie License (which includes more SDK versions).

    Community Participation

    You can email me (ar@amirrajan.net), tweet at me (@amirrajan), post to the community forum, converse during the monthly RubyMotion meetup (come to the #meetup Slack channel for the next live streamed link), or DM me on Slack. I'm always here. It doesn't matter how tiny you feel your problem is; I'm here to support you any way I can. That being said, the best thing about the RubyMotion community is there's always someone to lend a helping hand. Many times I'd be in the process of responding to a message, and another member handles it. It's hard to put into words how great that feels.

    Aside: I've recently rebooted the community forum, too. Come say hello.

    Sustainable Open Source

    Slowly but surely, RubyMotion is making incremental changes to support sustainable open source.

    • Trusted community members have access to this very website to recommend updates.
    • RubyMotion Applied provides a means for new-comers to contribute even the smallest pull request.
    • RubyMotion's templates are now open source and can be updated live/independent of a RubyMotion release.
    • RubyMotion's CLI commands are now open source and can be upgraded live/independent of a RubyMotion release.
    • Work is being done to open source and provide BridgeSupport updates out of band.
    • Work is being done to open source and provide repl updates out of band.

    This is just the beginning. Again, I want to emphasize sustainability. For me, it isn't enough just to open up the source code for this toolchain. I want developers to have the technical means to actually contribute. Too many "low-level" open source projects out there have an incredibly high barrier to entry for new contributors. I want the RubyMotion compiler to be one of the few projects that provides a means for newcomers (who've never touched a line of C code), to eventually become experts.

    Marketing

    If you've been involved in the RubyMotion community, you'll know that I dislike "marketing" in the conventional sense. The marketing I see out there right now is generally dishonest. For example:

    • Marketing Open Source as a ploy to bring developers onto a platform (only to find that the most import bits of a toolchain are propietary).
    • Showcasing flashy tech demos that are all smoke in mirrors.
    • Claiming sustainable/turn-key cross-platform deployment, when it isn't that simple, and requires the guidance of someone with real-world experience.
    • Claiming that a technology is native, when it really isn't.
    • Evangelism by devs who build nothing but "click draggy droppy" toy sample apps, and who have never actually released a successful app to the stores.

    This is the status quo of marketing right now. RubyMotion will not participate in these techniques. So here is what has been done on the marketing front this past year:

    • Sponsored mentorship programs at the University of Texas Dallas.
    • Charitable contributions to Rails Girls Summer of Code.
    • No questions asked free licenses for university students.
    • Appearances on Ruby Rogues and the CodeNewbie podcasts.
    • Presentations/lightning talks at Ruby RemoteConf and RubyConf New Orleans.
    • Workshops/presentations at academic institutions (both high schools and universities).
    • Encouraging word of mouth/grass-roots recommendation from community members.
    • One-on-one brain-storming sessions with community members and startups about how to build successful mobile applications.

    What's Next?

    Devs use RubyMotion because it lets you write native, cross-platform applications in Ruby. That is definitely a primary differentiator. But, I want RubyMotion to be more than about building apps with Ruby. I want RubyMotion to be about building successful apps.

    To emphasize the point above: If you're looking for a "safe" commodity toolchain, backed by a "safe" large corporation (who doesn't care about your success, nor the tiny line-item the toolchain represents on their balance sheet), look elsewhere. RubyMotion isn't for you. If your sole motivation is to check the "we have a cross-platform mobile app" checkbox for your company, look elsewhere. RubyMotion isn't for you.

    Now. If you want to create a successful app, with a toolchain built by a self-funded, profitable, knowledgeble company that cares about your success, read on.

    What does a successful mobile app look like?

    • A good name for your app that is search optimized.
    • High conversion rate on push notification (80%+).
    • High engagement.
    • Seamless, no-registration-required authentication.
    • An IAP conversion rate over 2% (if that's your monetization strategy).
    • Compelling, well placed rewarded ads (if that's your monetization strategy).
    • Tasteful/successful call to actions for premium content (if that's your monetization strategy).
    • Independently persisted data that supports seamless upgrades from version to version (especially around managing what's considered free vs. premium content).

    The plan is to bake this everchanging "business-centric" guidance right into the RubyMotion toolchain. Eventually, when you spin up a RubyMotion template:

    • You get a turnkey AWS instance to handle push notification (with CLI commands/Web interface to manage when these notifications go out).
    • Baked in warnings and guidance with regards to orientation, touch control selection, review solicitation, and when to display call to actions for monetization.
    • Turnkey APIs to measure engagement (with an "it just works" backend to capture this data).
    • Baked in warnings for poor App names (and a means to project revenue potential based on apps within your competition space).
    • Reports that help you make decisions and tweak your app (live-ops).
    • A means to capture "good" App preview videos and screenshots (all the encoding backflips you have to go through and guidance on screenshots that will encourage people to give your app a shot).
    • A means to create a quick hybrid app, get the hybrid app pushed to the stores as quickly as possible, and guidance to incrementally convert that hybrid app to native.

    The list above captures how real production apps are built.

    In short: Sure, a dev can snap their fingers and make a cross-platform app with framework X, but they haven't thought about all the ancillary/business-centric things needed to create a successful cross-platform app. RubyMotion takes these ever-evolving strategies/concepts into consideration and will help you (the developer) build something that has the best possible chance to succeed.

 
 

Want to stay in touch?

Follow us on Twitter