More and more video streaming apps arrive on the app store. More tablet rumors and a new iPhone coming next year.
My script (aka “Show Notes”) after the fold below.
When I started on Twitter, I tried out a few Twitter clients both on Mac and iPhone until I quickly settled on Tweetie. When Loren Brichter made the bold move to sell Tweetie 2 as a seperate app I also purchased it because I am convinced this guy means quality and Tweetie 2 is on the first page of my springboard.
One thing that’s cool about Tweetie 2 is the fresh paradigm to refreshing the contents of a table view. Up until now we had been looking for space to mount a reload button on, sometimes having to resort to adding an extra tool bar for just one view so that you can have enough space. Now if you have a tableview that it sorted reverse chronologically, then you have a natural urge to make new items appear at the top by pulling down the table with extra force.
Loren recognized this need and innovated the Pull-To-Reload paradigm. If you want to refresh a tableview in Tweetie 2 then you simply pull down the table far enough for an additional cell to appear at the top with the instruction “Pull down to refresh”. If you do, then at a certain point the arrow rotates and the text changes to “Release to refresh”. All accompanied by two distinct wooshing sounds and a pop once the reloading action has ceased. The Intuitiveness of this paradigm is so compelling in fact that people who use Tweetie 2 start to try to refresh ALL tableviews like this.
Might be a good case to make this the standard way from now on because it feels more logical and natural than to tap on a small button with a circular arrow on it. A user of MyAppSales requested that I add this mechanism for reloading reviews of individual apps. At first I thought this to be advanced magic, probably using forbidden techniques. But after a bit of research and lots of hints coming from my Twitter friends (thanks Thomas and Fabian) I figured it out. This article explains how I did it.
There are a couple of users of MyAppSales who have been collecting daily reports since the first feeble beginnings. Turns out that if you have upwards of 300 reports in your apps.db then the previous method of loading everything at program start has a major drawback. There is a watchdog timer which kills any app that takes more than 20 seconds to start which caused a couple of users grief because that’s how long it took to load on iPhone 2G or 3G if you had that many reports.
This release is all about startup speed. On my own iPhone 3GS I managed to get from 12 seconds down to about 2. Also I was intrigued by the request to add a Tweetie-2-like Pull-To-Refresh mechanism, so that’s in there as well.
Generally if you have any issues after applying this update then please go to the settings page and tap “Empty Caches”. This removes all the cached .dat files keeping information for faster access.
Now that I am coding full time I can spend hours and hours on lots of things. I have to literally force myself not to take on too much before releasing a new version. I’ll have to start updating all my other apps, create some new ones and then there are some looming contracts.
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.