Appsfire Award 2009 Winners announced and the problem with fake reviews.
My script (aka “Show Notes”) after the fold below.
Mingleboy asked Apple via E-Mail:
“Why does my updated app not appear amongst the new apps even though I changed the release date on iTunes Connect?”
We all remember that previously it was possible to hop to the first pages of iTunes by changing this date. And of course this “feature” was exploited quite a bit by developers hoping to achieve additional attention for their apps and thus additional sales.
Apple recently fixed this to match what they originally intended, it appears now that it was a bug in the system anyway that Apple willingly ignored for some time until the gaming of release dates overboarded. I reported about this change in Episode 1 of the Dr. Touch Podcast.
This new release is about fully integrating In App Purchases (IAP) into MyAppSales. Until now I did not need for IAPs to be displayed correctly because none of my apps have them. But my friends over at Crowded Road kept insisting that this is a key feature, so I invested some time to give IAP the special treatment.
The other reporting apps I had a look at tread IAPs just like regular apps, because at first glance they look the same in Apple’s reports. They have an apple identifier, but it’s not valid to open iTunes with it. To tell IAPs apart from apps you have to look for the IA1 transaction code and the filled in parent code. In the table the transaction is represented as 101 because it needs to be numeric.
Personally I am opposed to showing IAPs at the same level as apps and therefore MyAppSales shows you IAPs as part of the total royalties and average daily sales on the app page and also integrates it into the report views. If you don’t have IAPs you will not notice any difference in the UI.
Still you are encouraged to update your working copy to the latest version in the repo’s trunk or the release-1.0.13 tag because of the multitude of small fixes contained and for IAPs to be handled correctly should you ever have any on any report.
Bug reports or feature requests please add to my bug tracker.
I suck at predicting. Really. I appears that I am proven wrong time and again when it comes to seeing the future. One area where this can be seen rather clearly is when it comes to the success of the apps I have coded so far.
Half a year ago I already ranted about I lost Millions of Dollars because Apple did not permit my first two killer apps into the store. One (DropClock) was too dangerous, the other (MyAppSales) was incompatible with the SDK Agreement. Both apps I had very high hopes for because of their uniqueness or usefulness at the time. Niente.
iWoman I had originally created it for my (now) wife to keep track of her female cycle days. I was also my first full project going from start to finish, so I saw it mostly as a means to learn certain techniques being new to the platform. Therefore I did not make a prediction as to the immediate income, basically telling myself: Who would need this app besides of my wife? Well, I could not have predicted at that time that most of my income would come from “the long tail”.
This tail I am talking about is the constant trickle of sales you get even long after you released an app. It would inadvertently follow any kind of initial peak and be a result of a constant influx of new shoppers on the Apple app store. So my commercial disinterest in iWoman kind of proved me wrong once again. Until two days ago iWoman was responsible for a major portion of my total income from app sales.
It seems to be an inborn need for humans to successfully predict. And then when it turns out that the predictions where wrong, we find reasons correlations excuses what external influences out of our influence where to blame. And of course in the rare circumstance that your predictions actually pan out, we feel exhilarated and brag about how clairvoyant we have been.
Some time ago I started to do publishing deals with other guys. Like for example my 50:50 partnership for LuckyWheel. For my 80:20 partnership for Frequency Annoyer. I figured, since I cannot successfully predict the success of a single app I would diversify and be content with a portion of the profits of many apps as opposed to all of the profits or non-profits of only my own. That’s when I essentially also became a publisher.
For LuckyWheel I was doing the coding and my partner Michael Dorn did the artwork and questions. We split the profits evenly. LuckyWheel failed to make me rich as well, but it was sticking to the sold second place on the long tail, right behind iWoman.
Being a publisher does not mean my prediction track record improved. The diversification this brings simply reduces a negative impact from single apps and improves the long tail scenario. When Laurens approached me to publish his first app I was extremely skeptical. Who would want to buy an app like Frequency Annoyer? Hey, so I thought, it’s evil to annoy people with a high pitched tone that they cannot localized. Laurens was extremely enthusiastic, it was his first app, and he told me that he is confident that this will sell really well.
So for 20% of the profits I agreed to publish it after riding him hard to make some UI and usability improvements. But those apparently paid off, the app was approved the first time we submitted it, because I had learned by now how to avoid most of the kinks that would cause Apple to reject apps. Again, not a major surge to prompt instant retirement, but a sold long tail. So solid in fact that after overtaking LuckyWheel every now and then, it conquered the second place in daily income some weeks ago.
Laurens approached me for his second big app, this time even more confident. He said he was certain that even more people would purchase his latest invention the Full Screen Browser. Again I failed to see the potential, but my rate was set. 20% and I publish anything. And good luck. FSB got rejected twice by Apple. Once for not setting the age rating to 17+ as any app has to have if there is unfiltered access to the internet through it. The second time because Laurens was using the undocumented method setOrientation which is an incredibly irreplaceably useful method, but still forbidden. Well, we got that worked around and resubmitted.
I did not want to tell Laurens my opinion at that time. Who in his right mind would purchase a browser when there is Safari built into every iPhone? Full Screen Browsing for one Dollar? Seriously? Don’t you agree that this is a silly proposition?
If you answered Yes to the previous question that you fell into the same trap as me. We developers think we know what the customers want, but fail to notice the reality that we don’t. We can code extremely well, but only the customer knows that the customer wants. Hell, billions of dollars are spent by companies every year on trying to find out what the next big thing will be. Which political party will win. Which stock will go up. The matter of the fact is that nobody is good as predicting, but big companies have money to spend on the hope that somebody actually is. The logic goes: if I pay you a thousand dollars and you do a study then I should get a more valuable result than just predicting myself. Namely the result will be worth a thousand dollars, because of the simple rule of the market: Something is always worth as much as a willing buyer and a willing seller can agree upon. Or put differently: something is only worth as much as somebody pays your for it.
You probably guessed it by now, that FSB absolutely rocks my reports. Shakes my foundation of beliefs. Makes me feel warm and fuzzy inside. In just two days since it got on the store, Laurens has already sold 574 copies. So in just two days he made more money with FSB than in the 2 months before with Frequency Annoyer. 2 months versus 2 days. That’s over 2900% more success than I had predicted.
They say you can make numbers talk in any way you like if you just torture them long enough. But I am at a loss here. I have NO idea how to make these numbers prove my predictions.
What the morale of this story?
Yesterday a prediction of mine was proven wrong in an entirely different area. About a year ago I had predicted that a big international company would have to keep it’s Windows desktop support staff while reducing in other areas. Even a small staff (100 machines in 2 locations) still requires maintenance and logistics and a local person taking care of their hardware needs, right? It’s logical. There is no other way. So I thought this to be a safe bet that I had made and I felt secure throughout the financial crisis.
Still I was proven wrong. Big company decided to completely lay of the local IT support staff and replace it with remote support. W00t?! I’m laughing and crying at the same time. Crying because I can imagine the support hell that this will be for my former colleagues. Laughing because you now have access to Dr. Touch Cocoa Helpdesk full time. The doctor is in tha house!
So in closing I predict that I will refrain from predicting henceforth. Rather lets orient ourselves on the facts at hand. Fact is, my iPhone business has grown substantially over the last year. Fact is, I am a much better Cocoa coder than I was a year ago. Fact is, I am in constant contact with thousands of developers worldwide through this blog, twitter and lately also a new podcast. Fact is, I am frequently being approached by people with small and big iPhone projects.
So I predict that I should be fine.
When you are are newbie in programming objective-C then you might find somethings confusing when you start using strings. Coming from C you where used to using zero terminated C-Strings. Coming from other languages you might be challenged by the fact that there is no implicit type conversion like, for example, in BASIC.
In regular C strings are pointers of type “char *”, meaning that it’s the memory address of a one byte character. The length of a C-String is determined by a binary zero ” at the end of it. Objective-C rarely uses those, instead NSString means the world to us.
The core fundamental to realize first is that you are always dealing with pointers – that is addresses in memory – when using objects (instances of classes). So it simply does not make sense to compare strings with the == operator. Two variables pointing to NSString might or might not actually point to the same instance. (Actually the same was true for C-Strings, because the same text might or might not be contained in different memory regions referenced by char * pointers)
Yves Gonzales asked:
“Would you know what the URL scheme is for writing a review in the AppStore, launched from within an app in iPhone, which opens AppStore? (I want to ask users to leave a review.)”
At first I answered that I did not think this was possible. But Yves, with the help of trusty Mr. Google discovered a better answer than mine. There is in fact a possibility to get the mobile App Store app to open on the review page for a specific app.