Category Archives: Rhodes

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:

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.

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

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:

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.

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.

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.

simplified licensing

Today we announced simpler commercial license terms for our Rhodes and RhoSync products. Why did we change it? The previous license was fairly standard for embedded technology licensing: 5 percent of whatever you sell. Just a few years ago, the presence of an open source Gnu Public License alongside a commercial percentage-based license would have worked. You want to make a free app? Open source it under GPL and you owe nothing. Want to charge? Just give us a percentage.

In 2009 however this won’t work anymore. There are too many companies distributing “free apps” but who don’t want to open source them. And they intend to make money but in rather complicated ways that are difficult for anyone to really quantify. For other customers, they said “I don’t know exactly what I’m going to charge, but I need to know what I’m going to pay you regardless”. We needed a simple way to buy a commercial license for all of these customers.

So our new terms are:

- The Rhodes framework alone is $500 per application for an unlimited number of users

- The RhoSync Server (not required to be used by Rhodes applications but very commonly used) is $5000 for 100 users. It scales logarithmically with increasing users: 1000 users is $10,000. 10,000 users is $20,000.

Either license entitles customers to a year of free updates. You can use the last free update of Rhodes and RhoSync indefinitely for no further purchase. If you want to stay current, maintenance is 40% of the original price ($200 per year to stay current on Rhodes, $2000 per year to stay current on RhoSync).

Positive response to the new license is almost unanimous. We have had a handful of enterprise ISVs who were used to 5% embedded licensing who seemed to prefer that offer as it fits into the spirit of our partnership. Our whole goal is to make you, the mobile developer, as successful as possible, and share in a very small way in that success. It turned out on running the numbers that the actual pricepoints for those vendors ended up being very close to the new pricing (they were all RhoSync Server users).

For developers who want to use Rhodes only, the new license terms of $500 for a single app with unlimited users is of course a huge bargain compared to the old terms. We believe that when developers understand how much synchronized data can improve their user’s experience (and hence their sales) almost all developers of enterprise or informational applications will use RhoSync. “Rolling your own” mobile sync framework is just not a practical option (especially as you start to appreciate how we’ve taken advantage of things like iPhone and BlackBerry push to create super-optimized sync).

Anyway, for those of you that want a very inexpensive crossplatform smartphone app development framework, we’ve got a great deal for you: $500 to improve your productivity for even one device by a factor of five (multiply that by the number of device operating systems you want to support). We know that eventually you’ll want to use RhoSync as well.

App Store rules

The iPhone and the Apple App Store have been THE critical agents in changing the mobile consumer’s attitude with regard to mobile applications. Specifically they have converted virtually all smartphone users (beyond just the iPhone) to wanting and expecting to use native apps on their mobile devices. This is a huge sea change in behavior, especially for U.S. consumers. As enabling technology for building smartphone apps, we (Rhomobile) are hugely grateful for the investment that Apple made here and resulting success of this new category of software. I also personally appreciated how it has eased my life and the world in general (subjects of future blog posts unto themselves)

Part of the value proposition in the App Store’s success was that Apple would test the apps and insure that they did what they said they would and nothing more. This is critical. We take for granted native mobile app usage today. But as recently as two years ago, people did not want to download mobile apps to their devices. The App Store’s guidelines and testing and implied guarantees were critical in gaining consumer acceptance of downloaded apps. In order to make these implied guarantees, Apple needed to make restrictions on how such applications were built. Some of these restrictions were on enabling developer technology. We think these restrictions are reasonable and have architected Rhodes from the start to stay within both the letter and the spirit of Apple’s guidelines.

We believe that:

1) the App Store’s restrictions on iPhone application’s use of enabling technology are actually totally reasonable.

2) Rhodes is clearly acceptable enabling developer technology that stays within both the letter and the (reasonable) intent of the App Store’s restrictions

Specifically the iPhone App Store’s Rule 3.3.2 states:

An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

This paragraph contains two key points especially with regard to a framework such as Rhodes. The most often-referenced issue is “no interpreted code may be downloaded“. Note the emphasis on “may be downloaded”. Sometimes this is misinterpreted as “no interpretors”. No, the issue is that if you download code to an interpretor then there is no way to know just what an application really does since it could change daily. Clearly there are many apps that are based on some form of interpretor. The important thing is to not download code to those interpretors, because this invalidates any attempt to test what the application does.

There is an exception to this “downloaded interpreted code” ban of course. That is, use of JavaScript within a browser control. It’s a very popular technique to use the iPhone SDK WebUIView control to quickly create user interfaces in HTML or download content from an existing external web page. Many of such existing web pages however contain JavaScript. So loading those pages would violate the “downloading interpreted code” ban. In this area, Apple seems to be exercising discretion and allow such apps when the clear intent is to just reuse existing web content to good effect.

However, there are efforts to make downloaded JavaScript much more of an “app development tool” by providing robust device and UI capabilities. Or even to allow app business logic to be embedded in JavaScript calls. In my opinion, such frameworks do violate what Apple is trying to accomplish by insisting that an application’s functionality cannot be changed after it is installed. And that Apple is in fact being reasonable by calling such capabilities questionable.

By contrast, within Rhodes we should make clear that such dynamic behavior is not possible. Rhodes does in fact contain an implementation of Ruby. However, it embeds a mobile optimized Ruby 1.9-based intermediate bytecode executor that operates on precompiled Ruby code. Also, for good measure, we have eliminated the ability to do dynamic creation of code (such as removing “eval”). We want to make sure that application developers can only create applications with behavior that is known a priori. And that they do not have the ability to inadvertently create violating apps. Given that we are well known to the App Store and have never had an app denied, it appears that these extra efforts were worthwhile.

The second issue is that “an Application may not itself install or launch other executable code”. The key thing is the ban on launching other executable from your own executable. It does NOT mean that you can’t use a “plug-in architecture, call other frameworks or call other APIs”. That would be absurd and its doubtful if any apps would pass that muster. It means that you cannot use other enabling technology (runner, plug-in, framework, API) that is delivered as compiled executable code. Examples of such technology include Adobe AIR/FlashLite/Flex, Google Gears, any JVMs. The reason for this is that if a developer is going to be truly responsible for the full gamut of his or her functionality he needs to be able to see the source for all of his resultant executable code. This is not possible if he is in effect just calling another executable. This is why we always knew we would open source Rhodes. A Rhodes-based app is just like any other iPhone app, with, in effect, some extra source code that we have provided to the effort: a sync client, a Ruby intermediate bytecode executor, and a small Object-Relational Manager. It is merely an accelerant to a developer’s own efforts by providing a headstart with some source. If it didn’t exist, many developers would build their own equivalents of several of the pieces we provide.

In summary, we think guidelines on what applications can do on mobile devices (from Apple or elsewhere) are good things. Rhodes will continue to make it easy to build rules-compliant apps for the App Store and other app marketplaces.

SDForum: Trends in Mobile App Development

On Friday, I had the pleasure of participating in a panel at SDForum’s Developer Conference on trends in mobile application development. Alongside representatives from Sun, Nokia and others, we discussed emerging ways that mobile apps were being built. Two in particular seemed to capture the panel’s interest:

high level, declarative development

the success of HTML for web development provided a much more productive, portable, and powerful way of developing apps. Declarative development through either HTML or XML is emerging as a way to develop other kinds of apps as well: both rich desktop apps and mobile apps.

For desktop software, often known as Rich Internet Applications (RIAs), this is evidenced by technologies such as Adobe Flex (an XML for RIAs) and Titanium’s AppCelerator. For mobile software the category is even more nascent, and examples include Rhodes, PhoneGap, and Nokia’s Web RunTime (WRT) for Series 60 devices.

pushing computing to the edge

In the early days of computing, apps were primarily centralized on mainframes and minis, and accessed remotely by users. The advent of personal computers in the 1980s enabled a new generation of locally hosted and used applications on individual’s own desktops, spawning an exciting new array of capabilities. The dawn of the web in the 1990s created a swing back toward many “centralized apps” accessed by ubiquitously available web browsers. Finally in the last few year the explosion of smartphones as fullfledged computing devices has created yet another new generation of applications, that take advantage of these device’s new capabilities by executing locally on devices again.

The Rhodes framework is a great way for developers to take advantage of both of these trends.

1.0 Out and 1.1 Plans

Two weeks ago we released 1.0 to far greater than expected press and customer uptake. Frontpage stories on CNet, VentureBeat, InfoWorld, ArsTechnica and others, with very insightful analysis (although a few other articles confused us with a mobile web development solution because of our use of HTML to create views). Ryan Paul from ArsTechnica even wrote his own Windows Mobile app. Plus we’ve had several of our developers submit apps to the iPhone AppStore. VDGGroup released their IssuesToGo app – a mobile frontend to the popular LightHouse bug tracking that we’re happily using at Rhomobile to stay on top of our bugs. Wikimedia submitted their 1.0 based iPhone Wikipedia to the iPhone AppStore and will later move it to Android.

So 1.0 is out and now supports all shipping smartphones. Plus we have all the most important device capabilities (at least for enterprise app scenarios) covered. So what are we doing in the next release? 1.1 is slated for release in mid-May at Interop in Las Vegas. What’s new in 1.1 then? We are doing a lot of work to provide robust testing frameworks to enable developers to test their apps well. This includes providing the long asked for “desktop version of Rhodes”. You’ll be able to test your Rhodes app right from your Windows laptop without running an emulator.

We’re also doing a lot of performance work. This includes faster startup time for iPhone (already checked into the 1.1 unstable branch of Rhodes). It also includes faster data synchronization. One of the features is the ability to handle very slow backend apps by allowing queries to be queued and handled completely asynchronously (the queued sync option for a RhoSync source). This is also checked into RhoSync edge. There are several other RhoSync server and client performance improvements underway as well.

We’ll always add device capabilities in each of our point releases. For 1.1, by request of some Rhodes developers, we’ll be adding video play support.

But the biggest feature for Rhomobile coming over the next month is opening up the private beta of RhoHub. Explaining RhoHub however is a much bigger blog post to come.

mobile enterprise apps continue to be brightspot in the technology industry

As reported by InfoWorld and many others, Evans Data just announced their survey of 400 commercial app developers which shows that “94 percent of corporate developers expect development of wireless enterprise applications to either increase or stay the same in the coming year”. And this is all against the backdrop of the stunning complexity and fragmentation that mobile app development is subject to without a framework like Rhodes. One of the most interesting points of the article is how much things are moving to a more diverse and fragmented set of device operating systems:

Market adoption of Windows Mobile remained flat, with 33 percent targeting it as opposed to 31 percent in the mid-2008 survey. Apple’s iPhone jumped in the survey from 8 percent eyeing it six months ago to 20 percent in the new survey…Google’s Android rose to 18 percent in the new survey after registering with 7.5 percent of developers in the last survey.