The Wholesale Applications Community finally creates a viable app marketplace for phones beyond the iPhone. Yes, there were marketplaces for Android, Windows Mobile and Palm, but with far less traction. This new marketplace should gain critical mass quickly. More interesting is how to target an app for all of the phones available on that marketplace. Rhomobile’s Rhodes is the only framework that allows building native apps with synchronized data for all of those devices.

Microsoft finally shipped Windows 7 aka Windows Phone. With support for touchscreen usage through and through it looks to be a big winner. Developers will get the features of some “more modern” smartphones with Microsoft’s huge installed base of Windows Mobile apps. Using Rhodes will let developers write for Windows Phone and their apps will work on all other smartphones as well.

Also, smartphone installed base leader (by a wide margin) Nokia and Intel announced a new smartphone OS, Meego. Meego combines features of Moblin and Maemo to create yet another strong contender in the smartphone marketplace. So, as predicted on this blog many times, there are now seven major smartphone OSes. Rhodes supports five of them today, and the other two soon. Developers are flocking to smartphone app frameworks (a term we coined) to enable them to handle this dizzying diversity.

To address this today we announced Rhodes 1.4 stable production release. Among the many new Rhodes 1.4 features:

* support for a host of new Ruby gems in Rhodes: net/http(s), JSON, REXML (XML) , crypt, openssl, digest, lang, set, fcntl
* extension framework for adding third party extensions (gems) to Rhodes* API for returning screensize (write apps that handle the iPad gracefully!)
* native mapping for RIM BlackBerry (in addition to native mapping on iPhone)
* improved logging (from Ruby in Rhodes)
* support for the RIM BlackBerry 5.0 Java Development Environment
* a Mac OSX debugger (stepwise debugging in Ruby)
* improved spec running framework (do Test Driven Development on your smartphone! where else can you get that)

Support for net/http and net/https is being widely used to connect directly to backend sites. JSON and Rexml let you work with data on the device. The screensize API lets you conditionally handle different screensizes even better. Due to use of the browser component Rhodes excels at handling different screensizes. But having an explicit API makes it even better. The Mac OSX debugger for Rhodes allows you to debug your smartphone apps realtime.

In summary, Rhodes 1.4 provides a rich Ruby environment for native smartphone development. Write powerful apps once – compile to run everwhere. It offers a modern, productive development capabilities hitherto not available in mobile. Specifically interactive debugging, logging and spec-driven Test Driven Development is now possible in a framework which reaches all smartphones.

But we’re seeing a lot of the projects that enterprises exposes to consumers. These include claims apps for three different insurance companies that should all be hitting the market soon (I won’t steal their thunder by announcing them now). Consumers can use them to manage claims and other aspects of their vehicle or healthcare insurance right from their device. We’re also still happy by the Wikipedia app and its status in the top 100 public apps on the AppStore.

I met with Michael King of Gartner yesterday. He made the point that these apps were not “outliers”. The value that the Rhodes framework has that doesn’t exist in other frameworks (synchronized data, a Model View Controller paradigm, support for all devices, Ruby on the device and a hosted development environment), also apply to consumer apps. But the common thread is that the apps must be of a certain complexity and focus on data in order to necessitate most of these features (well certainly synced data, MVC and Ruby). Or you need it to go beyond two or three smartphone device operating systems.

If it’s a simple consumer “branding app” of a page or two, and its just for a couple platforms (iPhone and Android) its likely that either a small Objective-C app (rewritten for the other device) might suffice. Or you can write it in some other HTML framework such as PhoneGap since you don’t truly need the power of Rhodes sync or MVC or Ruby or multiple devices.

But for a wide swath of consumer apps you do care about hitting every available smartphone, you want a bigger hammer than just HTML and Javascript (such as Ruby on the device) and you want a more maintainable approach such as MVC for larger apps. Furthermore, though most App Store apps don’t use sync, the ones that do get a lot of differentiation in the sea of copycat apps that are appearing up there. For example, the claims apps qualify, location finder (of whatever: coffeeshops, restaurants, points of interest) apps qualify, anything where the user’s enter information (reviews, ratings, and pictures for annotation) qualify. How to describe these information oriented, utilitarian more complex apps for consumers.

How about “infotility?”. There was a category on feature phones called “infotainment” a few years ago. Infotilities are larger (more than one page), richer in capabilities (exploit what the modern smartphone can do, often sync or cache data and are often bidirectional.

So… thanks Michael. We’ll be sure not to ignore these consumer developers as you suggest. And let us know what the right category phrase is.

We think this has several implications for app developers:

• carriers appear to be less and less important to both phones and apps
• Android momentum continues to increase.  Developers focus on iPhone only at their own peril
• Even within Android this is not going to be the end-all phone. Plenty of people will prefer the keyboard of the very nicely featured Droid.

device diversity is only increasing

Specifically it predicts that Android will surpass iPhone in market share by 2012. It also makes a number of other interesting predictions. Specifically that BlackBerry will slip from second place to fifth place. And that Windows Mobile marketshare will increase.

What we’re seeing here at Rhomobile is that app developers (including the two thousand apps created on RhoHub alone in the last month) are starting to deliver more quickly on more than one device. For example, Track-R (mobilized PivotalTracker from Koombea) was delivered on both iPhone and Android. Aeroprise’s BMC Remedy Service Management app was delivered on BlackBerry first and then iPhone.

In the early days of Rhodes developers definitely appreciated the benefits of portability more strategically. But the primary benefit of Rhodes was productivity (its just several times faster and easier to write in Rhodes versus Objective C or Java in native SDKs). Nowadays, especially with Android becoming a major force, portability is top of mind of most of our developers.

Some people say “oh, you’re dual licensing like MySQL. So does that mean that I get to use it and not pay as I don’t with my MySQL based website?” Companies such as Google have thousands of MySQL servers running without paying license fees for it, due to a loophole in the GPL (in both GPLv2 and GPLv3) known as the “Google exception” or “ASP exception”. Specifically that access to your derivative work over http does not count as redistribution (or “conveyance” in GPLv3 parlance). It is for this reason that there Affero General Public License was created. Unfortunately for software vendors that have chosen to use the AGPL, it isn’t really accepted much as a widespread license. The Rhodes framework however is not subject to this loophole. So even with our status under a popular license such as GPLv3 closed source customers must purchase a commercial license for it.

Similarly the RhoSync server communicates with smartphone clients using a mixture of techniques: sometimes plain HTTP, sometimes the proprietary push techniques made available by various smartphone device vendors (e.g. the iPhone push SDK and the BlackBerry push SDK, or SMS as an alternative. So again the Google exception doesn’t apply and a RhoSync server commercial license needs to be purchased (write to our friendly reps for details).

It’s fine to release your project as open source as well. We love to hear about all projects done with Rhodes and RhoHub. So please tell us about your project. If you developed your project with Rhodes “offline” (not on RhoHub), consider getting a free RhoHub account and posting your code there.

There are in fact several high level alternatives, but probably only one practical one at a high level. Let’s start with the most seemingly obvious one:

Write natively in each underlying operating system’s SDK

For example, write your app in Objective C for the iPhone. Write it again for the BlackBerry in RIM’s slightly funky Java variant. Write it yet again for Android in their set of Java SDKs. Code it again in C# for Windows Mobile. And maybe get some reuse when you hack out a Symbian version for Nokia’s smartphones, popular in Europe and Asia.

I’ll actually accept that you might be able to write an app once with the native SDKs and languages for this set of smartphones. But I’ve postulated a theory a while back (when running backend and browser engineering at Good) that I’ll call Blum’s Law of smartphone development:

Businesses cannot maintain enterprise apps written individually for more than three smartphone operating systems past a 1.0 release

I’ll welcome comments that mention counterexamples to this rule. If you’re planning long term life for your app to address all your users, this is probably not a practical option.

Use First Generation “Enterprise Mobility Platforms”

There have of course been earlier approaches to the diversity of mobile operating systems. They emerged around ten years ago from the likes of Antenna, Dexterra, Vaultus, Plusmo and others. None of them got much more than a few dozen customers and much more than tens of millions of revenue. Although big corporations got benefit from them, they never came close to becoming ubiquitous enterprise infrastructure.

They all share a remarkably similar approach and set of components. Generally these are:

When these technologies first appeared there was nothing wrong with this approach. It allowed apps to run in fairly forbiddingly limited environments such as those on most featurephones. With the advent of modern highly powerful smartphones the interpreter approach to save space wasn’t really necessary anymore. But what sealed these technologies irrelevance was the App Store ban on interpreters. Instead of a “platform” that involved an interpreter to which apps are sent, a radically different approach was called for.

Smartphone App Framework

Last year we released the first version (0.1) of Rhodes calling it a “smartphone app framework”. The biggest difference is that the framework enables you to build native smartphone apps indistinguishable from what you might do with the underlying SDK. You can think of the framework as a library of code that you link into your app, a set of directory conventions for where you put your files and scripts to build the app. But, more excitingly, you can write your whole interface in HTML, the most widely known development technology in history. But you still end up with a NATIVE app that looks native and takes advantage of device capabilities.

Since then this has become a huge category with many entrants. These include WidgetPad, Appcelerator, QuickConnect, Ansca Corona, and PhoneGap. These frameworks are all a big step forward in productivity and finally allow the law that I cited above to be violated. They all also follow the practice of allowing you to write your interface in HTML. If you don’t need the synchronized data offered by Rhodes, the ability to have a full-on programming language (the first mobile Ruby for every smartphone) or the availability of Rhodes for all smartphones, each of these products is a good option. My personal favorite (if not using Rhodes) would be PhoneGap, but they are all a huge step above writing in native SDKs and languages.

This is informed primarily by my experience helping companies build smartphone apps for internal use using the Rhodes framework. Most of these smartphone apps are internal company apps for areas such as: helpdesk service requests, home healthcare patient service delivery, and CRM customer and product management. A few are on the App Store such as VDG Group’s Issues To Go for bug tracking and Koombea’s TrackR for Pivotal Tracker. To be clear, not all of the apps I’ve seen use all these guidelines (in particular one I’ve seen violated often even with Rhodes apps is “context sensitivity” below).

From these experiences helping our ISV and internal enterprise customers (and using their apps), I believe there are a number of areas that smartphone app developers for business should pay particular attention to.

Context Sensitivity

Don’t just a put a laundry list of activities (i.e. a “top menu”) at the top of your app. There should be a natural page that you can take your user to which has functionality. Typically this is a list of records. It might be a list of customers, a list of “stuff” (assets, products), a group of “issues” (tasks, bugs). Whatever it is that the app does. There can be other tabs at the bottom of the app that describe what the app does. Ideally the objects exposed on those tabs modify what you do with the original list of objects on the “home page” (or first tab). There should also be a tab for settings that controls the overall behavior of the app. If you find that you’re doing more than five tabs, the app is too diffuse. Write another app to handle the widening set of objects. Which raises the next point…

Start With A Single Task or Object

Indeed, in the early days of your app, just start with the ability to do a single task or work with a single set of data objects. It will take your users, not initially used to using apps for business on their smartphones right now, a while to absorb this capability.

Device Capabilities

Smartphones aren’t just “pocket-size PCs” (despite names like PocketPC and Windows Mobile). They have an amazing array of senses that are really an extension of their owner: sight (camera and video capture), hearing (audio capture), touch (the touchscreen), sociability (PIM contacts), direction (magnetometer), location-awareness (GPS). People generally don’t have or use these senses on their laptops.

Almost all apps I’ve seen can benefit from GPS and image capture. But most of them didn’t include such capabilities in their first envisioning. Even something as simple as a customer list can usually benefit from a proximity based sort when in the mobile sales guy’s hands. Consumer apps are usually thinking from the start to use these capabilities. Always think of how the unique capabilities of the smartphone device can enhance the application usage experience.

Local Data

Study after study has shown that mobile professionals aren’t willing to rely on the mobile device to do their job if they are concerned that they will lose their work. If you want your enterprise app to be actually used and interacted with remotely (not just used for reference) you have to give users the ability to use their information even when offline.

Consistent Branding

Early web apps attempted to look as much as possible like Windows apps. Eventually companies realized that it was better to maintain their own branding on those web apps rather than make them seem like desktop apps. The same thing is happening with early iPhone apps done by businesses today. The iPhone user experience for its own built-in apps is so compelling that many apps choose to make their apps like like Apple-shipped iPhone apps. For example, a company will show its customer list on the iPhone as an “extended contact form”. Typically its a bit of a force fit: the names aren’t quite the same and usually a company has more data than is present on the iPhone. The “make it look like the existing native apps” approach doesn’t scale out that well to a wide variety of business objects. It also loses an opportunity to create a consistent branding and user experience across multiple devices.

Regular Small Feature Delivery

The best smartphone apps do one thing and do it well. As you enhance your app you’ll want to beware of feature creep. Do small releases with one or a few features. Gauge what your users truly need next before launching on large groups of features. Ideally work with some toolset that allows very rapid iteration on the appearance of those features (Objective C for example may not meet the bar for this).

The good news for us is that RIM’s announcement is just part of a much larger trend. Nokia also does this with their Web Runtime toolkit. iPhone developers have many options to use web skills for rich native apps: either our Rhodes framework or frameworks such as PhoneGap, Corona, Titanium or Nimblekit. Android developers can write native apps with HTML using Rhodes, PhoneGap, Corona or Titanium. With third party JavaScript libraries such as JQTouch for iPhone and Android (which we highly recommend and use often in combination with Rhodes apps) such apps can have all the animated pop and dazzle of something you might write in Objective C. Without the pain of throwing away 25 years of progress in more advanced programming languages.

To take a closer look at what RIM has delivered it does appear that it’s still a subset of what we offer with no camera support and no native mapping. The big difference however is that we’re the only framework available for all smartphones and the only framework that provides synchronization (an easy way to enable current information to be available locally on user’s devices even when they are offline). I’m excited about seeing BlackBerry developers use the Widget SDK to learn “web-based for native” and then be that much more ready to use our framework on other devices and to upgrade what they’ve done for BlackBerries to be true enterprise apps, complete with synchronized data.

But that said, we may have been underestimating the benefits that Ruby has for mobile development irrespective of the Rhodes framework which uses it. Ruby has compelling advantages for building smartphone apps that are worth describing in their own right:

If you’re not using Ruby today for web development, we strongly urge you to consider it (our RhoSync server is a Ruby on Rails app of course). Ruby on Rails can be used productively by relative Ruby novices (although being a programmer comfortable with the Model View Controller pattern certainly helps conceptually). If you’re not using Ruby for mobile development, we’d encourage you to consider the Rhodes framework. If you’re uncertain about your ability to do so without Ruby skills, we’d encourage you to try it regardless. As an MVC framework most of your UI will be done in the views as HTML templates anyway. Our RhoGen app generator creates the Ruby code for the controller, which does basic Create, Read, Update and Delete of synchronized data on your phone right out of the box. But you can also use this controller code to learn Ruby, modifying and extending the code slightly as time goes on.

Since we first shipped Rhodes last December, we’ve been happy to see other mobile Ruby implementations emerge. Pragmaticomm has developed a mobile Ruby for Symbian. We’d like to eventually merge our Ruby with theirs. Charles Nutter has an Android version of JRuby well on its way to completion. Once it is complete we’ll take a look at the size and perhaps adopt it. I also talked with Matz at this year’s EuRuKo about factoring out our mobile Ruby implementations and getting it merged with general 1.9 development (this would save us ongoing work of course).

Otherwise today Rhodes is the only way to do Ruby development on the leading US smartphone operating systems: iPhone, BlackBerry, Windows Mobile. But because of the advantages of Ruby listed above, I have no doubt that will change and all smartphone operating systems vendors will eventually ship their own mobile Ruby implementations. That’s OK as we really are the “open mobile framework” company not the “mobile Ruby” company. But helping you developers build apps faster by providing you that mobile Ruby implementation now instead of years into the future is an exciting privilege.

I’d like to predict a new category to beyond the device side “smartphone app framework” that I think will emerge over the following year: the “enterprise smartphone server”. One of the things that we’ve learned in working with enterprises mobilizing their apps is just how important synchronized data is to all of them. So we’ve emphasized development of the RhoSync server, adding features to take advantage of recently emerging smartphone APIs (such as the push SDK) to optimize synchronization performance and recency, enabling selective synchronization, and allowing background sync on the server (also known as paged query).

Our belief is that every enterprise will be mobilizing several of their applications: CRM, field service, helpdesk, and one or two line of business apps (especially in certain industries such as healthcare or manufacturing or logistics). They will always want the data from those applications available on their employees smartphones whether or not its disconnected. We believe that every enterprise will thus need a smartphone synchronization server to facilitate this. With RhoSync, we believe that we’ve achieved this. And, given our support for recent smartphone push SDKs, we’re alone in this new space.

But just as there are now several other smartphone app frameworks to write native apps one time for multiple devices, we know that eventually there will be competitors. We don’t think its likely that they will come from “old line sync servers”. Most of those are dormant: Nokia discontinued IntelliSync, Motorola cancelled Starfish. Others come from “first generation enterprise mobility” players such as Sybase, whose technology is not acceptable on the iPhone (because it requires a downloaded “runner” or “interpreter and is thus not acceptable on the AppStore).

We do think that there are other “enterprise server helping smartphone app” needs that we aren’t quite addressing now. The biggest ones are device manageability, security, app provisioning, and analytics. Sync is the biggest need now and its what RhoSync and the runtime of RhoHub currently offer today. We do want to make all aspects of mobilizing apps to smartphones very easy for enterprises though. Over time the RhoHub hosted service and our mediating server RhoSync will add other enabling capabilities (sometimes through partnerships with existing technologies). RhoSync is thus the first “enterprise smartphone server”, but we think there will be many others.

Given the explosive growth and emerging ubiquity of smartphones, fullfledged computers in every enterprise employee’s pocket, we see this as the most important new enterprise middleware category since the app server and the relational database server. What BEA did for app servers and Oracle did for relational database servers, we intend to do for this new category.