Developing software for the iPhone is different - there is no nearly endless memory pool waiting for you to be filled, there is 128MB RAM. Oh, not for the app, for everything! So on the iPhone that leaves about 20 to 30MB RAM for the currently running application. Sounds big? Well, my Mac OS X Mail application currently uses 64MB doing pretty nothing, Twitterific is idle with 32MB RAM ...

The Challenge

Nowadays most developers are used to have Garbage Collectors removing objects from memory which are not used any more automatically, at least on Java. Objective-C 2.0 introduced the very same recently on the Mac Desktop, but it is nowhere seen on the iPhone. And there is probably good reason for it. Maybe. But anyway, that leaves the developers to be very very disciplined on how to work with objects. But on the other side there is this requirement for speed. In some cases these two don't really fit together. To get speed, you need to cache things in memory, but having too many things laying around in memory fills up the precious amount of memory. The memory issue is only on side of the story, since there are lots of other things that can go wrong for sure. So what to do?

Discipline

A proper design, discipline and knowing which function retains objects, which does not ... and knowing that for (mostly) every single line. Talking about WorldView and WorldView Live we thought to have everything set up. A good caching strategy for all those images going round, And in WorldView it worked pretty well, of course there were some hiccups in the beginning too, but overall it was pretty fine in my opinion. (Yes, everybody wants bug free apps, we too!) But then in WorldView Live, which shares quite some code with WorldView, for some users it didn't go that well. Even having a dozen of beta testers using lots of beta versions and trying everything we could to find and solve as many issues as possible, we obviously couldn't.

The road ahead

We had to teach the beta testers how to find crash logs and send them to us. Over and over again. Oh wait - isn't iTunes already fetching all crash data from the iPhone and asks the user if iTunes might send all these files to Apple? And shouldn't the developers have everything they need? Well, nearly. Until the point of sending the data to Apple everything is correct, but sadly developers don't get access to any of that data. We really wonder why.

So already beta testers have to dig around in the desktop file system structure searching for some weird named files and packing them somehow into an email. Ok, packing that into an email isn't that hard nowadays, but anyway! That process is way too complicated! There has to be a way to enhance the communication between beta testers and developers. Somehow.

But what about all the users, who download all these great apps, getting angry about crashes, writing angry iTunes reviews - not knowing the developers can't help them because they cannot contact them because there is no way to do so - not knowing the developers don't have access to the data the users just sent to Apple when that strange dialog box came up - and the app is still so buggy. Blame you developers!

To do or not to do

Even we think the latest version 1.2.0 of WorldView Live is a major step forward in stability for most of the users, we never can be sure we found every glitch in the application - WorldView Live consists of about 150 files source-code with way more than 20.000 lines of code (not including 3rd party libraries!). But lucky there is a light to help making the app even better, improving the communication with the beta testers and also with every user. It is a new open source development library named plcrashreporter developed by Landon Fuller.

"Despite my best efforts to the contrary, I ship software with bugs." (Landon Fuller) - buzzworks does too

This library provides the functionality that the data which is helpful for the developer to find out why an application crashed is available to the application itself once it starts up the next time. So the application can react in an appropriate way. What we did with the latest beta release of the next version of WorldView Live, which we shipped to the beta testers today, is giving the user the option easily send this data to the developer. The user is asked with a dialog if he wants to allow sending the data anonymously and he can deny, allow or even allow always. In the last case the app wouldn't ask the user the next time this happens and send the data automatically.

We even added some more settings to the app setting section in the settings app. From there the user can set or remove the allow always setting, allow the developer access to take a look at the bookmarks the device has (if the backup feature is used) or even provide an email address for the developer to get in touch with the user.

With this new feature and the brilliant library we hope to reach our goal a little closer: create bug free software. Even we are sure we will probably never reach it completely we are doing our best to get closer. This said I would like to thank you for reading all this text and not giving up before ;-)

(If you find bugs in this text, please feel free to file a bug report in the comments, or simply ignore it)