The mobile device of today is faster, sexier and much more capable than the days of the Palm III, but releasing code is just the opposite. It can take longer today to deploy your application than it does to write your application. It is an understatement to say that navigating the business landscape is quite burdensome for today’s mobile developer.
I was recently speaking to a client for whom I develop and support mobile applications. The primary question was: “how do we price the application? If we distribute it through the application store for free and charge on the back-end, do we have to give (unnamed third party goes here) a cut of the revenue?”
My client has had a handful of successful applications running on RIM’s Blackberry devices for a number of years. Their applications are geared toward the professional services marketplace: consultants, accountants, attorneys, etc. Some clients are small shops with less than a dozen users. Others are multi-national firms with thousands of mobile users. And of course they see everyone in between.
The software works great — clients pay for it and everyone is happy. Over the years the pricing and licensing model has evolved with the market. Sometimes the software is licensed by the user, and other clients may pay a site license. They can do what they feel is necessary to make the sale. They can even give it away or do a custom build for a client if that is what it takes to land the business. Sometimes standing on your head actually works!
Now their clients are asking for a solution on other platforms. Just port the code and off you go. Not so fast. It isn’t that simple any longer.
So wearing my “Entrepreneur/CIO” hat, I enjoy the puzzle of positioning and sorting through the options of building, marketing and deploying mobile applications.
As a developer, I just have to roll my eyes and long for the good old days.
Do you remember when you could just “beam” an application from one device to another? Some applications were locked to preventing beaming — no problem, let me go buy another copy for myself. Or how about being able to just post a single file to your website and have others download it? Better yet, collect money for your work so you can buy bread and cheese (and shoes) for your kids. It was also nice to be able to support your client with feature enhancements and bug fixes in near real-time. That made for happy and engaged clients.
The appstore Phenomenon
Today is the age of the application store. I hesitate to capitalize those words. Apple has theirs. Google has the marketplace. Blackberry even has appworld. I don’t think I ever saw the film, but I keep getting glimpses of Kevin Costner from the movie Waterworld whenever someone mentions appworld. In any event, application stores are the rage these days. They are not all bad. It is a place for consumers to go to find a list of available applications for their device and it is a place where developers can sell their applications. So, are application stores a good thing? Time will tell, but let’s look at some of the pros and cons of the application store model.
First the positive aspects of using an application store provided by either a manufacturer (Apple), a sponsor (Google), or a carrier (Verizon Get It Now).
Consumers can find applications in one place and don’t have to fish all over the Internet to find an application.
Application developers can focus on writing and supporting software. There is no need to dive into the world of credit card merchant accounts or maintain a shopping cart website on their own.
Device compatibility. Application stores can help by making sure that a particular application is compatible for a given device. If an upgrade to the operating system of the device is required it is usually caught before the application is installed, or even downloaded. This is a nice-to-have feature for both consumer and developer alike!
Application trustworthiness. If an application is in the store it means that there is some degree of validation and/or testing before it is launched. This reduces (does not eliminate) the possibility that an application can destroy a device or steal user data.
The price is the price. There is no haggling or spending hours trying to find the right download at the right price on the Internet. This will hold true only for those who value their time more than their money, I concede. When mobile software is selling anywhere from free to a hundred dollars, with the typical app between 5-10 dollars, it just isn’t worth spending hours shopping around.
There are some things of course that are less appealing in the application store model.
Freedom. This varies by platform. Here are a few thoughts:
Apple provides little freedom in terms of where and how you distribute your application. Don’t like it? Don’t use their platform.
Android has a number of marketplace options and probably represents the best of both worlds — use the Marketplace if it suits your needs. If not, purchase your application from Handango or other mobile application marketplaces.
Blackberry is similar to Android in that it is a good solution for those that want it. The important element for both Blackberry and Android is that the application store is an option, not a requirement.
Palm is still trying to sort out how they will operate their store. I am sure they are watching Apple’s success and trying to emulate that. That said, they are a new and on-the-bubble platform that needs people to get behind it. To that end they need the developer community more than developers need them. So whatever they can do to ensure their success is on the table, from my vantage point. So far it seems that they are listening to the developer community and are investing in developer relations.
For an in-the-trenches view of things you might care check out this post from JWZ where the vocal open source developer voices his concerns about his experience with Palm. Note that there is some adult language in the thread — just letting you know ahead of time.
From time to time we have to make releases for planned features, and unplanned features (bugs). No problem. Write the code. Test it on the simulator. Test it on some real devices. Release it to some targeted users. Then roll out to the general user base.
Sounds simple, right? Well, if you are dependent upon a third party to “bless” your application it is difficult to get it into the hands of your client. This is a detractor for both developer and client. Imagine your client discovers a small yet important calculation problem in an application. You need to get a fix out right away. It takes 5 minutes to change a line of code and recompile. And then it takes two weeks to get the code into your user’s hands. Imagine you need to make another small tweak after that. Another two weeks. You get the picture. It isn’t pretty.
Perhaps the most difficult aspect is the fact that the application store’s don’t provide a specified service level. If Apple guaranteed that your application would come out the other end in 10 days you could plan on it. Unfortunately you just don’t know how long it will take. It is difficult to manage client expectations when that happens.
For years I have heard people lamenting over their experience with “punch cards” and how difficult it was to get them right the first time. I cannot help but think that we’ve re-introduced some aspect of that system with the new application review process.
One more challenge of the application store model is that your application is visible to everyone. What if you don’t want anyone but your clients to see your applications? The short answer is to pick a platform that gives you freedom.
The “application store” is likely here to stay as a business model and software companies simply need to learn to navigate it. What do you think?
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62