Rhodes 2.0 Released! Rhodes apps continuing to be accepted on App Store

Yesterday was an exciting day in RhomoVille. We released Rhodes 2.0. As announced at the Web 2.0 Conference (where we won the LaunchPad award) Rhodes 2.0 is now FREE under MIT License and has many new exciting features:
- native mapping on all devices -we have implemented the best of breed iPhone style native mapping for all devices. You can get the iPhone-like zoomable, linkable, annotable native maps
- robust support for direct web services connections – Your Rhodes app can talk directly to your backend system via http and https (retrieving XML and JSON)
- a “metadata framework” – This allows you to work with enterprise application backends that have arbitrary schemas. This is typical with large ERP and CRM systems such as SAP or SugarCRM as deployed in real enterprises. Instead of hardcoding pages and forms for the business objects you write your pages to work against the metadata describing an objects fields, labels, and data types. This allows you to handle changing schema. Logic Appeal used this in their Rhodes app for SugarCRM now deployed at customers.
- and many other features

There are recorded webinars on all of the features of Rhodes on our Vimeo channel (this Friday’s webinar is on PIM contacts and alerts).

And just an update for many of you because you asked, Rhodes apps are continuing to be accepted on the App Store (as we indicated they would be) even after the iPhone 4.0 Terms of Service went into effect. Some of the recent apps accepted include TrackR 2.0 (a free app for PivotalTracker), Metalingual (an app for language translation from Sarah Allen), WorshipPlanner, and iFirefigher.

We’re looking forward to seeing many more Rhodes 2.0 apps from all of you. Drop us a line to tell us about them.

1 Comments | Posted by adam

“but isn’t HTML5 enough?” – why mobile usage will always be about native, not web, apps

I’m here at RailsConf 2010. What a great place to talk to current and prospective Rhodes developers! Rails developers all get why its important to have a full Model View Controller framework. They also get pretty excited about the presence of the first mobile Ruby on every smartphone device. Rails developers get the value of Rhodes deeper than any audience I’ve encountered.

A couple of the other talks, from otherwise insightful web framework developers, who apparently have “smartphone envy”, were disturbing. One speaker talked about his efforts to make Rails a little better for iPhone browsers accessing it as enabling “mobile apps”. This is a bit ludicrous now because users clearly prefer to run local native apps on their device versus accessing websites, especially for anything they use more than once.

One theme I’ve heard (again more from people pushing their web framework enhancements than from app developers, web or otherwise) is “once HTML5 is commonplace on mobile browsers that will all change and users will prefer browser-based apps”. So let’s take a look at this theory more closely:

First of all we should clarify that advances in HTML are unambiguously a great thing for mobile, whether for true native apps (such as those created by Rhodes) or mobile web apps. Rhodes uses HTML, CSS and JavaScript for its user interface rendering (as do other smartphone app frameworks that have followed us into the space). The richer the HTML capabilities, such as the extensions available in HTML5, that are available the better all such framework apps can be.

But of course HTML5 support on mobile devices also allows better mobile web apps. HTML5 supports storage to the device database. It also provides geolocation. So does that mean that mobile web apps are poised to become things that smartphone users interact with primarily? That won’t happen for several reasons:

device capabilities

Although geolocation is now present in HTML5, smartphone device capabilities are exploding by leaps and bounds. Smartphones pretty much all support: interaction with PIM contacts, camera, accelerometer, magnetometer, push, and native mapping. It will be many years before these capabilities show up in a W3C proposed standard and many more years before a smartphone browser implements them. If you have any doubt track how long it took from the proposal for HTML support for database storage to take effect (first floated in the 1990s). By that time there will be many more device capabilities as smartphones continue to evolve at a furious pace.

synchronized local data

It’s one thing to say that you can store some information to a table, or even cache it. It is quite another to intelligently, incrementally and efficiently synchronize that data to connecting devices so that information can be used offline. For purely one way data, automatic caching has its place with some more unstructured data apps and sites (such as news reading and social networking). For more structured bidirectional data the ability to store a record locally via HTML and JavaScript isn’t providing much compared with the ability to truly synchronize structured data bidirectionally. That typically is going to require some significant logic on the device.

offline usage

But even if the app isn’t information intensive it is critical for the app to be able to be used offline. All modern smartphones today are “occasional connected”. But its rare today (and will be for a while) for a device to have 100% reliable connectivity all the time. Users want apps that they can use whenever they want to, wherever they are. That is a big driver of the success of the App Store. Its just not possible with a mobile web app.

Its great for both users and developers of both mobile web apps and true native smartphone apps that HTML5 brings more capabilities to the table. But if you are a developer who wants to get the most usage of your app the maximum amount of time from your users, you’ll want to provide them with a native app.

Most refreshingly if you use a framework like Rhodes, you don’t have a big dilemma. You can use the power and productivity of HTML5 in your Rhodes views and still deliver the usability and ubiquity of a true native app.

1 Comments | Posted by adam

Rhodes 2.0 and Web 2.0 Launchpad

This was a big week for Rhomobile. On Tuesday morning we announced the public beta of Rhodes 2.0 at the Web 2.0 conference. Rhodes 2.0 has several major new features:

• streaming bidirectional High Definition audio and video (to and from the device)
• a “metadata framework” which lets software developers write apps that work with enterprise applications that do not have fixed schemas or database structures
• a much faster sync server
• our own comprehensive styling library that provides optimized interfaces on ALL smartphone devices.

Sign up for the beta today!

We were also very surprised and pleased to win the Web 2.0 Launchpad award yesterday.   This was given out by audience acclaim (a “Clap-O-Meter”) and seems to be validation that our message of “use your existing web development skills to write native apps” has resonance among web developers.     In particular, based on booth traffic and feedback, this audience of modern web developers seemed to really appreciate the industry’s only Model View Controller framework for smartphones.

0 Comments | Posted by adam

Rhodes in the Future

As mentioned in our previous post we believe that we are compliant with the new iPhone 4.0 SDK rules, and we believe Rhodes apps will continue to be to be accepted on the App Store after adoption of the new TOS.

But to make sure our loyal developers are 100% safe in using our framework, we will be announcing some new products soon that facilitate enterprise app distribution for iPhones and other devices, completely bypassing any App Store. These products will ensure that Rhodes remains the go to framework for cross-platform development on all major smartphones.

Finally we will be taking our RhoSync sync server and forthcoming server products and supporting client apps written in Objective C. Even prior to the latest iPhone 4.0 TOS controversy we had many Objective C developers asking to be able to use our sync server. We will be providing a C++ library usable from your Objective C apps to provide your users with the convenience of synchronized offline data. We will also be providing an Object Relational Manager that is usable from Objective C that allows you to work with data intensive apps without working with SQL

In summary your investment in learning the Rho toolset will be maintained regardless of future App Store testing procedures, especially if you are an enterprise app developer.

1 Comments | Posted by adam

iPhone 4.0 SDK rules

Yesterday Apple released the iPhone 4.0 SDK into beta. This release has stirred up quite a bit of controversy due to the terms of service contained there. We believe that we are in compliance with the new terms of service in the iPhone 4 SDK. Specifically with Rhodes apps developers must install the Apple iPhone SDK before using Rhodes to create their app. We generate Objective C and require that XCode be installed and executable on a Mac to perform the build. Apps cannot be submitted to the App Store without using XCode to do signing.
.
As we have in the past we will do everything that we can to comply with Apple’s rules. This is why we did not allow dynamic evaluation of code in our apps and why we never performed hosted build for iPhone’s online. Our engineering team will continue to do everything we can to insure that you can create iPhone apps that are compliant with all iPhone SDK and App Store rules.

1 Comments | Posted by adam

what’s so special about the Rhodes smartphone app framework?

When we first released Rhodes framework in the fall of 2008, we called it a “smartphone app framework”. Use your web development skills (HTML, CSS, JavaScript) to write native smartphone apps completed with rich device capabilities such as GPS for geolocation, PIM contact access, camera capture and more. Make it easy apps to provide their users with local data for disconnected offline use. And provide this capability across all smartphones.

We always knew that the base “write HTML/CSS/JavaScript to generate native apps” category would explode. Because it is so clearly the right way to rapidly write apps across multiple devices. And it has: there are now seven players in this base category including PhoneGap. Rhodes has several major architectural aspects that differentiate it longterm from all of these entrants.

ONLY MODEL VIEW CONTROLLER FOR SMARTPHONES
Rhodes is the only framework that uses the Model View Controller pattern. You can write just HTML, CSS and JavaScript to do all of your app. In effect, writing your entire app in the View. If you do this Rhodes is just like all of the imitator frameworks.

But the value of a Controller and use of MVC is very real. It is theoretically possible to write a web app or website with HTML, CSS, and JavaScript and no backend logic, putting all of your logic into JavaScript in the page. But this NEVER happens for an app or site with any complexity whatsoever. All web apps have some backend: either Java or PHP or ASP.NET or Python or Ruby. That is what the Rhodes MVC framework gives you for native smartphone apps: the ability to write real business logic in your local native app on the device.

Rhodes is the only framework with MVC support. This explains why there are so many robust enterprise apps written with it something missing entirely with other frameworks. Rhodes enables you to take modern web development and enterprise app development goodness and apply these best of breed techniques to building native smartphone apps.

ONLY OBJECT-RELATIONAL MANAGER FOR SMARTPHONES
In 2010 ORMs are the way that web developers interact with databases. In web apps it’s rare now to see direct SQL calls. And that’s a great thing for developer productivity and reliable code. Rhodes features the only ORM for native smartphone apps, whether from frameworks or even direct smartphone OS SDKs.

ONLY FRAMEWORK WITH SYNCHRONIZED OFFLINE DATA
This is the ability, provided by the Rhodes framework combined with the RhoSync server, for apps to make data available to their users when they are offline and disconnected. Rhodes is the only framework to offer sync. Doing sync servers well is a very nontrivial effort (far larger than the effort to build a HTML/CSS/JavaScript framework) so this is likely to be true for some time.

The availability of data when disconnected and the ability to transparently synchronize with a backend app have been shown time and again to be necessary to making enterprise users comfortable with transacting from their devices.

SUPPORT FOR ALL DEVICES
Rhodes supports all smartphone device operating systems as first class citizens: iPhone, Android, BlackBerry, Windows Mobile and Symbian. Symbian support was held in abeyance at 1.1 but will be caught up in the 2.0 release soon. WebOS support is underway. There will be more smartphone operating systems emerging as well including Intel and Nokia’s Meego OS. Rhodes has always led in the device OS support area and will continue to do so in the future.

FIRST MOBILE RUBY
Much of the benefit of Rhodes would be achieved no matter what we chose for the language that is used in the Controller. But Ruby is very understandable, terse and powerful and the world’s fastest growing programming language. We’ve seen Java shops and .NET shops enthusiastically embrace Rhodes.

We built the first Ruby implementations for every smartphone device operating system. There is now a Symbian Ruby available as well from Pragmaticomm. And there is also a JRuby implementation running on Android (our Ruby is C-based and hence smaller and faster). We actually look forward to the day when Ruby implementations will ship with all phones. Our value is in the entirety of the framework and supporting servers. But in the meantime providing an advanced dynamic language like Ruby on the device is pretty exciting to many developers.

HOSTED SERVICE FOR DEVELOPMENT
Rhodes provides the world’s first Development as a Service for mobile. You can write your apps online on RhoHub. In effect we give you a web-based Integrated Development Environment. We also let you do builds for all smartphone operating systems online. Finally at runtime we host a sync server for you and app provisioning is under development.

We do tell developers that if they don’t need ANY of these capabilities they should consider a simpler framework such as PhoneGap. That said we have yet to see an enterprise state that none of these differences were relevant and choose another framework.

Our lead over imitator frameworks is very large and growing larger. Over the next few weeks we’ll unveil some of the new features that are even more exciting than these major differences.

0 Comments | Posted by adam

Mobile World Congress: crossplatform diversity only accelerating – Rhodes 1.4 released!

There were many exciting announcements today at the Mobile World Conference in Barcelona. The biggest ones all emphasize just how much crossplatform diversity is here to stay and the diversification is only accelerating.

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.

1 Comments | Posted by adam

informational, utilitarian apps for consumers: “infotility?”

I was pleased to see today’s article in Mobile Enterprise Magazine on open source for mobility. It was great to see Rhomobile recognized again as the leader in smartphone app frameworks for the enterprise. This includes apps such as Aeroprise’s mobile BMC Remedy and OpenHealth’s mobile SugarCRM.

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.

0 Comments | Posted by adam

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