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.