Archive for December 2009
Not long ago Apple announced that its App Store boasted 100,000 applications available for download and those apps were downloaded more than 2 billion times in 77 countries. Numbers seem to be impressive. And promising for those dreaming to enrich themselves by selling their iPhone applications. But the question actually is what is concealed beyond these numbers?
Throughout various news, articles and forums I found a couple of interesting facts. Believe they are worth sharing with you:
- about 30 percent of Apple’s App Store downloads are paid applications;
- the average number of downloads for a paid application is 9,300, compared to about 71,000 for the average free application;
- half of all paid apps are downloaded 1,000 times or less;
- only 10 percent of them get close to 75,000 downloads;
- paid downloads have reaped close to $1 billion in overall developer revenue since the online iPhone catalog was launched;
- the average number of downloads for a paid app translates into an average revenue of $12,100, with a net to the application’s author of $8,500.
So how do you feel what your chances to earn much from selling iPhone apps are?
Somebody will say – “Hey, guys, the arithmetic mean can be misleading!” Surely, these are average results, not common ones.
In reality App Store sales revenues are extremely disproportionate. The situation could be described like this: “A small segment of developers does dramatically better than this average. Most does much worse“.
The statistics proves this statement:
- the top 10 percent of paid applications average nearly 75,000 downloads;
- the second 10 percent of applications fell to a mere 9,232, slightly less than the overall average cited above;
- the third 10 percent fell by more than half that, to 3,849;
- 50 percent of all paid applications have an average download of less than 1,000.
Thus, while certain developers experience “gold rush”, others have low if any return on their investments of money and time. Looks like a lottery indeed and the next point of Apple’s App Store failure.
From your point of view what could prevent app’s sales revenue accumulation failure here?
At first glance prices per applications could be considered a main factor. And it is partially so, but please have a look at the findings below:
- the average 99 cents application is not downloaded substantially more often than the average $4.99 application.
- the 99-cent applications have an average of about eight or nine uses, the lowest number for all paid application categories.
- the $4.99 programs have an average of nearly 20 uses.
but when application’s price doubles to $9.99, the average number of uses nearly halves, to about 11.
It means that within a certain range users are not price-sensitive and do care about the quality of applications.
As well the survey found an interesting fact that paid applications overall were used slightly more often and for somewhat longer periods than free software:
- the average number of user for all free applications is about 8-9;
- for all paid applications – just over 10.
The reasons for this difference could be rather tricky – it could reflect application quality or increased user “attachment” to something that actually cost them money.
And what do you think of all this stuff? Perhaps you could share your personal experience with folks.
In recent years agile software development has emerged as one of the most popular methodologies used in software projects.
Agile development, in its simplest form, offers a lightweight framework for helping teams, given a constantly evolving functional and technical landscape, maintain a focus on the rapid delivery of business value. As a result of this focus and its associated benefits, organizations are capable of significantly reducing the overall risk associated with software development.
In particular, agile development accelerates the delivery of initial business value, and through a process of continuous planning and feedback, is able to ensure that value is continuing to be maximized throughout the development process. As a result of this iterative planning and feedback loop, teams are able to continuously align the delivered software with desired business needs, easily adapting to changing requirements throughout the process. By measuring and evaluating status based on the undeniable truth of working, testing software, much more accurate visibility into the actual progress of projects is available. And finally, as a result of following an agile process, at the conclusion of a project is a software system that much better addresses the business and customer needs.
Agile development has its own set of drawbacks and may not be suitable for any type and size of software project, but can be successfully used for reasonably sized projects with a maximum team size of around 100 developers. However, agile development should be taken up by any organization in steps and can be started with a small project that can fall in line with the agile methods.
The advantages and risks of Agile Development are currently discussed very hotly. However, with all its pros and cons, agile development is gaining immense popularity amongst organizations across the globe that believe in simplicity in designing and developing software with great and effective collaboration between the project stakeholders.
I wonder what you personally think on this topic. We would be happy to have your comments on if it really makes sense to go agile.
Christmas time is a time for miracles and presents. Just imagine what could be considered a Christmas gift for iPhone developers :)
App Store acceptance procedure – main complaints
Recently there has been much ado about App Store policies that stifle and hurt developers. The main problems seem to be the long acceptance process and Apple’s “self-appointed right to deny an application that isn’t in its best interests”.
Developing an application for iPhone or iPod Touch is comparatively an easy part of the whole process. Once the app is functional, it must run through acceptance which can take long weeks. Even updates to existing applications must pass through this Iron Curtain. It could be frustrating indeed.
It is doubtful the review process needs to be eliminated completely: believe no user will be happy if a seemingly benign downloaded application could harm his/her iPhone device core functionality – cause it crash constantly, send hundreds of text messages or call Honduras. In exchange to have no worries many users are willing to accept reasonable delays in application approval.
From the side of a developer. There have been cases when the application was approved but then in a month or so “the mysterious masters of secrecy decided there was something very bad in the code”. What are the reasons for such delays? Some developers note an interesting thing – they often get a rejection notice almost exactly one week after they submit the app. They even have a crazy theory according to which the approval team is rated on statistics of how many applications are processed within a week of being submitted. So for Apple it would be better if App Store’s decisions were understandable (reasons for rejections) and predictable (when the decisions are to arrive). Now developers submit things, cross their fingers, and submit again.
Apple does miss many opportunities because this uncertainty does kill the incentive for developers – they become afraid to risk serious development time on the platform. Finally, creativity will find expression – many mobile developers have started to expand their mobile platform horizons by creating apps for Android, RIM, Palm’s Pre, and Microsoft’s Windows Mobile. “If Apple does go too far, users will look elsewhere for their phones or to third parties for their applications”.
Voila – the gift itself?!
Not long ago Apple approved three apps – Knocking Live Video, iSimulate, Ustream Live Broadcaster, – with one thing in common: they use private APIs, a violation of the iPhone developer agreement.
The use of private APIs is perhaps “the least contentious of all the strange and convoluted restrictions facing developers. Private APIs are programming functions that Apple does not document because they’re not considered “stable” — the way they work may change in future releases of the iPhone SDK, or they may disappear altogether. Developers are urged not to rely on these interfaces for key functionality of their products, which makes sense for the most part”.
The words so much desired by many iPhone developers: “While your application has not been rejected, it would be appropriate to resolve this issue [private API] in your next update”. Sounds like a real Christmas gift? From App Store reviewers.
So what is all that? Clemency? Christmas miracle? Or may be Apple is feeling platforms-competitors’ heat behind :)
It may seem to be a small change, but it is a real benefit: instead of having to once again go through the review process and having another couple of weeks of waiting, the developers can simply fix the issue in the next update they submit. It is hard to say right now whether it will be a wide-reaching policy, but “one is a fluke, two is a coincidence, and three is a trend”. Hopefully it will be like this.