Install Theme

The Cross Platform Myth

A few weeks ago, we released a version of the Lucky Oyster iPhone App that we really felt represented the full range of use cases we wanted to support based on our months of research with alpha users. And so it was only natural for us to cross a secondary bridge: making the app available to other devices and the desktop.

To make platform/device ubiquity happen, we were banking on a decision we made last spring, to develop our app in a hybrid environment (Phonegap specifically), leveraging HTML5, CSS, and Javascript.

In the beginning, using Phonegap gave us a tremendous advantage in that our development was lightning fast, and we didn’t need to secure any platform-specific development resources. And for features that required getting closer to the native capabilities of the device, we simply used existing plugins or wrote our own Objective-C.

So while the speed-to-market part of the equation panned out, two things really surprised us about making our hybrid app cross platform. To be clear, this is in fact one of the intended benefits of the Phonegap framework, and their build service supports cross platform deployment quite well. Most of the key third party plugins have both Android and iOS versions, and the device API provided by the framework is incredibly robust across everything from iOS and Android to Windows Phone and Blackberry.

The first surprise was how easy making Web-, Android, and other versions of the app would be, at least from a development standpoint. I was skeptical at first. For example, to make the app work on the Web, we just loaded in alternative base classes, supplanting Phonegap and/or native Plugin functionality with environment-specific code. Even our use of SQLite worked seamlessly between our native iOS code and HTML5 WebSql with literally a few modifications to model instantiation, as their APIs are largely the same. We also discovered we could have device- and content-specific templates, functionality, etc. with very little heavy lifting, although keeping the presentation exactly the same was clearly going to be a more difficult chore.

But the second surprise, and the more relevant one, was that we realized we didn’t need to go cross platform with our app. The use cases, for Web specifically, but for other devices as well, differed from those the iPhone app was meant to support. By replicating the app, we would have been leaving an opportunity to test an alternate product approach to our mission.

In the end, we came to a few conclusions about what cross platform could mean to a startup like us:

- Just because you can push your code to multiple devices inexpensively, maintaining all of the device-specific rules, exceptions and tweaks is where things will ultimately get super costly. And unless you’re 100% sure you have the right product to build your business, that could be a fool’s errand.

- You can cover the entire device world with a mobile/Web friendly version of the product, and one platform-specific “native” app.

- Having a lighter non-app version of the product can serve as a great bridge between the open Web/mobile world, and the barriers inherent in the adoption of apps (losing context during installation; requiring a password to install; actually running the app post install; logging in; etc.).

- Rather than seeing cross-platform as a n-degree development problem, we chose to see it as a 2-degree product opportunity. Our iPhone app is super rich and granular in functionality, and provides a more intimate experience, while our mobile/Web version is simpler, lighter, more open/public, and a great way to introduce new users (independent of their device) to our core product/mission.

- By choosing this route, we can quickly pilot functionality in the mobile/Web environment, and move it to the iPhone app once proven.

Finally, we realized that in a startup, you’re never really sure about the product until you see massive traction, and the entire process is about experimentation and learning, and determining features that best support user delight and adoption. And given that, replicating the same product n times—just because it’s technically feasible—is to neglect an opportunity to learn even more, pilot new functionality more quickly, keep the mid- and long term costs of maintenance to a minimum, and build bridges between the open world of Web/mobile and our native app.

Thoughts? Comments? Drop us a line at