Gizmodo did an excellent review of the different Smartphone App Stores that exist in the market place. The chart below describes the similarities and differences between the various platform storefronts as of April 7th, 2009. The full article can be found here.

Ever wondered what it takes to build a successful mobile application?

We did too. We did some research on the top mobile applications and noticed some commonality. In no particular order, here they are:

1. Mobility

The mobile phone is unlike traditional computing platforms. One of the common mistakes in designing a mobile application is to simply replicate the features of a desktop or web application onto a mobile device. A good mobile application will take advantage of the inherent mobility factor that comes with a handheld. Using capabilities such as location-based services, Bluetooth or the built-in accelerometer is what really makes a mobile application attractive. Furthermore, considering that the mobile device is carried by the user everywhere they go, as a mobile application designer, you want to think of creative ways to make use of that fact. With platforms that make use of push technology you may want to include custom notifications into your application.

2. Sociability

From its infancy, the mobile phone had sociability as the corner-stone of its existence – people call each other to keep in touch. With the advent of data services, the mobile phone is used more and more for digital socialization. This is an area one may want to explore with a mobile application. Integrating your application with well-known Web 2.0 social communities such as Facebook, Twitter and others can make for an attractive medium to connect users. Social features in a mobile application simply make sense. In addition to connecting your users, sociability can also provide a way for user-driven viral adoption of your application and/or content.

3. Usability

Mobile users are just that – mobile. A typical mobile user will spend only a few short minutes using a mobile application. Your application must be very easy to use, with limited instructions. Do your best to keep the screens clutter-free and give users minimal options. Do not overwhelm your users with too many ways of doing the same thing. Design intuitive controls and navigation menus. Also keep in mind different environments such as subways where network connections are unavailable. If your application needs a constant network, this will limit the times when a user can actually use the application.

4. Dynamic Content

You definitely want to impress the user the first time they run your app… but a mobile application needs to do much more than that – it needs to keep users coming back. Mobile users are accustomed to a quick ROI on their time – you don’t want to bore your users with static content. Take advantage of the data connection and fetch dynamic content. This will provide new reasons for your users to keep using your application over and over again.

5. Personalization

Mobile phones are so ubiquitous that they are truly becoming an extension of the owner’s personality. Mobile phone owners can customize the physical look and feel of their handhelds using different skins and accessories. The software can also be personalized using wallpapers and themed icon sets. A good mobile application will allow the user to customize certain aspects of it. Personalization of a users’ profile may may help increase application usage as it can become’s a part of their identity.

Now that you know what it takes to design a winning mobile application, go out there a design the next big thing on the market.

We’d love to hear from you. What are your top 5 attributes of a successful mobile application?

A common struggle with mobile devices is the small size applications are allowed to be. Feature phones in particular only allow a few hundred KB to MB for each application. Large applications also impact your wallet when you have to download them. Smartphones and cheaper data plans are helping relieve this problem, however if you need your application to support a wide variety of phones there are some good practices you should follow.

Java ME handsets have the most issues with images, so following some easily automatable rules will make your images work on a broad set of handsets. PNG images are the most common, since it’s the only required image format for the platform. According to the Java ME specification, most PNG features should work, but in reality a number of them do not. Specifically 8-bit transparency is not implemented on all devices. Some devices dislike some of the extra data chunks in PNG files that are not strictly necessary, some other devices will ignore other chunks — for example, the gAMA (Gamma) chunk is often ignored.

So the goods – here’s how we process our images – it makes our apps work better across Java ME handsets, and it makes downloads faster for Smartphones.

• Avoid 8-bit transparency as many devices have little or no support for it. If you need it for a rich user interface, such as on QVGA devices, just understand that you’ll need non 8-bit transparency images for smaller screen devices
• PNG files should be indexed, not RGB. This allows you to shrink the image size by minimizing the number of colors. Eyeball the images as you lower the number of colors and you’ll frequently be able to shrink the file size
• Remove extra data chunks aside from the 4-5 necessary ones. Anything other than IHDR, PLTE, TRNS, IDAT, IEND should be removed. Extremely rarely, a device has been known to require PHYS or BKGD to work properly – these cases are rare enough to handle manually when required
• Ensure the transparent colors are at the beginning of the palette
• Transparency color should ideally be Black, White or Pink. Pink is a usual choice as it is in the middle of the RBG spectrum. Black or white are ideal to minimize transparency problems when background hue is generally known
• Transparent color should not be numerically close (within 0×0F) to a non transparent color – some devices will either render all “close” colors transparent, or not render the transparent pixels as transparent
• Absolutely no duplicate colors should exist in the palette

Having been in the mobile space for a number of years, I’m often asked by prospective customers whether they should develop a mobile website or create a downloadable application that runs on the handsets. The short answer is, it depends on what your trying to accomplish.

Developing for the Mobile Web

Web development on mobile phones has long suffered from a very rigid platform and the inability for mobile browsers to keep up with current web technologies. This is slowly changing, partially due to the recent spikes in Smartphone handset sales. With many handset manufacturers attempting to clone the iPhone’s usability and appeal, a larger focus has been placed on the content on mobile phones, which in turn, requires better software to render this content. For example, both the iPhone and Blackberry Bold browsers can view HTML pages and process JavaScript. Technologies such as Flash have been rumored to be coming in the near term, but it will take some time before its supported on a large number of devices.

The “Pros” for Developing Mobile Web Applications

• The cost of supporting a mobile web application is relatively cheap in comparison to a downloadable application
• Accordingly, the speed at which a mobile website can be created is relatively quick
• If you have an existing high traffic web destination, developing a mobile version makes sense as your site already has a brand attached to it and a loyal following
• Higher-end devices are beginning to support existing desktop browser capabilities thus making the delta between your mobile and desktop browser experience smaller
• Deployment of a mobile website is quite simple
• The mobile web allows you to develop on a single platform and target the broadest set of launched across all handsets

The “Cons” for Developing Mobile Web Applications

• Currently, mobile websites are unable to take advantage of device specific features
• Ex: For the same reasons you can’t use a website to burn a CD, you cannot use a mobile website to access your phone’s contact list
• This is why high traffic sites such as Facebook will create both a mobile website and downloadable application
• Relatively speaking, interfaces on mobile websites are quite poor and clunky resulting in a less than desirable user experience
• Currently, support for AJAX and DHTML technologies is quite limited
• Despite developing for a single platform, developers must take into account mobile device idiosyncrasies across different handsets, firmware versions and operators
• Users must be connected at all times… there is no concept of an “offline mode”
• With the increase in mobile handset vendors, there has also been an increase in browser fragmentation
• On the web, typically developers are focused on Firefox, Opera, Internet Explorer and Safari
• In the mobile space, there are 10+ relevant browsers and many more in development
• Mobile website owners must rely heavily on 3rd party sources such as Device Atlas to understand device characteristics

Developing Mobile Applications

Similar to the mobile web, the native capabilities of handsets have improved and so have the associated SDKs. If you’re watching how Apple markets the iPhone, its all about letting users know that their device is more than just a phone. Specifically, they showcase applications created for the handset that leverage it’s unique capabilities. In general, Apple has done a fantastic job of making users feel comfortable in downloading content to their handsets. It’s not only helped them, but it’s opened up the floodgates across other platforms.

The “Pros” for Developing Mobile Applications

• Mobile applications can interact directly with the device obtaining useful information such as location, contact lists, accelerometer functions, etc. This is critical for a “mobile” application
• Having the ability to control exactly what is displayed on screen allows for customized (and optimized), rich user interfaces directly on the device
• User interactions can also be directly controlled via the possible inputs (touch, voice, keyboard, etc)
• In your mobile application, you are able to store reasonable amounts of data directly on the handset in a secure manner as opposed to storing everything on a remote server (slow!)
• Performance can typically be optimized for each handset and platform
• Mobile (Smartphone) development platforms are improving quite rapidly
• Developers can create a consistent look and feel throughout their application
• Measurement in terms of how users interact with an application is possible

The “Cons” for Developing Mobile Applications

• Unless proper design measures are taken, upkeep and continued portability of your application is difficult to maintain.  This happens to be something we specialize in
• There are 5-6 relevant mobile application development platforms to choose from, and understand which ones best suit your needs can be confusing
• Within these platforms, additional fragmentation exists at a per device, firmware and operator level
• Typically, developing rich mobile applications is more costly than creating a mobile website
• Mobile applications may require porting to additional platforms and this takes up front consideration
• A single, publicly available source for data across all mobile handset characteristics and attributes as they relate to the individual SDKs does not exist
• Testing can be time consuming and costly as mobile applications must be tested on the physical handset
• One needs to understand the various carrier requirements if an “on deck” strategy is preferred

In conclusion, it very much depends on your organization’s goals with regards to the mobile application. If it’s simply an extension of your mobile website, is heavily content focused and does not require an interactive user experience, then the mobile web may be a better choice. If one requires access to device functionality such as location or the contact list and have an appropriate development and porting strategy formed (either internally, or through a partner) that will help minimize the effects of device fragmentation, then developing a mobile application makes sense.

As we’re all aware, the iPhone represents an exciting innovation in the mobile space. Developers finally have a platform to distribute content that has a widespread audience of techies and casual users. One of the major draws to the platform is the perceived lack of device fragmentation that exists given that one is developing for a very small set of devices in the iPhone and iTouch.

While Apple has done a tremendous job in limiting the level of fragmentation, its inevitable that developers will run into issues as they create content. Keeping some of the suggestions we’ve provided in mind when designing and developing your application will help make your code more portable across the different platforms.

1. Device Simulator vs. Actual Hardware

Its incredibly difficult to create an accurate device simulator that runs on a developers machine, given that the underlying hardware and user input mechanisms are different from the get go. Apple has provided one of the best device simulators that we’ve seen for mobile devices. Given their focus on the generation of unique and compelling content, this shouldn’t come as much of a surprise.

The first thing I noticed was the accuracy and speed at which the emulator operates at. To given an example, the Apple emulator can be loaded in a matter of seconds while RIM’s BlackBerry emulators take quite some time to load and I’ve found the load time takes me out of the development “flow”. They’ve also made it very easy to run the emulators across the different released firmware versions (which is quite useful when you’re trying to isolate firmware specific bugs in your application).

When developing using the emulator versus the device, the following should be noted:

• The simulator does not have an accelerometer, thus making it difficult to test any applications that require those functions
• There are ways to simulate the accelerometer and tie it to the one located inside your MacBook
• The simulator does not provide access to location but it does provide you with a default location thus allowing you to use the API
• The performance on the hardware itself is notably slower than on the simulator. Graphically demanding applications should always be tested on the handset itself to ensure the performance is up to par
• There are several video playback issues
• The simulator does not appear to take into account the case sensitive filenames stored on your MacBook’s hard drive. For example, if you have a test.png in your application, [UIImage imageWithName:@”Test.png”] will work on the simulator but not on the device (notice the capital “T” in “Test.png”)
• I had a custom button with an image:
  

  UIButton *button = [UIButton buttonWithType:UIButtonTypeCustom];
  [button setImage:image forState:UIControlStateNormal];

  I tried to dynamically position the button using some computations. If button.frame.origin.x was not a round number the margin of the button will show up fine on the simulator but is chopped of on the real device. The solution was to use the round() function when computing button.frame.origin.x, which makes sense but is something I assumed the platform would have done for me

   

2. Differences between firmware SDK versions

When you develop for a mobile device, the firmware version of the device is often a major factor. One could have different firmware versions for a single device as its deployed across multiple carriers as an example. There are also have some users who actively update their firmware to the latest and others who do not. As a result, one could end up with different builds for the same device for each targeted carrier, because they introduced the device at a different point in time with different firmware versions.

Luckily, with iPhone updating the device is extremely well thought out and easy process from the user’s point of view. A developer typically only has to worry about the current operating firmware and the previous version. While a developer compiles the application, its tied to the version of the SDK so a user with an older SDK will not be able to install it and will be prompted to update their firmware in order to do so.

There are still some issues that you might want to keep in mind:

• If you are not building against the latest SDK, make sure that you are testing the application on devices with previous versions
• There are bugs fixed/introduced in each new version. A few that I’ve run into include:
  − the list of supported fonts is different from version 2.0 and 2.1. I believe some fonts were taken out or the name was changed. My font selection dialog was crashing after updating to the new version.
• There used to be a way to provide a transparent background for a UIWebView in firmware version 2.1…. unfortunately this appears to have been removed
• See the links for additional changes: 2.0 to 2.1 2.1 to 2.2

3. Fragmentation between Apple devices

From a device fragmentation perspective, one should consider the three different versions of devices that Apple supports: iPhone 2G, iPhone 3G and iTouch.

When designing your application you have to carefully choose your feature set based on the targeted audience.

Some additions items you should take into consideration when developing your applications:

iPhone 2G vs iPhone 3G

• Because of the network speed, iPhone 2G is not suitable for streaming applications

iPhone vs iPod Touch

• There is no camera on the iPod Touch
• There is no sound recording mechanism on the iPod Touch
• Location information is limited when using the iPod Touch, and is only available when the device is connected to a WiFi network
• The iPod Touch does support any phone functions
• The 2nd generation of iPod Touch introduced a faster processor: 532MHz (up from 412MHz). This has an impact on applications which are dependent on the CPU speed (mostly games).

4. The Future

It will be interesting to see how Apple tackles the fragmentation problem as they release additional versions of their platforms. The rumored 3rd generation of the platform has quite a few enhancements that will allow for more interesting applications to be created, but may cause issues for existing verisons to run on the handsets. I believe Apple will control this by releasing new versions on a controlled basis and ensuring hardware changes are ramped up over time.

The challenge all developers will face is ensuring that there is both portable and future proof at the same time.

Check back soon for additional iPhone development tips and tricks!