RubyMotion Success Story: Fandor

Fandor wanted to make it easy for people to discover and watch handpicked, award-winning movies of all lengths and genres, from the world’s most respected filmmakers. They aim to create a global community of film lovers and makers connected by meaningful and entertaining cinematic experiences as well as deliver a fair revenue share to filmmakers and distributors.

Fandor decided to go with RubyMotion to build their iPhone and iPad apps.

What were the goals for the redesigned Fandor app?

Our film database is full of classic and avant-garde films, so our first version of this redesign includes features most important for watching these films, as well as sharing them, saving them for later, and searching our extensive database.

Why did you choose RubyMotion to build this version?

RubyMotion allowed us to move quickly, and rebuild our app from the ground up in a matter of months with limited resources.

What were the features of RubyMotion that allowed you to build your app so quickly?

First, RubyMotion is Ruby. Everyone at Fandor comes from the Rails world. Being able to write in Ruby and use Ruby idioms let us code faster. We know how to write beautiful Ruby code. While learning the iOS SDK, we didn't have to simultaneously discover what beauty means in Objective-C (if there is such a thing).

Second, RubyMotion is developer-environment agnostic. By using RubyMotion, we also removed the overhead of learning Xcode. Our engineering team felt like Xcode was bloated and confusing. We each used our own IDE of choice. I can't imagine not using RubyMine - the ease of being able to jump to method or class definitions makes code reading (of both our own and external libraries) incredibly easy.

Using RubyMotion, did you run into any issues integrating native or third party tools?

The only issue we had was with the ARAnalytics Objective-C library - I wanted to use its method swizzling to centralize our analytics. We tried a few times to get it to play nice with us, but there were some confusing low-level Objective-C integration problems that became too costly to solve.

What native frameworks did you use to build your media player?

We used MPMoviePlayerViewController - it was the most straightforward option available to us. There have been some product requests that have come in recently to change the player functionality, so if those keep coming, we may explore a more low-level option like AVPlayer.

What were the biggest challenges building your app?

Getting acquainted with the iOS SDK was quite difficult at times - the system felt significantly more opaque than the open-source Rails world.

Learning how to code idiomatically was also costly. We threw away a lot of the code we wrote in the first few weeks. We sometimes came up with solutions that didn't use the hardware effectively or introduced memory leaks.

Additionally, there were a some genuinely difficult programming problems that came up. Our designers had some pretty ambitious initial designs for the layouts of the film that were algorithmically intense.

How did you research answers to issues when they came up?

Here are the resources we used, in order of frequency:

1. Stack Overflow
2. Apple Documentation
3. Third party blogs / gists
4. Apple example applications

And when all else failed, we used the amazing Infinite Red consulting company as a backstop to our own knowledge.

What open source tools would you recommend to other RubyMotion developers?

We used RMQ extensively in our app, and it made creating layouts significantly faster. I recommend it.