For my talk at LA RubyConf, I decided to share some truths about mobile development, in general, rather than focusing only on how it is different with Ruby using the Rhomobile platform.

The truth is that mobile development sucks. With Ruby, sometimes it sucks less. The unavoidable problem is that at the end of the process you still need to get your app on the device using cruddy development tools reminiscent of the 1990s. I likened mobile developers to people who like to get tattooed. Perhaps some are thrilled by the painful process, but most endure it to achieve the end effect. Mobile applications are compelling, wonderful expressions of some practical problem solved that you can carry around in your pocket. Despite the often frustrating and stupid steps that I need to follow to get things done, I love what I can build as a mobile developer.

Rhomobile is steadily normalizing some of the process to smooth out the cross-platform differences using tools and techniques from Ruby, which I discussed at the end. My talk reviewed the development process backwards, starting with the user experience, reviewing what it takes to distribute the app and build it for distribution, then finally reviewing the code (posted on github). I posted links to the app for iPhone and BlackBerry.

The key point on the user experience is that mobile apps should be different on each device, but those differences should be superficial. It is essential that your app use the common UI patterns that users of that device expect, but the core of your app has to do with the problem you are solving and that should be consistent across devices. For the RubyConf app, those device-specific differences were the navigation. On iPhone, there’s a tabbar across the bottom. On Android, there is also a tabbar that has a slightly different look and is positioned across the top. On BlackBerry, these navigation options appear in a menu. The user of each device would find the navigation expected, since it is consistent with how other apps look and feel on that device. Meanwhile, most of the screens are identical across the app. I didn’t discuss the map implementation which is almost the same across devices — of course, it always looks like a map with markers, but the markers have a different visual representation and the pan/zoom controls are different.

The other point about user experience, which is not expressed by the RubyConf app, since it is really a work-in-progress, is that your branding should be consistent across platforms. Mobile apps have more in common with web applications than they do with desktop applications. On the web, your brand is integrated into your application UI. I expect that to be the common pattern for mobile applications as well.

The process of building, signing and distributing the app is quite different cross-platform. It is really hard without actually doing it to get a feel for what it takes and how long it takes to do this on each platform. The documentation is scattered and hard to follow even for a single vendor. One of the goals of my upcoming book is to pull together this information and help people understand what is common across platforms and what is consistent. In this talk, I gave a lightning-speed overview of the process on iPhone, BlackBerry and Android.

The slides for the talk don’t really stand alone, but I am posting them here for reference:

I don’t know who first said that if you aren’t embarrassed about your v1 product, you waited too long to ship. At Mightyverse, we repeated that to ourselves as we struggled to release the first version of our iPhone app. After 2 weeks, we hit 128 downloads and I enjoyed reading my co-founder, Paul Lundahl’s reflection on the process. Despite our misgivings, we continue to explore the painful edge of what may not yet be a minimally viable product.

Why do I persist in this belief that we are pursuing the right methodology when the release of this marginally useful app means that many early users may be frustrated and never come back?

• A mobile startup without a mobile app hasn’t reached the starting gate. At least now, we have a demo that anyone can see. No matter how many times I tell people that Mightyverse allows you to access native language video recordings, when I show the app half the people say “oh, so you are using video!” When you are introducing a new concept, people only hear half of what you say. Even when we speak the same native language, communication is hard.
• We are learning a lot from the app and the process. Now we know that we can get through the Apple App Store process. We understand the limitations of the iPhone video APIs. With a version of the iPhone app released we can consider whether another platform will allow us to create a better user experience, while still leveraging our early iPhone work to maintaining a presence on that platform.
• This open approach allows us to move more quickly toward our goals than traditional methodologies. Even if we are a bit embarrassed, we are also very excited. We are learning how to work together effectively to balance content and software development. We know that our 23,721 video recordings represent just a droplet of language and our software does not yet provide features which support any use case particularly well. Working in collaboration with language enthusiasts and other early adopters we have developed a process of continuous course corrections.
• Having an audience leads us to make hard decisions quickly and perform crisply. Since the audience is small, we are comfortable experimenting and allowing forward motion with a post-hoc review process. Moving quickly unleashes creativity. The process is inexplicably fun.
• Lastly, I expect that the people who will discover Mightyverse in the future will vastly outnumber the people who will use it now, so I am ok risking their displeasure. In fact, if we actually manage to stumble upon some people who hate it, perhaps that is an opportunity.

So, if you have an iPhone, download the app, join our experiment, and let us know what you think. After all, where else can you learn to say “I’m sorry. I speak the Japanese of a pre-schooler” ?