Choosing a mobile development platform

Smart phones, they’re everywhere. They’re fueling the end of despotic regimes, tuning up your local experience, and shooting feature-length films. There’s a school of thought that says mobiles – smartphones and feature phones – are powerful tools to tackle barriers to human well-being as well. We’ve seen many amazing projects in this spirit come through IDEAS – SanaMobile is a remote medical diagnostic tool; AssuredLabor helps trustworthy workers connect with employers; Netra reduces the cost of diagnosing refractive eye conditions; and Konbit enables employable Haitians to create audio resumes.

But we’re getting a little ahead. Our question is about getting started in smartphone application development, so we want to put it to you, developers: how do you choose the platform and development environment to work in – Windows, Android, or iOS? What are the criteria you would use? (And be honest here: if its as simple as, “I learned Java in 4th grade and have stuck with it,” or, “A sponsor gave us 5 Windows phones,” then tell us that, too!).

“Call the question” is a new series we’re experimenting with, to get insights into how innovation for development and invention and entrepreneurship as public service happens – at MIT and elsewhere. We encourage questions from the specific (how do I choose my corporation type?) to the strategic (where should I pilot an innovative water desalinization technology?). Got a question you’d like to have answered?  Send an email to and we’ll consider posting it here. Either way, we’ll let you know.

1 Responses to “Choosing a mobile development platform”

  • I work for an interactive agency, so for me the choice of platform and development environment largely depends on the need of the client, their budget and requirements.

    What is often most cost effective is to create an interactive web site that is targeted for optimal display on a mobile device. This typically means detecting how the user is accessing the site, via traditional web browser or via mobile device, and then for mobile devices auto-forwarding the user to the mobile friendly edition of the web site.

    Using this strategy, a wide range of mobile devices will be able to access your content, and use the various features of the web site. It will not limit you to only users with iOS or Android or Windows based devices.

    Alternatively, when client requires features and functionality best implemented via a native application running on a mobile device, the idea is to analyze a client’s web log files, to get an idea about what devices their users are already using. This in turn helps inform what mobile platforms to target.

    A colleague of mine has a recent blog post with more details of the approach my company takes:

    For me personally, I gravitate towards Android and Blackberry. They are both use java based APIs which is where I have more development experience. And of those two I’d tend more towards Android. The challenge with blackberry are the sheer range of devices, running several different generations of the Blackberry OS, and only the most recent Blackberry OS, version 6, is anywhere near comparable to what Android and iOS devices have been doing for a while now.

    The bigger challenge I’ve had with Android and Blackberry based devices is the sheer range of device capabilities, some with track balls, track pads, touch screens, physical qwerty keypads, virtual qwerty keypads, or both, plus devices that can switch orientation from vertical to horizontal. Getting an application to cope with all of those hardware parameters is difficult. So difficult that its actually better to create several different versions of an application, targeting major hardware capabilities. E.g. a trackpad optimized version of an app, and a touch screen optimized version.

    The nice thing about iOS devices is hardware uniformity. Makes it easier to focus on creating application features without worrying about device capabilities.

Comments are currently closed.