Ad

Our DNA is written in Swift
Jump

How to make a Pull-To-Reload TableView just like Tweetie 2

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.

Read more

MyAppSales 1.0.14 "Go Faster Strips"

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.

Changes:

  • Pull To RefreshADDED: Added Pull-to-Refresh on all review table views. Just like in Tweetie 2.
  • CHANGED: If a review text or rating changes then the review will now be updated and marked as changed.
  • FIXED: Country assignments for some report regions where incorrect causing financial reports to be incorrectly rejected as duplicate. Fixed translation language for China.
  • FIXED: Changed from GET to POST for Google Translations to support extra long review texts.
  • FIXED: Bug would cause link between InAppPurchase and App to disappear upon restart
  • CHANGED: Rewrote totalling to cache and replace averaging
  • CHANGED: Numerous performance improvements
  • ADDED: Lazy loading for reviews for additional speed improvement on startup
  • ADDED: Transparent 2-stage loading of reviews to speed up opening of review page for an app
  • CHANGED: Made more UI elements opaque to speed up table view drawing
  • ADDED: Financial and Monthly Free download on Import/Export homepage

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.

Dr. Touch #006 – "And the Winner is…"

Appsfire Award 2009 Winners announced and the problem with fake reviews.

Subscribe to the Podcast in iTunes

My script (aka “Show Notes”) after the fold below.

Read more

iTunes Release Dates

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.

Read more

Dr. Touch #005 – "Advent Calendars"

Don’t forget to open all those windows on those app advent calendars.

Subscribe to the Podcast in iTunes

My script (aka “Show Notes”) after the fold below.

Read more

Dr. Touch #004 – "Revolution"

Our favorite company gives in, it’s revolutionary!

Subscribe to the Podcast in iTunes

My script (aka “Show Notes”) after the fold below.

Read more

MyAppSales 1.0.13 "Mo' Money"

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.

Changes:

  • FIXED: Prevent app from saving incomplete reports without a date. This would cause a crash on subsequent starts of the app. There are also additional measures to prevent loading such a report should it be present in the database.
  • FIXED: Added missing country FI as identifier for Europe region of financial reports.
  • FIXED: Added missing country CO as identifier for USA region.
  • FIXED: Correct spelling of country Vietnam. This would cause a financial report with this country in the first line to be detected as “rest of world”.
  • CHANGED: If you have reports from more than one app grouping (aka Apple account) then reports for those no longer show the apps of other groupings.
  • CHANGED: Apps and IAPs are now child classes of Product to allow for polymorphism.
  • ADDED: IAP Products are now kept in a separate table from apps
  • ADDED: IAP support on the overview and country detail report views
  • ADDED: IAP support for export via built-in web server

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.

Dr. Touch #003 – “Freedom At Last”

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.

Subscribe to the Podcast in iTunes

My script (aka “Show Notes”) after the fold below.

Read more

Though Shalt Not Make Predictions

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?

  • Don’t trust me (or any iPhone Developer) on any kind of prediction related to commercial success or failure of individual apps.
  • Diversify to reduce negative impact if single apps.
  • Partner with other people. It’s better to have a small share in something big, then to have everything of nothing.
  • Just try it out. Even hobby projects will increase your programming and marketing skills. But you need to see them through from initial inception all the way until they can be purchased on the app store.
  • Don’t try to be “right”. You’ll rarely be. Instead try to be “in” with the profits of many apps.
  • Don’t let your ego get the better of you. Don’t get cocky. Much of my income is a direct result of partnering with two teenagers half my age (Laurens and Fabian)
  • And the correlary to the previous learning: if you are under age, don’t be afraid to contact me and let me publish your app for a portion of the profits.

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.

The World on an NSString

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)

Read more