Regarding the iPhone, it’s certainly got buzz in its favor. And as of Q1 CY09, Apple had sold 21 million iPhones.

On the other hand, Microsoft announced that 20 million Windows Mobile devices sold in 2008 alone. However, unfortunately for the independent software makers, what’s missing in the Microsoft case is a sales channel like the iPhone store.

If you’re an aspiring iPhone application developer, there have been some inspiring big-money success stories. For example, Tap Tap Revenge is on an estimated 6.5 million devices. But there’s a huge amount of competition now. A recent estimate is that there are 35,000 applications on the iPhone store (many of which are free).

Is developing iPhone applications a good business model? It’s always fun to play an overly-simplistic numbers game:

Start by assuming that you’re an experienced developer who makes $100 per hour. That’s a lofty rate, to be sure, but I mean someone who’s truly senior and has the credentials and reputation to deliver a sophisticated iPhone application, on budget, with high reliability. If you’re not one of those, you should not be playing this game (and good luck finding one).

Assume you spend the equivalent of one month, or 160 hours, on developing an iPhone application. That’s $16K of development cost. Now suppose you sell the application at the typical 99 cents per download, and that you can average 50 downloads per day. Minus Apple’s cut, you’ve got 69 cents of revenue per unit. To make back the development cost is going to require selling almost 24,000 units, which will take 464 days, or around 15 months.

Too conservative? Maybe in some ways. For one thing, moving 50/day may be typical across the board, but top category apps do 2500/day. Also, in a software start-up endeavor, the average developer cost had better be less than $100/hr (although there’s big time competition for those brains right now). And in that case, you won’t be developing just one application, but rather several of them, in which case you might be able to average less than 160 hours per. The goal is to have a few solid app releases, established a brand, and break into the top per-category lists. If you can get to that point, then, again, you’ll be doing way better download numbers.

On the other hand, the winning strategy right now seems to be to build one or more successful apps as free downloads in order to garner a user base. Then try to monetize later (hey, .com all over again!), perhaps by introducing premium versions. There will be non-trivial marketing and design expenses along the way, probably dwarfing the above development-cost-only numbers.

So – surprise – it’s not the get-rich-quick opportunity that many people seem to think it is. There is significant competition in this space, including from folks who decide to provide similar apps for free, either because it’s just a side project or because they’re doing it as a brand-building strategy.

Other background links:

http://www.macresearch.org/business-models-iphone-applications

http://bits.blogs.nytimes.com/2009/04/05/will-the-iphone-30-fuel-a-second-gold-rush/?hp

http://moconews.net/article/419-whats-it-cost-to-be-a-top-iphone-app-1875-a-day

The full list is here. A sample is here:

(Sounds like madness to be in New Orleans in July, doesn’t it?)

Primarily, Tim’s paper attempts to answer the question, “what do we call an application that doesn’t run in the browser?” and he defends his choice of ‘rich client’. I personally prefer ‘thick client’, since it clearly contrasts what the likes of Sun (moment of silence please) and Google have been trying to push as the thin client, or the equivalent of terminal- or browser-only, solutions that are in their best interest. However, I freely admit that ‘thick client’ doesn’t have all of the right connotations, especially in the PR department, and that my business is in the ‘thick client’ camp.

I disagree with some of Tim’s points. First, he says that some things are impossible to do in the browser. Given the extensibility of today’s browsers, and the software tools available to web application programmers, this is not true, even if we generously interpret ‘impossible’ as a relative term.

This serves as a segue (Segway?) to the next point, though, which is that just because you can do almost anything with an ActiveX control in IE, for example, doesn’t mean you should use that approach - security generally being the primary issue when it comes to browser plug-ins. However, this brings me again back to the first point, which is that just because the ActiveX approach is harder to do securely doesn’t mean it’s impossible to do securely. And - this is the key thing when it comes to the relative security of the “rich client” approach (another of Tim’s points) - regardless of where the application lives, inside or outside the browser, security requires diligence and careful analysis.

Thirdly, Tim’s points imply that richness is easier to achieve outside the confines of the browser. A relevant measurement for this claim would be the development cost of equivalent applications, one browser-based and one not, that solve a business problem. Admittedly, those are difficult data to obtain for a couple of reasons. First, the biases of the customer as well as of the developer influence technology choice. Second, my first point notwithstanding, I freely stipulate that many problems are more easily solved by one approach (in the browser) or the other (outside the browser), if for no other reason than industrial inertia.

Still, regarding the ease of achieving richness, I cite two counter-arguments to Tim’s viewpoint: first, there is tremendous competition in the custom web development market, both domestically (US) and overseas. This has driven down prices and driven up quality (although not uniformly). And second, while it’s not clear whether richness implies a professional design and UX, it should, and that’s neither cheap nor easy regardless of the technology. But, in my experience, it’s easier to find experienced web designers than experienced “non-browser-based-UI” designers (easier being, again, a relative term; it’s really hard to find either).

Particularly interesting to me is the Sensor API support, which relates to a recent JW Secure project, and the Network List Manager (NLM). NLM is a little-known feature introduced in Vista that gives you network connectivity data and change notification.