RubyMotion Blog

Avatar

This is the official blog of RubyMotion, a toolchain for iOS and OS X development that lets you do iPhone, iPad and Mac apps in Ruby.

Follow us on Twitter to stay tuned with everything that's happening in the community!

Not a RubyMotion user yet? Give it a spin today!

RubyMotion #inspect 2014: Last Speakers, Panel, Schedule

In about a month we will be launching our second annual developer conference, #inspect, the 28th and 29th May in sunny San Francisco, California.



RubyMotion #inspect 2014 will be a 2-day single track conference, 100% about RubyMotion. We picked an awesome venue, Fort Mason, a former US military post office which offers a scenic view of the famous Golden Gate Bridge.

We are obviously super excited about the conference. Make sure to grab a ticket when you can, we are selling those fast.

Last Speakers

We are now revealing the last 6 speakers, in addition to 16 already-announced speakers:

  • Kevin Poorman is a software architect at West Monroe Partners and a certified Force.com developer. He authored several RubyMotion apps, all tied to the Salesforce enterprise resource, and will talk about connecting RubyMotion to enterprise systems.

  • Andy Pliszka works at Pivotal Labs on large iOS projects. He will talk about setting up RubyMotion for Test-Driven Development (TDD) and how to leverage test-first methodology when building RubyMotion projects.

  • Ivan Acosta-Rubio writes iOS apps using RubyMotion at Software Criollo. In his talk, Ivan will introduce the AV-Foundation framework and how to capture media on iOS and OS X. Let’s write some spying tools!

  • Isaac Murchie works at Sauce Labs and will talk about using tried-and-true Ruby tools, such as RSpec, Cucumber and Capybara, to automate the testing of RubyMotion projects with Appium, in order to deliver robust mobile apps.

  • Paul Colton is the co-Founder and CEO of Pixate. Paul will review the Freestyle framework and how it can be used to style RubyMotion apps using just plain CSS.

  • Mark Villacampa works for Cabify on their RubyMotion app and is also a hardware enthusiast, hacking 3D printers. Mark will talk about connecting RubyMotion to hardware, walk through all the available options, and giving recommendations for the folks interested to try at home.

This ends our speakers selection for this year! If you submitted a proposal and didn’t get in we are truly sorry. We got a lot of proposals this year and it was tough to make the pick!

Panel

We will be organizing a panel dedicated to RubyMotion apps in production.

The panel will be composed of folks working on high-profile RubyMotion apps, such as Bandcamp, Jukely, A Dark Room (which is at the time of this writing, number one in the top-paid category of the US App Store!), and possibly Frontback and Jimdo.

We will discuss their experience, common pitfalls when working on a high-profile RubyMotion app, then take questions from the audience.

Schedule

We published the schedule of the conference. One keynote, 20 presentations, one panel. As you can see, it’s fully packed with awesomeness!

We still have tickets available, so if you want to join us, now is the time, register today!


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion #inspect 2014: Announcing More Speakers, Student Tickets

In a bit more than a month, the 28th and 29th May, we will be launching our second annual developer conference, #inspect, this time in sunny San Francisco, California.



RubyMotion #inspect 2014 will be a 2-day single track conference, 100% about RubyMotion. We picked an awesome venue, Fort Mason, a former US military post office which offers a scenic view of the famous Golden Gate Bridge.

We are obviously super excited about the conference. Make sure to grab a ticket when you can, we are selling those fast.

More Speakers

We are happy to reveal four more awesome speakers, in addition to 12 already-announced speakers:

  • Alex Rothenberg is a software engineer at McKinsey and the author of the motion-addressbook library. He will talk about simplifying the Cocoa APIs and making sure they do not crush your Ruby code.

  • Dennis Ushakov, a software engineer at JetBrains, will show off RubyMine and its excellent integration with the RubyMotion toolchain.

  • Nikolay Nemshilov is a senior software developer at Ninefold and also the author of UnderOS (or shortly, uOS), a project that aims to help web-developers to get into native iOS development by reusing knowledge and technologies they already know, which he will present.

  • Austin Seraphin is a blind developer and an accessibility expert. Austin was a speaker at #inspect 2013 last year and delivered one of the most acclaimed presentations. Since then, he authored the motion-accessibility gem and will talk about how making RubyMotion apps accessible to the blind.

We will be announcing the last batch of speakers soon. If you submitted a talk proposal, we will get back to you as soon as we can. Thanks for your patience!

Student Tickets

Due to the demand we will be offering a limited batch of tickets for students to the conference at a highly discounted price.

Students tickets are priced at $149 and require proof of enrollment. Please email us in order to get one. We will update this post once the batch will be gone.

Call for Sponsors

We are still looking for a small number of sponsors to share in the support of #inspect 2014. This is a great opportunity to show your commitment to the RubyMotion community and also promote your products or services. If you or your company are interested get in touch.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion Success Story: A Dark Room

A Dark Room is a very popular text-based role playing game (RPG). Originally web-based, Amir Rajan ported it to iOS using RubyMotion, and very quickly the app went from being the top game in the RPG category to be in the top 5 paid apps in the UK App Store. At the time of this writing it’s on its way to the top paid category of the US App Store.

The game now enjoys a 5-star rating and has been positively covered numerous times in the press.

We sat down with Amir to discuss his experience building this awesome game in RubyMotion.


What is your background, and what brought you to become involved in RubyMotion?

Before I took my sabbatical (I guess you can say I’ve gone independent now), my entire 8 year development career was all .Net development. I used ruby primarily for build automation during my day time job. Outside of my 9-5, side work I did was primarily Rails and NodeJS. I’ve contributed quite a bit to the open source .Net community. I’m a contributor to NSpec (an RSpec clone), SpecWatchr (an auto test tool for NSpec), Oak (a dynamic “poly fill” for C# andASP.NET MVC), and Canopy F# (a Web UI automation DSL for Selenium and PhantomJS).

One of my friends told me about RubyMotion. I was immediately interested given that I had an appetite for “different ways” (better ways) to approach problems.

Why did you choose to use RubyMotion instead of Xcode and Objective-C?

My first few apps that I built (none of which made it into the App Store) were actually built using Xcode and Objective C. Notably, I built a little budgeting app for myself with a Rails back end. At that time I actually had RubyMotion but wanted to have a solid basis of “vanilla” iOS development before making an assessment on RubyMotion.

One thing I saw immediately was the contrast between the work I did on the server side Rails app vs when I went back to Xcode. The hardest things to explain is the “Ruby mindset”: light weight environments, concise workflows, editor agnostic, fast feedback loops, simple API’s… essentially developer happiness.

As painful as it was to work outside of my souped up VIM environment, I completed my budgeting app using Xcode and Objective C for the client side. I did not enjoy the experience. Objective C is verbose, the Cocoa API’s are unintuitive, a lot of ceremony with regards to class definitions. Xcode makes it difficult to work with vendor libraries (try referencing AFNetworking for HTTP communication and Cedar for testing if you don’t believe me). Interface Builder was frustrating to work with too.

Now that I had my perspective, I worked with RubyMotion instead. The wrappers are wonderful (I primarily used BubbleWrap and Promotion). The rake tasks that come out of the box are great. Testing is first class, MacBacon has an RSpec style DSL that I know well and enjoy working with. Package management is solid, and I was able to use Objective-C libraries via CocoaPods. It just felt like everything was thought through, distilled down, and presented in a form that was immediately familiar to me given my Ruby background (and the “Ruby mindset”).

What inspired you to create “A Dark Room”?

A Dark Room is actually a joint venture between myself an Michael Townsend. He created the web version of the game. It went viral on Hacker News and I stumbled across it. At this time I was on a sabbatical, and decided that this would be a wonderful project to take on. I absolutely loved the web version of the game, but it wasn’t touch device compatible. I sent an email to Michael, asking if I could port it to iOS. He said yes! 4 months and 12,000 lines of RubyMotion later, I had a game in the App Store.

How did you begin writing the app, what were your early development stages?

I had some real world experience with Xcode and Objective C. In fact, the first few hours of A Dark Room development was done in in Xcode. I wanted to start fleshing out the engine of the game, and found it rather awkward using OCUnit. I rely heavily on fast feedback loops and incremental evolution. OCUnit did a good job in giving feedback, but fell short when it came to test composition. I refactored often, and what I found was that Objective C and OCUnit just made that an utter chore. I had a copy of RubyMotion, I knew that it had an RSpec style testing framework, and I knew how easy it was to refactor Ruby code. So I put the Obj C version of A Dark Room aside, and fired up RubyMotion.

I was extremely happy with the default template. Testing was baked in, the rake tasks were already in place to run tests. I created a light weight watchr script to run tests whenever I saved a file… everything just gelled really well :-)

As the game progressed, how difficult was it to add and remove features from your code base?

Not knowing RubyMotion, I initially stuck to using “vanilla” Cocoa apis for all my UI work. It was extremely easy to translate Objective C to Ruby. I was able to use all the resources on Stack Overflow whenever I hit a snag. Eventually, I was juggling a number of views and decided to look at ProMotion and BubbleWrap (which I found via the RubyMotion Wrappers site). The refactoring was easy. It amounted to deleting code ;-).

As far as the core game engine, I was able to use all the refactoring techniques of Ruby. All the language capabilities “just worked”: inheritence, class macros, modules/mixins, “send”, blocks, etc. My tests were always running in the background with every change I made.

Your app has been praised as being one of the few games that have are accessible to the blind. What did you do to make sure your app was accessible?

Accessibility changes were surprisingly simple to make. It’s amazing how much iOS does for you out of the box. Most of the first part of the game was already playable via VoiceOver. I ended up using an existing Objective-C open source library called SSAccessibility (it did all the hard work with regards to queueing multiple messages). I used CocoaPods to install the library, updated my Rakefile, and was up and running. The key take away here is that I was able to leverage the existing Objective-C ecosystem. Here is a write up of all the quirks with regards to making accessible apps.

What were some of your greatest, happiest moments during development?

Shipping. It’s hard to believe that the code base was over 12,000 lines. I was happy to get this mammoth out the door.

Were there times that the RubyMotion toolchain was a source of frustration? And how did you get those issues resolved?

I had a couple of instances where RubyMotion would throw a runtime exception without a backtrace (stacktrace). It was always related to the initial load of the app’s UIViews. I’d use git bisect to zero in on what line caused the error. It was tedious work at times.

Will you continue to use the RubyMotion compiler on future projects?

Absolutely. Without hesitation. Idiomatic Ruby wrappers on top of iOS, frictionless workflows, and the “it just works” culture that Ruby fosters, trumps any hesitation I once had. On top of that, I now have a fairly large app to serve as a testament to the platform.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion #inspect 2014: First Batch of Speakers, Lodging Information, Sponsors

In a bit less than two months we will be launching our second annual developer conference, the 28th and 29th May in sunny San Francisco, California!

(Yes, that’s the week before WWDC!)



RubyMotion #inspect 2014 will be a 2-day single track conference, 100% about RubyMotion. We picked an awesome venue, Fort Mason, a former US military post office which offers a scenic view of the famous Golden Gate Bridge.

First Batch of Speakers

We closed our call for presentations and are now working on finalizing the schedule. In the meantime, we already pre-selected some of the speakers and it is our pleasure to list them here!

  • Laurent Sansonetti, Shizuo Fujita and Eloy Durán from HipByte will share a keynote talk in which they will talk about what’s coming next for RubyMotion (we think you will like it!).

  • Clay Allsopp, author of the Pragmatic Programmers’ RubyMotion book and numerous libraries will talk about building build tools that build tools to build apps. Sounds crazy and interesting!

  • Jack Watson-Hamblin, creator of MotionInMotion, the popular weekly screencast, will talk about the RubyMotion community and what we can do to make it better.

  • Lori Olson, author of a RubyMotion book about Core Data, will share her experience in solving real problems using Core Data in RubyMotion apps.

  • Todd Werth, co-founder of InfiniteRed and author of the popular RubyMotionQuery (RMQ) library will talk about what’s new in RMQ. Todd is also co-organizing the event!

  • Jamon Holmgren, owner of ClearSight Studio and author of the popular ProMotion framework, will talk about going from a prototype to a production app.

  • Mark Rickert, owner of Mohawk Apps, is the author of numerous RubyMotion apps, all of which are open-source. Mark also has a lot of experience marketing apps and will teach us a few tricks on how to promote an app in the App Store and through other channels.

  • Ken Miller, co-founder of InfiniteRed, is the author of CoreDataQuery (CDQ), a library which aims at making Core Data easier to use. Ken will talk about CDQ and what’s new.

  • Dave Lee is a contributor to ReactiveCocoa, a framework that provides Functional Reactive Programming to Cocoa apps. Dave will talk about integrating ReactiveCocoa in RubyMotion.

  • Will Raxworthy, author of numerous blog posts about RubyMotion, will talk about 2D game development, using the new SpriteKit framework and integrating with native game controllers, and eventually write a Flappy Bird clone!

We will be announcing more speakers soon. If you submitted a talk proposal, we will get back to you as soon as can. Thanks for your patience!

Lodging Information

The conference is located between the Fisherman’s Wharf and the Marina district. Both are within easy walking distance and both have public transportation.

The Wharf has many places to stay because it’s a tourist location. There are a lot of tourist-area places to eat too. You won’t see a lot of San Franciscans in this area, but there is a lot going on and it is fun.

The Marina is a local neighborhood, but there are a lot of motels/hotels on Lombard street. The Marina is cheaper than the Wharf.

There are plenty of other neighborhoods to stay in too. The Mission district is where a lot of tech workers live and is an Uber car-ride away. Union Square is a popular location and is a MUNI 30 bus away (or Uber). SOMA and Market Street are where many of the startups are.

Check out the lodging section of the conference website for more information and also pointers to places we recommend.

Sponsors

We are delighted to announce that Pixate will be our lead (gold) sponsor this year!

Pixate was founded in the summer of 2012 as a Y-Combinator company with the goal of enabling designers and developers to quickly and easily create beautiful, native mobile applications. Their flagship product, Pixate Freestyle, enables the styling of native mobile applications using CSS.

A few words from our silver sponsors:

Terrible Labs is a design and development shop in Boston. They use RubyMotion to build all of their clients’ iOS applications. They have also used RubyMotion to build their own product, TicketZen, the easiest way to pay parking tickets.

RubyMine, the most powerful Ruby IDE, provides smart coding assistance and advanced testing and debugging features for all types of Ruby projects and cutting-edge technologies, including RubyMotion.

We would like to thank Pixate, Terrible Labs and RubyMine for helping us organizing this awesome event.

We are still looking for a small number of sponsors to share in the support of #inspect 2014. This is a great opportunity to show your commitment to the RubyMotion community and also promote your products or services. If you or your company are interested get in touch.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion Raises Millions, Becomes Free, Introduces Smart Suggestions™

Update: We hope that you folks enjoyed our April Fools prank! We are of course still 100% bootstrapped. We also still intend to grow organically thanks to your continuous support!

(Personal thanks to Josh Ballanco for having had the idea of RubyMotionCoin and MotionInflater.)


We are delighted to announce on this 1st April 2014 that we just closed a multi-million dollar funding transaction with Agile Ventures and Extreme Capital, two top-tier investing firms of Silicon Valley.

This is our first series A round of funding and we are extremely excited about the future of RubyMotion. Make sure to read the coverage on TechCrunch (to be published later today). You can also check a picture of our new board of directors and observe the synergy already at work.

We have been bootstrapping RubyMotion since its inception and were profitable by charging our awesome customers (from here on out referred to as users), but we think it’s now time to shift into the next gear.

Our goal is to grow RubyMotion faster into a 100-people company serving millions of users and bringing you folks tons of innovation. The entire team will also relocate into the San Francisco Bay Area (including Eloy’s new boat which presents a set of interesting logistic challenges).

We are of course still committed to a long-term vision. Unlike the majority of VC firms, our new partners Agile Venture and Extreme Capital are there for the long run and will definitely not require an exit in the next four years. (At least they said so during our meetings.)

Free, Smart Suggestions

Thanks to this funding round we no longer need to get money from you folks, so RubyMotion will become totally free. Awesome isn’t it?

We will also ship with a new feature called Smart Suggestions™ (patent pending). The RubyMotion build system will now show you suggestions of services you might want to use by scanning your project’s source code, sending us a copy, and getting back a list of relevant services. (Please note that the connection to our server is totally secure by using the same cryptography algorithms used in banks, so you should feel safe.)

Here is an example of what a future project build session might look like.

  Compile app/person.rb
  !!! It looks like you are creating a regular expressions on line 42.
      RegexBuilder™ is a new revolutionary tool that makes building
      regular expressions easier.
      Would you like to know more? [Yy]
[...]

We believe that Smart Suggestions™ will significantly increase your productivity, so we are enabling it by default for all users. Please contact our sales team if you would like to disable Smart Suggestions™.

Future Plans

Very soon we will be introducing RubyMotionCoin, a new virtual currency that is mined as a byproduct of the Xcode build system. If you include a CocoaPod in your app that contains Objective-C++ code using templates, your mining rate doubles.

Finally, we will be releasing MotionInflater later this year, a system that will automatically convert your RubyMotion code to Objective-C, ensuring that your app gains the approval of important people and allowing you to experience the inflated ego that can only come from shipping a real iOS app.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

New in RubyMotion: New CLI, WeakRef Zeroing, Background Fetch Testing, Subscripting, Performance

We shipped quite a few releases since the beginning of the year. Let’s dig into the new major features.

New Command-Line Interface

The motion command-line interface has been fully rewritten using the CLAide project.

$ motion 
RubyMotion lets you develop native iOS and OS X applications using the awesome Ruby language.

Commands:

    * account          Access account details.
    * activate         Activate software license.
    * changelog        View the changelog.
    * create           Create a new project.
    * device-console   Print iOS device logs
    * ri               Display API reference.
    * support          Create a support ticket.
    * update           Update the software.

Options:

    --version   Show the version of RubyMotion
    --no-ansi   Show output without ANSI codes
    --verbose   Show more debugging information
    --help      Show help banner of specified command

The new codebase allows better output and more elaborated argument handling. It will also allow us to extend the interface more easily in the future.

WeakRef Zeroing

In previous builds, trying to send a message to a WeakRef object whose internal reference was prematurely destroyed was causing a crash at runtime, since it was attempting to send a message to an invalid object address.

Now, the internal reference of WeakRef objects will properly be zeroed when it is destroyed. Sending a WeakRef object a message whose internal reference has been zeroed will cause a WeakRefError exception at runtime, matching exactly the behavior of CRuby’s weakref.rb standard library.

The WeakRef#weakref_alive? method was also added and will return false in case the internal reference has been zeroed.

autorelease_pool do
  @ref = WeakRef.new(Object.new)
end
@ref.weakref_alive? #=> false
@ref.description    #=> WeakRefError: Invalid Reference - probably recycled

Background Fetch Testing

iOS 7 introduced the notion of background fetch which for example allows your application to check a remote web API if there is any updated content and, if so, fetch it, all while being in a suspended state.

To perform a background fetch iOS will launch your application using the application:performFetchWithCompletionHandler: method. You can now simulate this on the iOS Simulator by setting the background_fetch environment variable, as show below.

$ rake background_fetch=1

Note that while your application is in the background you will not be able to REPL until you activate the application again.

Object Subscripting

As of clang 3.1 Objective-C developers are able to add support for the new Objective-C literal syntax on their own classes by implementing a set of methods.

RubyMotion will now properly handle objects from these classes and allow you to send the #[] and #[]= messages on them as convenience shortcuts.

As an example, let’s take a fictional SubscriptingExample Objective-C class:

@implementation SubscriptingExample

- (id)objectAtIndexedSubscript:(NSUInteger)index;
{
  ...
}

- (void)setObject:(id)object atIndexedSubscript:(NSUInteger)index;
{
  ...
}

- (id)objectForKeyedSubscript:(id)key;
{
  ...
}

- (void)setObject:(id)object forKeyedSubscript:(id)key;
{
  ...
}

@end

The following class can now be used from Ruby code using convenience shortcuts.

obj = SubscriptingExample.new
obj['one'] = 1
puts obj['one']
...

Performance Improvements

As you could see from the release notes our goal of improving the overall performance of RubyMotion apps is continuing steadily.

Runtime primitives (such as the method dispatcher) are faster by 25%. Builtin classes methods have also been optimized, sometimes by a 2x factor. Some of our users reported very positive feedback from their testers.

As mentioned in our previous report, we are still working on a benchmark suite for RubyMotion. Its goal is to let us identify performance problems as well as catching performance regressions. It is still at this time a work in progress and we still intend to publish it once it’s complete.

Jim Weirich

Jim was one of the very early RubyMotion users. He believed in the project and gave us the motivation we needed to keep working on it and launch it.

As the author of Rake, it goes without saying that RubyMotion would not exist without him.

You can watch Jim speaking about RubyMotion at the local Cincinnati Cocoa user group. In this video, Jim demonstrates his legendary joie de vivre as well as his excellent teaching skills.

You can also check out Jim teaching the use of source code control (you do use SCC on your RubyMotion apps, right?) for the Pragmatic Programmers, who have kindly agreed to donate the full proceeds of the screencast to Jim’s family.

Jim passed away the 19th February 2014. He will be deeply missed. Rest in peace, Jim.


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion Success Story: Jimdo

Jimdo is a web site creation and hosting service based in Hamburg, Germany since 2007. Their motto is Pages to the People! and since last year they provide an iOS app for iPhone and iPad that integrates with their service.

The app was recognized as Best of 2013 by Apple and is fully developed with RubyMotion! We sat down with Christoffer Tews, one of the folks at Jimdo responsible for the app.

Can you tell us a bit about you?

My name is Christoffer Tews. I started at Jimdo ~2 years ago with a student job during my Master of Science in eCommerce . I wanted to do something in the mobile development because my bachelor thesis had been about implementing an iOS shopping app with Appcelerator Titanium and the whole mobile development is just exciting.

So I came to Jimdo and started to work as a student on the very first day on the iOS app of Jimdo with Mark Frawley (Developer) and Jan Schlie (Designer). The team grows up to 10 people later. While doing my masters thesis (building a usability framework for iOS) I decided to join Jimdo as a full time employee, because I loved the product especially the iOS app and the dev team around it. And I still freaking love it! ;)

What is Jimdo the company?

Jimdo is the easiest way to create a website. With a simple, intuitive interface, Jimdo enables anyone to create a unique website with a blog and online store. Our motto—Pages to the People!—sums up our mission: Put the power of website creation into everyone’s hands. Whether you want to start a business, promote your music, or simply share photos with your friends and family, you can create your home on the web with Jimdo.

Since it was founded in Hamburg in 2007 by young entrepreneurs Christian Springub, Fridtjof Detzner, and Matthias Henze, Jimdo has grown tremendously. We’ve helped people build more than 10 million websites and Jimdo is now available in 12 languages. Our team of 170 people come from 15 different countries and work in 4 offices worldwide.

If you want to know how much fun it is to work at Jimdo just look at this page.

What did you make with RubyMotion?

Our iOS app allows users to build a complete webpage for themselves or their business on directly from their mobile device. It’s not like other apps, where you can just edit some parts of your website and maybe don’t even see your site because of a „special user interface“ to edit the content.

With the iOS app of Jimdo you can edit the website simply by touching an element on your website e.g. a headline, some text. You can also structure your entire site’s content with our simple, gesture-driven in-app navigation editor.

What role does the Jimdo iOS app play in your business, and related to that: why did you decide to build the app?

So from the business point of view it has two primary goals. First, it is a value-added service to the existing Jimdo web service, allowing our users to easily update their site with rich media and text while away from their desktop. Secondly it serves as a new platform for organic discovery of our brand, a way for new and different demographics to discover us. We offer the iOS app for free - it doesn’t matter if you are using the Jimdo Free package or the Pro/Business package. The only difference between the packages is, that Pro or Business users will get some extra features in the app that are not available for Jimdo Free users, e.g. Statistics (page views, visitors, etc.), extended Shop features etc. These extra services will grow with the time and we will also always enhance the core app features for Free users to stay true to our core value Pages To The People!.

Given your experience using Appcelerator Titanium, why did your team choose RubyMotion to build the Jimdo app?

So we must admit that we chose Titanium Appcelerator in the beginning (before RubyMotion was released), because Jimdo is a web product with lots of front end web development experience and it seemed a good choice to build a cross-platform app which we could re-use instead of building a native app for just one platform.

However, after about 2 months we regretted choosing Titanium. It was sometimes slow, not very flexible (there were issues customizing TableViewCells and other native UIKit components without writing Objective-C). The support for newer iOS SDK features always lagged months behind Apple releases, and so it impeded our ability to quickly new version-specific features. In short it became clear that building a high- performance app with a huge amount of (UI)-customization wasn’t clearly feasible with Titanium.

Apart from that, developing a complex hybrid app with Javascript was clearly no fun at all. In particular, some things that bothered us were: Lack of proper namespaces, classes, accidental global declaration, minor syntax errors passing without warning, undefined variables discovered at runtime etc.

After a new evaluation of possible alternatives we found the freshly distributed RubyMotion framework. We were a little bit afraid of choosing a brand new framework especially because we wasted 2 month of development at this point, but it’s implementation of the Ruby language is directly based on the Cocoa APIs and data types. Therefore, and because it is compiled ahead of time, it’s performance is much closer to standard Objective-C. Also, the possibility to vendor in Objective-C (3rd party) libraries with one line of code, was and is, just awesome. Also at this point ARC wasn’t completely released yet and the built-in garbage collection from RubyMotion made our code very terse in comparison to Objective-C.

Even our UI-Designer started to write code. We built our UI without using Storyboard, our entire UI is built with a mix of reusable procedural code and Teacup stylesheets.

What technologies from iOS did you use, and did you have any issue accessing those in RubyMotion?

That is kind of a tough question, because we really use the whole spectrum of iOS technologies. I think there is almost no UI element that we haven’t implemented and customized in our app.

We make heavy use of RubyMotion’s excellent support for Objective-C Categories, which makes implementing delegate protocols very simple. In terms of Apple Frameworks, we use CoreData for non-sensitive data, and Keychain Services to save sensitive data securely on the phone. We also completely redesigned our app to adhere to iOS 7 design guidelines, which includes blurred background images, transparency, flat UI where it makes sense.

We’d like to extend our thanks to the RubyMotion team here for supporting the iOS 7 APIs since its beta stages and for the constant (weekly) updates to fix bugs. We only faced limitations when we tried to (ab)use the Runtime class of Objective-C for meta=programming patterns like method swizzling but this could be solved by writing our own wrapper in Obj-C and vendor it in.

Apart from that we really weren’t confronted with many bugs in RubyMotion and even when there were, our mails and pull requests were answered promptly and the fixes were usually implemented in the next weekly update. We wonder if Laurent gets much sleep because his response time answering emails was never longer than 15 minutes whatever time it was ;) Thanks for that!

What gems, CocoaPods, and other libraries did you use, and which did you find the most useful?

First of all: Teacup! It is just great for designing the UI, decouple the code from the views or controllers and makes it easy to customize elements for different iOS versions.

And we use the following Pods and libraries: SSKeychain, AFNetworking, AdjustIO, Thrift, Crittercism, Reachability, Google Analytics, and much more…

What did you learn from writing this app in RubyMotion that you will remember the next time you need to write an app?

We had a lot of learnings there. Some were about code quality and trying to use patterns like MVC correctly in Cocoa. Others were about how to create useful, maintainable automated tests. We decided very early to establish automated tests but our focus was more on Acceptance Tests written in Cucumber format with the Frank Framework. This was and is still a good solution to our needs but an actual test run take almost 1 hour.

So we decided to increase our unit test coverage with the inbuilt “rake spec” MacBacon framework that ships with RubyMotion. These tests of which we have several hundred already only take a couple of seconds to execute which gives us more immediate feedback.

One of our learnings so far is, start writing unit tests for your iOS app as soon as possible and as much as possible - it really makes you think about your class/module interfaces and encourages you to decouple views, controllers and methods so as to be more testable. It just makes your code better and more solid. You also don’t start to panic on your next upcoming release, if there’s a bug, because you can just test it.

Would you recommend RubyMotion to other developers who are going to start learning iOS app development?

Definitely yes! As mentioned in the intro, we started of with 3 people on the mobile team. All 3 of us hadn’t much experience with Obj-C or Ruby. RubyMotion empowered us to learn both in a very short time. Learning Ruby is quite easy, even combined with learning the iOS Cocoa APIs, it has a flatter learning curve than adding Objective-C into the mix.

From my personal point of view I would even say if you want to learn writing native iOS apps, RubyMotion is the fastest, most technically solid way to do it. I personally also recommend it to academic courses which are usually of a 2-3 month duration (one semester) - a period where it’s hard to additionally learn Obj-C and write a good working prototype in parallel.

When you needed to find out an answer to a tricky problem, how did you get the help and answers you needed?

The support at the RubyMotion Google Group is really good and the response time there is also fast (max. 12h until first response). As some of us had already met Laurent at the BubbleConf in Amsterdam, we just sent him emails directly, but we try to do it only when it really gets technically deep into the RubyMotion implementation or if we have found some curious bugs. I’m pretty sure he thinks “Arrr! This Jimdo dudes again” ;), but as mentioned, his responses were fast and he’s still polite. He doesn’t send standard phrases like “Please open a support ticket at…”, even if maybe he should sometimes to stay sane. Also Colin is really active and helpful in the Google Group.

For a company of this small size, with what I imagine is a huge customer base, HipByte is really responsive. Thanks again for that!


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

Announcing RubyMotion #inspect 2014

We are super excited to announce our second annual developer conference, #inspect 2014. The event will happen on May 28th and 29th, in lovely San Francisco, California, and is co-organized with our friends at InfiniteRed.



RubyMotion #inspect is our official conference. It is organized for and by the RubyMotion community and aims at covering all the technologies that surround the RubyMotion ecosystem. This is the place where RubyMotion enthusiasts can finally meet face-to-face to chat, connect, hack together and learn what’s happening in the community.

Last year #inspect was organized in Brussels, Belgium. We definitely had a blast. Many guests told us it was the best conference they ever attended. This year we will change a few things and try to innovate with the conference format.

We booked an awesome venue for the event, Fort Mason, a National Historic Landmark right in the Marina district of San Francisco. We will be scheduling at least 16 talks as well as workshops, informal panels, and more activities. Like last year, we will also deliver awesome food and celebrate the end of the event with a great party.

We already pre-selected 8 awesome speakers. If you would like to speak at the conference we definitely want to hear from you.

Early-bird tickets are available, at 25% off the regular admission price, in limited quantity. Don’t wait too long. Like last year, the conference is designed to be small and intimate, and will likely sell out before the event.

To those interested, we will also be running a 2-day training right before the conference. It will be a shorter version of our official training program and will be delivered by core RubyMotion engineers. We conveniently provide a Training+Conference ticket.

Finally, we are looking for a small number of sponsors to share in the support of #inspect 2014. This is a great opportunity to show your commitment to the RubyMotion community and also promote your products or services. If you or your company are interested get in touch.

We will be posting more information about the event very soon. Stay tuned and see you in San Francisco!


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

New in RubyMotion: Device Crash Reports, Pretty Vendor Build Output, Proc#weak!, Performance

Our last release of the year, featuring a few major changes. Let’s dive in!

Device Crash Reports

It is an unfortunate reality that applications crash. This is even more so the case during development cycles.

Until today, the best way to deal with device crash reports during development was to use the Xcode organizer. As a lot of you already know, the user experience was far from ideal and symbolication did not always work as expected.

As of RubyMotion 2.18 we are happy to introduce a long-awaited Rake task to deal with device crash reports: rake crashlog:device.

The task will:

  1. Connect to your development device
  2. Retrieve all crash reports generated by your app
  3. Symbolicate them using the .dSYM bundle created by our build system
  4. Save the final reports on your file system
  5. Open the last generated report in Console.app

Let us show you an example. We create a new RubyMotion project and slightly change the application delegate method to trigger one of those UIKit-level exceptions which will crash the process hard.

class AppDelegate
  def application(application, didFinishLaunchingWithOptions:launchOptions)
    NSArray.arrayWithArray(42)
  end
end

As expected, running the app on the device causes a crash.

$ rake device
[...]
    Deploy ./build/iPhoneOS-7.0-Development/foo.ipa
*** Application is running on the device, use ^C to quit.
Dec 29 21:01:49  foo[936] : -[__NSCFNumber count]: unrecognized selector sent to instance 0x17da1190
Dec 29 21:01:49  foo[936] : *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFNumber count]: unrecognized selector sent to instance 0x17da1190'

Since this is a lower-level exception happening on the device the terminal output does not contain its full backtrace. We could easily get it by connecting a debugger, but let’s use another way! Since the application crashes a report was generated on the device. We can use the new rake crashlog:device to retrieve that report and see what happened.

$ rake crashlog:device
New crash report: /Users/lrz/Library/Logs/RubyMotion Device/foo_2013-12-29-210200_lrzs-iPhone.crash

The command saved a new crash report file and opened it in Console.app. This is what we can see (some of the lines have been trimmed out for better readability):

Last Exception Backtrace:
0   CoreFoundation                  0x2f013e7e __exceptionPreprocess + 126
1   libobjc.A.dylib                 0x393706c2 objc_exception_throw + 34
2   CoreFoundation                  0x2f0177b2 -[NSObject(NSObject) doesNotRecognizeSelector:] + 198
3   CoreFoundation                  0x2f0160aa ___forwarding___ + 702
4   CoreFoundation                  0x2ef64dc4 __forwarding_prep_0___ + 20
5   CoreFoundation                  0x2ef4d70c +[NSArray arrayWithArray:] + 40
[...]
9   foo                              0x00097008 rb_scope__application:didFinishLaunchingWithOptions:__ (app_delegate.rb:3)
[...]

As we can see, the last frame from our application (highlighted here) in this exception backtrace was in the app_delegate.rb file, line 3, which coincides perfectly with our wrong arrayWithArray: call.

Just by typing one command in the terminal we were able to determine what went wrong on the device. Pretty cool, isn’t it?

Pretty Vendor Build Output

The RubyMotion build system invokes the xcodebuild tool in order to build Xcode-based projects. If your project uses CocoaPods or manually vendors Xcode-based libraries you already know that the build terminal output can be messy sometimes.

As of RubyMotion 2.18 the build output of Xcode-based projects will be consistent with the rest of the build. Here is an example of the new output of a project that uses CocoaPods.

     Build ./vendor/Pods/Pods.xcodeproj [SORelativeDateTransformer - Release]
   Compile ./vendor/Pods/Pods-SORelativeDateTransformer-dummy.m
   Compile ./vendor/Pods/SORelativeDateTransformer/SORelativeDateTransformer/
           SORelativeDateTransformer.m
      Link ./vendor/Pods/.build/libPods-SORelativeDateTransformer.a
     Build ./vendor/Pods/Pods.xcodeproj [Pods - Release]
   Compile ./vendor/Pods/Pods-dummy.m
      Link ./vendor/Pods/.build/libPods.a

This feature would not have been possible without integrating the awesome XCPretty project, created by Marin Usalj and Delisa Mason.

Proc#weak!

Since RubyMotion relies entirely on the underlying iOS’ retain count memory model, creating cyclic references is unfortunately possible.

In order to help developers avoid the creation of retain cycles, in the past we introduced the WeakRef class which can be used to create weak-references in Ruby and also a cycle detector that can resolve basic cyclic references at runtime.

Sadly it was still possible to easily create cyclic references using blocks. Let us explain why.

A block in RubyMotion keep a strong reference to the object it was created from, bound as self, which prevents said object from being destroyed before the block can send messages to it.

class Test
  def foo
    lambda { bar }
  end
  def bar
    p :here
  end
end

o = Test.new
b = o.foo
o = nil
b.call

In this case, the Test object will remain alive until the Proc object dies.

This behavior has the side effect of easily creating cyclic references.

class MyController < UIViewController
  def viewDidLoad
    @b = lambda {}
  end
end

In the snippet above, the Proc object keeps a reference to the MyController object, and vice-versa, resulting in a cyclic reference. Because the cyclic detector is at this point not able to detect cycles outside autorelease pool contexts, both objects will leak.

This is where Proc#weak! can come handy. This method makes sure the given Proc object does not keep a strong reference to its self binding anymore.

The method always returns a reference to the receiver and can be safely called multiple times. The snippet above can be rewritten to prevent a cycle:

class MyController < UIViewController
  def viewDidLoad
    @b = lambda {}.weak!
  end
end

Now, MyController will still keep a strong reference to our Proc object, but the later will not. MyController can then be safely destroyed when it is no longer needed, along with the Proc object.

We believe that the addition of Proc#weak! was the last remaining piece to help RubyMotion developers prevent cycles in their apps. Some popular libraries (such as BubbleWrap) and high-profile apps (such as Bandcamp) are already successfully using it.

Performance

As you might have already seen from the previous build release notes, we have been working on performance improvements for the past few weeks.

We have been internally building an intensive performance suite. Our objective is to run it periodically against previous versions of RubyMotion in order to catch performance regressions. We are also running the suite against CRuby 2.0 with the goal of providing better performance results in every possible scenario.

This is a long process and we are not done yet, but we will publish the suite and the data online as soon as we have something we are pleased with.

In the meantime, if your app or library is experiencing performance issues, please let us know via a support ticket, attach some code and we will add it to the suite!


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.

RubyMotion Success Story: Bandcamp

Bandcamp is an online music store, as well as a platform for artist promotion, that caters mainly to independent artists. Artists on Bandcamp have a customizable microsite with the albums they upload. All tracks can be played for free on the website and some artists offer free music downloads.

Bandcamp recently launched their new iPhone application and it has been written with RubyMotion. We sat down with Daniel Dickison to talk about his recent experience using Ruby to build an iOS app.

So Daniel, you’re at Bandcamp, what’s your role over there?

I am a programmer and sort of, the way we do things is all the engineers do a little bit of everything. We’re not too specialized, but obviously I’ve been working on the mobile app, so that’s been my thing for the better part of this year.

It’s been a solo endeavor?

Mostly, although definitely wasn’t totally solo. We have two dedicated designers on the team. So the designers did the design and I did most of the coding. Though a couple other people helped out during the process.

Tell me a little about Bandcamp, what kind of a company is it?

We do music. It’s a music platform for mainly independent artists and also labels. So it’s a platform for people to put their music up and distribute it and get paid directly from fans for buying music. That’s sort of the main thing we do.

Is it a pretty big startup?

I don’t have much of a sense of whether we’re big relatively. I don’t have much of a context. Let’s see I think we’re something about 15 employees now. We just celebrated our 5th anniversary, 5th birthday of Bandcamp was just a couple weeks ago, so we had a special blog post.

That’s right! With very cool ASCII art.

Oh yeah that’s Moni, our designer, he’s the ASCII art master.

Oh very cool!

He does a lot of ASCII art stuff in the group IRC that we’re always on.

It’s one of those things you’d expect to be a lost art, and instead it proliferates.

Mmhmm. It’s kinda fun, I don’t know how people make those, but I’m always impressed when it’s animated.

I’m wondering more about the “Bandcamp platform”. Is that to say that people build applications using your platform, or is it that you can build multiple applications with?

Oh I meant platform, not in the technical sense, but as artists using the site to promote their own music. We don’t set prices, artists basically control their own Bandcamp page. They can give music away for free, or for pay, name your price is like “the big thing” these days.

So the web application has been around for five years?

Yes, that’s basically what it was, exclusively, until the app. And the app itself is a compliment to the site.

What led to the mobile app? What was lacking?

There’s really, the one big thing was, when fans buy music on Bandcamp, before the app, you would basically get a download for the music, whether it’s a track or an album. If you wanted to listen to it on your phone you would have to download it on your computer, then load it onto itunes, then sync that to your iphone, which works, but is 5 steps more than we want people to have to do just to listen to what they bought on their phone.

So the big idea is if you buy something on the site, then you should be able to seamlessly listen to it on your phone, which is the first and main problem that we wanted to solve on the app.

Gotcha, so you wanted a way to download directly to the device and play it, pretty much be one action.

Yup!

What led to the decision to use RubyMotion for the iOS app?

That’s an interesting story! So the site’s written almost all in Ruby, on the server side, so all the engineers here know Ruby. Personally I’ve done some iOS development, so I would have gone with Objective-C and written it that way, but Joe, who is head of engineering, I think he was familiar with MacRuby from before, so he heard about RubyMotion and suggested it, and the big plus is that it’s a lot easier for other engineers to jump on the project. It’s a different API but the language is what we’re all used to doing on the server side already. So really that’s the big reason.

Has anyone else reviewed your iOS code?

Yeah, so actually after v1 went out, we’re working on new features, we actually have another guy that’s doing iOS stuff almost full time now for features, and Joe was another one who spent a good chunk of time working on the iOS app.

How was it, introducing them to the organization of the code, and where things go, what was that learning curve like for them, for the new developer?

I’d say, there’s still a learning curve, because the UIKit stuff, it’s a pretty big API to wrap your head around, but it definitely seems like it’s a lot easier to add new features. We look through the code and the syntax is all straight up Ruby.

So the language isn’t getting in the way.

Yeah, kind of an interesting aside, back when we were still prototyping the app, I had an idea to do the UI as a Web view. If that had panned out, it would’ve been really cool because the backend code would’ve been all Ruby without a lot of the UIKit layers. It would’ve been very straight up server type code on the backend with Ruby, and the frontend would’ve been HTML/Javascript. We didn’t end up going that way in the end, because it worked pretty well, especially on iOS, it works really well, but it didn’t work that well on Android. You lose most of the gains of doing it cross-platform anyways.

Gotcha. Let’s talk more about early prototyping. Were you able to use RubyMotion to your advantage there?

I think so, a lot of simple things get really simple. I’m thinking the basic whether you’re matching regular expressions with strings, or iterating your arrays or working with hashes, that stuff is so much less verbose, doing it in RubyMotion. And the other, I guess it’s both a pro and con, is not having to work in Xcode. I use Sublime Text myself, but it’s nice being able to drop right in to the editor you already have customized and not having to have this gigantic IDE. Although, it’s not so bad and definitely getting better.

Actually for a while I was using Sublime Text and switching to Xcode to compile, I would switch back and forth. But it is a difference. For me, Xcode doesn’t become part of my work flow as well. I can integrate iterm and Sublime Text, I can have them talk to each other very easily.

I feel like if you want to use Xcode to the full extent, you have to let Xcode be the world. Use storyboards, do everything in Xcode because everything’s integrated well.

What kind of RubyMotion tools were helpful, like what’s your workflow look like?

We didn’t use a lot of CocoaPods or anything like that, this was a decision I made early on, because I’m familiar with Ruby and I’m familiar with UIKit and Foundation and all that, a lot of the nice Ruby wrappers I just wanted to write myself, just for maintainability, because you guys are iterating pretty quickly, and iOS SDK’s change, not as drastically but you do kinda have to stay on your toes to keep up to date with new APIs that come out, and get deprecated. So it seemed like it might be a good idea just to do it all in our own custom code that we have a good understanding of and can easily change if we need to update it for various things.

My workflow is basically a terminal window open that’s firing off rake every time I need to compile, and a Sublime Text window and Dash is awesome for documentation because when you don’t have the Xcode, I dunno what you call it, the assistant window, and option-click to get documentation, it’s super super useful to have Dash.

I would agree that’s the thing that I would love to see implemented, is autocompletion. I guess RubyMine has a very good one but I haven’t seen one for Sublime Text. I don’t know how’d you do that anyway, that analysis.

Yeah, maybe this exists already but it’s probably possible to just hook up a key binding to take whatever string your cursor’s currently in and hand that off to Dash. Which I should probably look into, that would be pretty useful.

What I would love is if I started to type UIControl and then I could choose StateNormal, and it would flow off my fingers. Though, for that specific example I use SugarCube of course, it has helpers for that.

I noticed recently that the Sublime Text plugin for RubyMotion recently updated for Sublime Text 3, I haven’t installed that yet, I should probably check that out because I think a lot of it would just be having autocompletion for a lot of the constants.

Do you use any gems or CocoaPods?

No we don’t actually, we do use some third party libraries, which are pure Objective-C. FMDB is Objective-C wrapper around Sqlite, and Reachability wrapper, just real simple Objective-C stuff. We wrote some Objective-C ourselves. There’s a few parts, there’s an audio player, one of the main features we have, that we wanted, is to play a track we just bought, streaming, from the server, but we also wanted it to be cached for subsequent plays. It turns out you can’t do that with the built-in AVPlayer API. It’ll stream, but it won’t give you the data to cache it at the same time. So we wrote a little audio player, using the audio queue API. So that’s a C API. It may have been possible doing it in Ruby, but it was just easier just to drop into pure Objective-C and C. So we have that.

You expose that with Objective-C classes?

Yeah it’s basically an Objective-C wrapper around the C API. It basically takes a file and we can play audio from a file as it’s being written out from the server. So that’s a low level thing we had to write in Objective-C.

bandcamp gif

Another thing that RubyMotion contributes to is the ability to organize code differently than you would in Objective-C, I wondered if you had any thoughts on that.

Yeah, actually that’s kind of interesting, I hadn’t thought too much about it… not having .h files for everything is quicker when you’re writing code, you can just start pounding out code without having to switch back and forth, making sure your header and your exposed APIs, and worrying about that stuff. So it’s definitely faster, I think.

Any other metaprogramming techniques that you rely on?

Oh yeah let’s see, I think there were some. There’s some utility base classes that, depending on whether TestFlight SDK is defined or not, if it isn’t it’ll stub it out with a dummy class that pretends like TestFlight SDK is there. There’s definitely little funky Ruby meta-programming stuff that we can do that we throw in there.

Were there any issues with RubyMotion things that hung you up?

There’s definitely one thing that was a huge time sink which was the memory management, especially with blocks and multi threading. I filed some bugs with you guys about this, and a lot of it got sorted out.

Any feature requests, things you’d like to see, in terms of RubyMotion?

Let’s see… that’s a good question I mean the profiling one would have been a huge one but you guys got it already, that would’ve been one. You know it’s actually pretty solid. I think once you guys get this retain cycle and memory management stuff solid, I think that would make it, without question a solid platform to develop in.

Great! Any questions for our side?

I’m curious, are you guys a distributed team?

Yeah we’re all over! I’m in Denver, I pretty much step in for the interviews, for community projects, kind of poke around the mailing list as much as I can. Most of the team is in Europe, though we’ve got Watson in Japan, in Tokyo. So he and Laurent have been the main, core developers, though Eloy Duran is also entered into that world.

We’re also distributed, it’s interesting to hear about other teams that do that. We do a daily Google Hangout meeting to give status, to keep up to date, I was wondering if you do stuff like that?

Nothing so formal, we are always in HipChat, and it’s actually kinda fun because the sun never sets on the HipByte chat, because it transfers from Japan to America to Europe, and there’s this perfect 8 hour difference between each one, it just depends on who’s awake. There’s always at least one person to hand it off.

I think we’re pretty close to that! We have a guy in Australia who keeps the lights on when everyone else is out, and then a guy in Oxford, and the rest of us are scattered around the Americas. It’s pretty good for us, too, because if there is an emergency, there’s usually someone around there’s usually someone around to take care of it.

We don’t get to take advantage of that, there’s usually not compiler emergencies, like there is on the web.

Haha emergencies accumulate a little more slowly.

A little, yeah, and you can always fall back to a previous compiler version, usually that resolves it for the short term. Well Daniel I don’t have any more questions for you, I really appreciate you taking this time. And I hope you continue to make apps using RubyMotion.

Oh yeah we’re in it for the long haul with this app. You’ll definitely hear from us, I’m sure.

Great, congratulations again on shipping!

Thanks! Have a good one!


Interested in giving RubyMotion a try? We offer a 30 days money back guarantee. Download it today!
Follow us on Twitter to stay tuned with everything that is happening in the community.

By Laurent Sansonetti.