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