Lesson 1

I really like working with Cocoa on the iPhone. I really do. Some things are a bit odd and some things are a bit annoying. For instance, UIAlertView will always call the same delegate function of its delegate, so if you have multiple UIAlertViews opened from the same UIViewController, you either need to have multiple delegates or keep track of which UIAlertView is currently open.

One thing, I am struggling to accept is the didRecieveMemoryWarning function of UIViewController. Whenever the phone runs low on memory, this function will be called on all your view controllers. Default behaviour is that they will unload the associated view if not currently visible. Once the view should reappear it will be reloaded.

That sounds like a good idea, but it basically means that you cannot have any state saved in the UIView. All states must be saved in the UIViewController. This is a bit annoying, because it means that UITextView contents, UILabels, UIScrollView positions etc. etc. must be stored every time a view is covered with e.g. a modal view. Some of these things you should do anyway if you are developing according to MVC. One thing you cannot really do it with is the CALayer which is specifically associated with a layer of a UIView and therefore deallocated once the UIView is deallocated. Overall, the strategy really is a bit annoying.

Fortunately, didReceiveMemoryWarning is not called very often, but it can be called when you least expect it. So I think this is a design blunder on Apple's behalf, because it means that you have two choices. 1 implement your own didReceiveMemoryWarning function that does nothing or close to nothing. 2 save the state of your view in every viewWillDisappear call, and restore it in every viewWillAppear call. And remember you really have to do either of these two things for your app to work correctly.

I am wondering how many developers are concerned about it, and how many crashes this is causing in the apps on the app store. Everyone is complaining about crashes. Personally, I have never given it much thought until I started noticing crashes in XmasizeMe because I stored data in a UIView, which would be deallocated. The fix was to only deallocate the data I could give up instead of the entire view. What was more puzzling, was that the didReceiveMemoryWarning occured at a point where there should have been plenty of memory. The likely cause was the allocation of a couple of CALayers with a large image (1024x1024).

The idea, that you app can free up some memory once in a while is really really good, but I think Apple should have not implemented a default behavior that frees your view. Unfortunately, if Apple had not implemented this, I probably would never noticed the functionality. From now on I will use it more actively.

Lesson 2

XmasizeMe is really the center of these two lessons. The discussion of Lesson 1, resulted in me submitting an app with a crash problem. Something I am not proud of. Lesson 2 is a bit more serious.

After one day of availability on ITMS I have had a total of .... tada.... 24 downloads of XmasizeMe. Yes, I know 24 is a magical number in December, but really this is not good. I should have had 200 downloads the first day.

So what went wrong? Well I got two reviews on the US store. One wrote that an elf and a reindeer were missing (3 stars). The other complained about crashes (1 star). I had initially dropped the idea of making xmas-cards because I felt I did not have enough content to build them. The other reason, because I felt I did not have anything to add to this market. After discovering how many xmas-card apps there are on the app-store I should have gone with my initial feeling here.

The fact really is that if you want to make money on the app-store you need to be original, and make something that a very large fraction of users will instantly want. Otherwise, you will not survive in this market. Making small apps like XmasizeMe is not going to work in the long run, because they only appeal to a small fraction of users, they go by highly unnoticed due to the app-store system, and seasonal apps with a low number of features can only sell during the season to which they apply.

Buyers want a load of features in the apps for $0.99. It makes sense to complain about crashes, but it doesn't make sense to complain about missing features in software that costs < $1. I doubt the majority of the $1 apps are making serious money. The biggest problem with the app-store is that a lot of developers are setting the prices too low, so people have started to expect too much from $0.99 app. Unfortunately, you cannot sell a lot of apps for a price > $0.99.

In reality, there are too many developers for this market now. I am wondering if this will change over the next 6 months, but I doubt it. Everyone is coming to the party to see if there is a bit of gold to pick up. Unfortunately, like for most parties, most people will not get lucky. Now I am wondering, if I will...