Which Mobile Platforms Should You Target? (Part 1)

Bernhard Kappe, Monday, March 16, 2009 @ 1:32 pm

Our company gets a lot of requests for mobile application development.  Most of the time the request is for a specific platform like the iPhone or Blackberry, but every so often we get a request for “all major mobile devices.”  That request usually changes when people realize that developing on iPhone, Blackberry, Android, Windows Mobile, Palm, etc. really means developing five or more separate applications.  The next question is usually what platform should they target first. That’s not an easy question to answer, because of the constant changes in the landscape and the type of application in question.  Here’s how we tackle it:

Is It Really a Web Application?

If your application is really a web application that relies on external data, doesn’t rely on phone specific data or local storage, then you really can build one application:  A web application.  WAP as a standard never really took off, and most smartphones (including Blackberry) now use full featured web browsers.  Setting up a web application to recognize the browser and operating system of a requestor and serve up appropriately formatted content is relatively straightforward.  The main design considerations are lower bandwidth and smaller screen resolutions.  This puts a premium on providing the most important information in bite size chunks, as well as having bigger button and form element targets.   This is far cheaper than building a separate application for each platform.

Worth noting: The web traffic of all mobile web browsers together only makes up a small fraction of overall web traffic, and the iPhone dominates that traffic, generating two thirds of all mobile web traffic.    This is primarily because the web browsing experience is just so much better on the iPhone than on other mobile platforms.  Because Apple’s aesthetic and expected interactions for native applications are so pronounced, the most effective web applications targeting the iPhone have mimmiced the aesthetic and interaction patterns. To speed up iPhone web application development, Pathfinder has developed TankEngine, an open source Ruby on Rails plugin for developing web applications optimized for the iPhone look and feel.

Next Time:  Part 2:  Native Mobile Applications

Related Services: iPhone Application Development, Custom Software Development

Related posts:

1. Which Mobile Platforms Should You Target? (Part 2)
2. Which Mobile Platform Should You Target – Other Points of View
3. Pathfinder sponsoring Day of Mobile in Chicago
4. 5 things I can do with my windows mobile phone that you can’t do with your iPhone
5. “Developing iPhone applications using Ruby on Rails and Eclipse, Part 2: Displaying iPhone content to the client” Also up on IBM Developerworks

Comments (10)

Software Development

Comments: 10 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Have you checked out RhoMobile? Seems promising to be able to develop apps for all major platforms.

   http://www.rhomobile.com/

   Comment by Andrew Herron, Monday, March 16, 2009 @ 2:10 pm

2. 

   @Andrew

   We’ve looked at a number of solutions, including the one you mention. Clearly writing an app for a common platform is more cost effective than writing apps — even ones that share a business model and rules — for several platforms. That being said, rhomobile looks like a web-based solution (see the faq). There’s nothing wrong with that (see the blog post above and our solution TankEngine), but it isn’t always appropriate for all types of applications.

   Comment by Dietrich Kappe, Monday, March 16, 2009 @ 3:47 pm

3. 

   Gentlemen,

   Rhomobile is NOT a web-based solution at all. It is a framework that allows you to build a NATIVE application. From the front page of our website:

   Rhomobile’s open source mobile application framework Rhodes lets you quickly build mobile interfaces to enterprise applications. These are true native device applications: They work against synced local data and take advantage of device capabilities such as GPS and PIM access.

   Comment by Adam, Tuesday, March 17, 2009 @ 5:21 am

4. 

   @Adam

   My apologies. I was looking specifically at the iPhone version. Given the iPhone’s strict prohibition against deploying interpreters in apps, I assumed your iPhone version was a Webkit wrapper of some sort that exposed native features into JavaScript. The language in your FAQ seemed to indicate that your “pages” looked like native iPhone UI.

   Can you clarify?

   Comment by Dietrich Kappe, Tuesday, March 17, 2009 @ 9:12 am

5. 

   Thank you Bernhard. It’s a very good point: before building an app, do you really need an app? Or is it just about being “cool”? I hope it makes sense.

   Thank you also for the article, though there is an alternative explanation to iPhone “supremacy”: the unlimited access to web – no pay per usage. I would be curious to see how that compares with countries where iPhone is sold with no unlimted access to the web (e.g. Italy).

   Comment by Giorgio Venturi, Wednesday, March 18, 2009 @ 5:49 am

6. 

   We actually talk about this in two different questions on our FAQ on our site (just for emphasisis . Rule 3.3.2 says that you cannot download interpreted code. It does not prohibit having an embedded interpreter. In fact there are hundreds of iPhone AppStore apps with embedded interpreters (Javascript interpreters, shell script interpreters, etc.). What you can’t do is download code to those interpreters. In fact, just to protect developers from themselves we disable several Ruby features (such as eval).

   Comment by Adam Blum, Wednesday, March 18, 2009 @ 3:39 pm

7. 

   Bernhard, your topic really sounds familiar! At least for the mobile enterprise application market the technology Mobile OSGi offers a proposition that seems to fit to your context. Refer to http://www.slideshare.net/j.ritter/mobile-osgi-for-enterprise-applications (specificall page 25 and 31). More on Mobile OSGi you find at http://mobileosgi.blogspot.com. What’s your take on that?

   Comment by joritter, Thursday, March 19, 2009 @ 8:15 am

8. [...] the first installment, we covered the simple case, where your application is really a web app, not really using any [...]

   Pingback by Agile Ajax » Which Mobile Platforms Should You Target? (Part 2) » Pathfinder Development, Monday, March 30, 2009 @ 5:05 am

9. 

   we are also using RhoMobile’s framework.

   Comment by NYWebTeam, Saturday, April 4, 2009 @ 9:40 pm

10. [...] two part series Which Mobile Platform Should You Target – on web apps and on native apps – generated a fair bit of feedback, especially from those targeting cross [...]

    Pingback by Agile Ajax » Which Mobile Platform Should You Target - Other Points of View » Pathfinder Development, Monday, April 6, 2009 @ 12:06 pm

Leave a comment