The mobile software space is getting rather crowded. In the not-so-distant past, a mobile developer’s choice was limited to two or three popular native operating systems: Palm OS, Windows Mobile (two flavors), or Symbian. Other platforms were less known or were perceived to not provide for much profit. For a microISV, either the barriers to entry (such as steep signing fees) were too great, or the platform was not popular enough to generate adequate third-party software sales.
The mobile software space is getting rather crowded. In the not-so-distant past, a mobile developer’s choice was limited to two or three popular native operating systems: Palm OS, Windows Mobile (two flavors), or Symbian. Other platforms were less known or were perceived to not provide for much profit. For a microISV, either the barriers to entry (such as steep signing fees) were too great, or the platform was not popular enough to generate adequate third-party software sales.
Now the choices for native apps have multiplied: Palm OS, Windows Mobile (three flavors), Symbian, iPhone, Android, Access Linux Platform (ALP), Blackberry, upcoming Palm Linux, and several other mobile Linux platforms. Developers can also program via the browser—the elusive “mobile web app.”
My direct experience has been mainly with Palm OS, but of course for survival we have to consider alternatives, as the current OS becomes antiquated, the market share of the Palm OS-based PDA’s and smartphones diminishes, and the marketing opportunities of third-party applications to hardware customers slowly disappears. So, how would one compare and contrast today’s choices for mobile software development? As the ideas for this post were coagulating, I found the answer to that question was more complicated than first expected.
I have been compiling a spreadsheet so I could get a snapshot of the differences. (It’s a work in progress.) However, terminology can differ, different developers and websites throw a lot of terms around, from software for the Integrated Development Environment (IDE), to languages to code in, to frameworks, to virtual machines. I discovered the best way to approach this subject was to start with a summary of what’s out there, and then to cover each option individually, with more details.
As a micro Independent Software Vendor (mISV), it is difficult to program in multiple flavors. Platforms can differ by the programming language in which you code, by development environment, by tools, and even sometimes by which desktop hardware you use. It’s like reading seven books at once, in three different languages, some in hardcover, paperback, eBook, and audio book format. Not only can you get the plot lines mixed up, and require different tools to read them, but the experience is not enjoyable. Now try writing one book (without help) in three languages, on paper, eBook, and audio. Less fun. Editing nightmare. Now you have to sell the book—in hardcover, paperback, big print paperback, eBook, and audio tape, CD, DVD, and MP3 formats. The user interfaces (UI) are all different. As an author, your core competency is writing—not editing, publishing, and distributing. If you have to spend equal time on all tasks, your book will probably not be your best. Or you’ll never ship. Either way, if you are in this to make a living, doing it all is difficult and not the path to take.
So, how do you choose? Which platform will be your Holy Grail? It will probably depend on many factors: how long your mISV has existed, what investments you have already made, what programming languages you already know, what hardware you own, what desktop software you have installed, how much the tools cost, how big the market is, how good the marketing opportunities are, and what motivation you have. Of course, time will be one of your scarcest resources. The choices vary greatly for each consideration, but one platform should best fit your needs and priorities.
Focusing on core competency, if you are already developing for a mobile platform your best bet is usually to stick with one platform. You have a name recognition advantage, you have the tools in place, you have contacts, and you have applications you can build, improve, or expand upon. The only exception is if your platform’s market is shrinking, or is perceived to be so. (Users stop buying software if they think it will have no value in the near-future.) Therefore, you must switch platforms to survive. If you are new to mobile development, start by choosing one platform. While it’s possible to maintain two platforms, it may not be time or cost effective. By developing for one platform, you can focus on what you do best.
Referring to my spreadsheet, many of the platforms can use C++. However, is it possible to write one application for all (or most) platforms? No, and yes. Each platform will have a different UI, different drivers for the hardware, different system calls. Some have different database structures. So, while adding 2+2 is the same, the format for how the user inputs the numbers and how the user sees the results will vary greatly. A large percentage of the application is the UI and the UI for each platform may require extensive development time and effort. So a vanilla set of C++ code is not enough.
However, I also said “Yes.” One option today is to write a mobile web application. While the UI may differ in appearance (depending on screen real estate), the coding is simpler and much easier to change on the fly from within a browser (using Cascading Style Sheets(CSS), for example). We’re exploring this with our Date Wheel.net web app. We are working on the graphical variations (screen size, and style) but the functional UI will remain the same.
A lot of buzz surrounds web apps—most commonly referred to as Web 2.0. Many of the Web 2.0 apps are desktop based, however, which poses much less UI graphical variation, better established browsers (Firefox, Internet Explorer, and Safari), and more profit models (like Google Adsense). Many of my readers probably use some of the more “social” of these tools: Facebook, Twitter, Flickr, Digg, or apps like Gmail, Google Maps, and Pandora. (For a good taste of Web 2.0, check out Webware.com.) On the negative side, some say Web 2.0 is the next big bubble. In any event, right now it’s a very active development community.
I believe mobile web apps are still in their infancy. Major barriers exist:
- Mobile browsers are inconsistent—some don’t support Javascript, different sized text, CSS, HTML (some still only support WAP), or PNG images.
- Screen size and depth vary greatly: from 320×320, to 240×240, to 320×480 at 160 ppi, to….
- No easy business model—physical files and unlock keys are gone. The smaller screen adds complexity to the ad supported model, low-priced subscriptions seem unrealistic for smaller applications, and you can’t just give it away for free—your business does need to make money.
- Connectivity! What happens if I’m offline or out of my service area? This barrier is huge.
Will things change? Of course! iPhone has already raised the browser bar. Easy to use mobile ad networks are popping up everywhere. (I’m using Ad Mob for Mobile Travel Aide). Offline solutions, such as Google Gears, are being developed. And it’s just a matter of time before connectivity becomes ubiquitous. Some of us remember how the early cell phone market was—voice quality was horrible, coverage was lacking, and prices were high—all leading to slow adoption. As data becomes faster, cheaper, and more reliable, mobile web apps will become more popular.
So, in upcoming posts, I’ll endeavor to individually explore as many of the available mobile software platforms in depth. I welcome any anecdotal input—please feel free to comment or send me your take. My spreadsheet is far from complete, so if you have anything to add or amend, I’ll endeavor to keep it up to date. The mobile software world may be evolving at a rapid pace, but while overwhelming, it’s also exciting and invigorating!
Special thanks go out to Natara for their insight into the Windows Mobile platforms.
