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.

3 Comments | Posted by admin

EuRuKo and device capabilities

Yesterday I had the pleasure of speaking at the superb European Ruby Conference in Barcelona. It was fascinating seeing the enthusiasm of the audience for Ruby and the technologies presented. I also got to talk to several attendees about their own Ruby efforts. The most interesting chats that I had were reminders of how device capabilities on mobile are constantly expanding. This will be a constant thread and area of continued development and innovation for Rhomobile.

For example, I talked to Bart ten Brinke and other developers from Nedap Healthcare about their mobile home healthcare monitoring and timekeeping software. It runs via the builtin RFID on the nurse’s mobile. They swipe the patients card over the phone to check in and check out during their visit. Right now it’s only J2ME based for Nokia’s Series 40 RFID-embedded featurephones. But the forthcoming RFID support in various smartphones, including several accessories for the iPhone, plus support for RFID in Rhodes, would enable a much more powerful (far beyond just timekeeping with patients) suite of similar apps for the iPhone.

I also talked with Jason Goecke of AdHearsion after he did a superb talk on voice-enabling apps. I really like following great speakers as they get the audience woken up and ready to process even more information (this phenomenon contributed to our mutual five star ratings). Like Rhodes, AdHearSion is a Ruby-based framework that makes it easy to buid server apps that do voice and IVR processing for apps such as phone-based customer support systems.

The possibilities of doing interesting applications with data on the smartphone but allowing the user to voice drive a backend app via a smartphone are pretty extensive. Imagine the customer/user interface for a CRM or issue tracking system and then invoking “reach out via voice” totally within context that you’ve selected via your smartphone. With the IVR systems I’ve used I think you’d save at least “voice menu options”, which I would imagine would make customer satisfaction skyrocket in such systems.

I’m sure there are developers using Rhodes and AdHearSion today without our knowledge given our common customer base of early adopter Ruby developers. But regardless, I’m excited about about demonstrating the potential of data-oriented smartphone apps (aka Rhodes apps) to accelerate and alleviate interaction with backend IVR systems (such as those built with AdHearSion) in at least one of our sample apps.

0 Comments | Posted by admin