The year 2008 was a key year for mobile applications. In that year, Apple released its iOS SDK in March and launched the App Store with the release of iOS 2.0 in July. Let’s call it the start of the Mobile Gold Rush. Now in this mobile gold rush, there are hundreds of thousands of applications and amongst them many are bound to have the same idea and the same purpose. How does one app shine, while others won’t even get visits to their description pages?
Let me tell you about an experience I had. I used to own a smartphone running Windows Mobile 6.1. I loved the phone when I only used it as a phone, but simply hated it when it came to applications. There were thousands of issues I could have pointed out. The end result is that I am not going to purchase another Windows smartphone. Do you see where I am going with this?
Consumers always rely on their memory associations, whether conscious or unconscious, when it comes to purchasing new products. I would say almost everyone would not go back to using a product they’ve had a bad experience with when there are so many other options around. This goes the same for mobile application developers and development firms. I have uninstalled so many applications from my Nexus One within the first few minutes of their lives. It wasn’t because of the features they didn’t have or how horrid the GUI was. The main reason was they weren’t working the way they were expected to. Some users even kiss applications goodbye altogether according to this survey based on such experiences. Let me put it this way:
“If your code is not flawless, you will lose your market share and never be able to recover it.”
Application developers strive to develop new features giving them the competitive advantage or as my friend and mentor, Bruce Firestone, calls it “Pixie Dust”. This is completely the right thing to do; however, they should focus more on their apps’ perfect functional execution. Having a limited number of features that work exactly as the user expects is better than having more numerous, but buggy features. I know it sounds like a no brainer, but the success of a small number of apps as opposed to the thousand other ones doing the same thing should serve as sufficient evidence that it is easier said than done.
Buggy code hurts the application and the developing company’s brand. Making sure your code is near perfect would be a strategy I would like to call the Pre-Branding Protection Plan. With the abundance of competitors in the mobile gold rush, bad apps will almost permanently prevent market recovery and destroy sales.
One method I use to make sure my brand would be protected is using J2ME static analysis tools. There are various paid and free tools, but I am very happy with the Klocwork Solo, which is geared for J2ME developers. I had never used such tools and only started using them when I joined the company. I don’t know what I would do without them now. In my next posts, I will discuss some of the issues the tool caught that improved my productivity and the efficiency of my code.