the gPhone arrives

Google has finally admitted, and the pictures are finally appearing of their own branded Android phone, called the Nexus One. It will be keyboardless, slighter longer than the iPhone and thinner. It will also not be tied to any particular carrier.

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.

0 Comments | Posted by admin

device diversity

The latest Gartner report on future smartphone market share was an interesting read, as reported by Register Hardware. It fleshed out what we’ve been saying for a while:

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.

0 Comments | Posted by adam

GPL and dual licensing

We’ve had over a thousand customers sign up to the RhoHub service over the last month since we launched on November 4th at the iPhone Developer Summit. They are now asking “ok I’ve built my app really quickly. Now what do I need to do to distribute it on the App Store or elsewhere?” We ask that you either open source your app by making the source public and putting a GPLv3 license on it (we’ll automate this latter step soon). Or purchase a commercial license if you want to keep your source private.

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.

0 Comments | Posted by adam

building smartphone apps – the alternatives

Smartphone apps are the most exciting trend in computing since the advent of web apps. How do you as a developer take advantage of this? More generally, how do you do that and get maximum reach for your app across the diversity of smartphones out there. If you’re writing a consumer app you can get away with just targeting the iPhone (albeit missing some market opportunity). If you’re writing a business app you need to be able to reach all the users in the enterprise. There just are no homogeneous mobile device environments in any place but the smallest mom and pop shops now.

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:

• an Integrated Development Environment (IDE) – design the screens for the app in a desktop editing environment generally with some kind of WYSIWYG preview. And (for some) describe the connections to a backend data source.
• a “runner” or “interpreter” on the device. This runner is built by the vendor for each device operating system. It generally included featurephone operating systems including J2ME and BREW.
• sync server – Sometimes this is general purpose (such as IntelliSync). Sometimes this is just common code shared among “backend connection server apps” (such as Antenna)

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.

2 Comments | Posted by admin

best practices in smartphone business apps

Friday I’m speaking at the Mobile 2.0 conference in Mountain View. The topic is “iPhone for Business”, which, if I took the topic literally, raises many issues about distribution and maintenance of smartphones in the enterprise. But I’m really just going to focus on the narrower issue of “iPhone apps for business”: how do you build compelling and useful smartphone apps for enterprise information?

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).

2 Comments | Posted by admin

“web development skills to build native smartphone apps” – the ruling trend

Yesterday RIM announced their Widget SDK. We’re excited about about this at Rhomobile because it is further validation of the strategy to utilize developer’s web skills to build great native apps. We often find ourselves having to explain “yes – it does let you write your interface in HTML, CSS and JavaScript. No – it’s NOT a mobile web app. It’s a true native app”. It’s great to have RIM out there helping to explain the power of using familiar, productive declarative web-based programming skills to build apps that run local on the device and fully leverage the full power of the smartphone.

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.

0 Comments | Posted by admin

the first mobile Ruby

Our open source framework Rhodes contains the first implementation of Ruby for every major smartphone operating system: iPhone, Android, BlackBerry, Windows Mobile and Symbian. The primary benefits of the Rhodes framework are: the productivity and portability enabled by writing interfaces in HTML once (and compiling to native smartphone apps), access to device capabilities from a common library used on all smartphone devices and the ability to easily incorporate synchronized data for offline use.

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:

• scripting language. Everything from implied (duck) typing to easier creation of classes and functions to built in support for regular expressions result in much higher productivity

• economy of expression. Ruby apps are often less than a third of the size of equivalent Java apps. This helps to make apps easier to maintain even after the initial productivity boost. We’ve found that the best mobile apps are small apps. HTML for UIs helps enormously to minimize code size. Ruby for controllers helps make sure that economy gain isn’t lost. The result is that Rhodes apps are usually less than 20% of the size of underlying SDK apps (e.g. Objective-C apps)

• rapidly growing programmer base. O’Reilly estimates over 50% year over year growth, by far the fastest

• rich ecosystem. On GitHub, RubyForge and elsewhere Ruby gems and plugins abound. The success of Ruby on Rails has spurred a huge industry of addon capabilities that can be leveraged by mobile developers using Rhodes as well

• pure object-oriented design. This makes it easy to build both an overall framework on (such as Rhodes or Rails), and also develop libraries for

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.

0 Comments | Posted by admin

the enterprise smartphone server

Rhodes is a great option for allowing developers to write their smartphone apps one time and have them run natively on all devices. After being out for a while several competitors emerged and now we have a product category known as the “smartphone app framework”, with several participants. We believe that our first mobile Ruby, our fullfledged MVC framework, our hosted development site RhoHub and, most importantly, support for synchronized data, are longterm differentiators. But in such as a nascent area its better to have some other players out there helping us educate the market.

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.

0 Comments | Posted by admin

use your web dev skills to build NATIVE smartphone apps

I’ve been speaking at a lot of Ruby conferences over the past few months (almost every one). The attendees of these conferences are almost all web developers. They see that the big growth opportunity in software today is writing native smartphone apps (not mobile web apps, a category that the App Store has basically killed for many good reasons). But they are worried that they have to learn specialized arcane skills such as Objective C and the iPhone SDK, or Java and the Android SDK or C++ and, if they are outside the US, the Symbian SDK in order to be productive writing such apps. Learning any of those skills individually is a daunting task. The combination of them is well nigh impossible in a timeframe sufficient to actually release an app for today’s marketplace.

There is an alternative: a “smartphone app framework”. When we released the first version of Rhodes last December we coined this term. To our delight a robust marketplace has emerged of such tools as reported by InfoWorld recently. Flavio Ishii recently blogged on this phenomenon as well. Smartphone app frameworks let you write your user interface for NATIVE apps (NOT mobile web apps) using HTML, JavaScript and CSS. The user has no idea that these were build with an embedded browser component.

CSS is used to style the HTML to look native. Joe Hewitt pioneered this approach prior to Rhodes existing, with his IUI library. Rhodes ships with CSS libraries for iPhone, Android, Windows Mobile and BlackBerry to make the HTML look more native very much inspired by IUI. But developers can use third party libraries such as IUI or IWebKit by just adding them in the CSS directories of their Rhodes project. Smartphone app frameworks all provide some method of accessing native device capabilities. For Rhodes this is a combination of JavaScript libraries and Ruby libraries.

Today Rhodes goes beyond other smartphone app frameworks in several areas:

• support for all popular smartphones
• the first mobile Ruby implementations running on all smartphones (HTML is great for the interface, but having Ruby far more powerful than trying to write your whole app in HTML and JavaScript)
• the only smartphone focused sync framework (client in Rhodes and separate RhoSync server) in the industry

Discussion of each of those differentiators are worthy of their own posts.

0 Comments | Posted by admin

app stores for all major smartphones now live!

Yesterday Microsoft announced that the Windows Marketplace for Mobile is accepting applications. This is a great opportunity for mobile developers. Combined with BlackBerry AppWorld, Android Market and Nokia Ovi Store there are now marketplaces available to facilitate distribution to users of every major smartphone. This is a great opportunity for developers. There is now a place to highlight the availability of their app, that doesn’t rely on consumers finding out about you and your app directly. Just create a great app in a category of a consumer needs and they’ll find it.

It does beg the question however: is there sufficient consumer demand on any of these one platforms (with the possible exception of iPhone) to justify writing an app for just that one platform. This is where we are seeing the most demand for the Rhodes framework: the need to create a great app that spans all smartphones that user’s may choose to carry. With Rhodes you can do this: write your app once and Rhodes allows you to instantly build native apps for each of those device operating systems and their associated “app store”. While there are a couple of other approaches to doing both iPhone and Android apps, we are not aware of any way besides Rhodes to write a single set of code and build native apps for all major smartphones: iPhone, Android, Windows Mobile, BlackBerry and Symbian.

0 Comments | Posted by admin