Dr. Touch lost his job as Windows desktop supporter while USA is eating turkey. The following day is “Black Friday” where the holiday shopping frenzy starts.
My script (aka “Show Notes”) after the fold below.
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.
This new release fixes two urgent issues that became pressing today: Downloading and Notifications.
Any version prior to 1.0.12 is no longer able to download reports as of today. So if you put off updating until now then you have no choice any more.
To update either do a fresh checkout or update your existing working copy. If you have not linked your checkout back to the repository please do so and then “SCM – Update Entire Project”.
I’m also announcing the MyAppSales VIP List. If you are a CEO or otherwise important person and cannot be bothered to update your working copy of MyAppSales via XCode then this is for you. I have very limited space available on my device list but for VIPs on this list I will be making AdHoc builds for each future version. You may apply for inclusion via e-mail.
Apple appears to be cracking down on apps these days which are not sticking to the SDK agreement when it comes to using undocumented (read “private”) APIs. I’m attempting to make a list here, so if you have received the usual slap on the wrist for actually using one of the undocumented “features” to make it easier on yourself then please let me know so that I can add it here.
The problem with these undocumented API calls is that up until now Apple did not seem to uniformly care if they where to be found in submitted apps. But lately the reviewers seem to have gotten a static analyzer into their hands. With the help of which they can dump all the method names in your app so they will see if you are naughty or nice.
The official statement is that Apple is working on making more and more undocumented API public. They claim that those APIs are not properly tested and will probably change between OS versions thus breaking apps that rely on them. We’ll see if some of these following methods will eventually really become public.
“I need some help with this issue and I’m hoping you have the time to point me in the right direction, here goes:
- I want to display today’s date in a UILabel, then with a button event, the tricky part…
- display a date 7 days in the future UNLESS it’s the weekend, then it will display the following Monday.
So basically I want to display ONLY weekdays, no weekends… it that even possible?”
Of course it is possible. In this case it’s not even very difficult.
I assume that you know how to display a UILabel and set its text. So in this article I’ll show how to enhance what we previously learned about adding days to NSDates and add extra code to also skip weekend days.
Sure, you should be doing your coding mostly because you enjoy it and only secondarily for the money. But it’s no sin to get a kick out of checking yesterday’s sales report and seeing how well your babies are performing. My aim for MyAppSales is to be the preferred mobile tool for this purpose.
I lost track some months ago, but I estimate my user base to be around 250 people worldwide. Because I am distributing MyAppSales as source code only this automatically requires users to have at least some fleeting knowledge of how to download source code from a Subversion repository. This is called “positive preselection”. That’s one of the reasons why I can hypothesize that MyAppSales users are smarter than the average Cocoa Touch developer.
I am proud of my baby and I was interested to learn which of the multitude of apps which are being tracked with MyAppSales are considered by their makers to be their crowning achievement . So I’ve asked my customers via Twitter which of their apps they deem to be their masterpiece (so far) and today I’m proudly presenting the best apps of the smartest developers to prove the hypothesis from this article’s title. I call this …
Entires are sorted in order of submission. All wordings and descriptions are verbatim. The statements are not meant to be reviews but to illustrate which skills, talent and knowledge need to come together to make what a developer has the right to call “his best app”.
So what are those super powers? You’re about to find out …