I was just about to convert our Mac CoverFlow classes (my partner Martin Carlberg wrote them in our GIS project) to iPhone, when I realized that there is a nice implementation already written by Devin Ross at DevinsHeaven. It is part of a library called Tapku library that can be found at GitHub. I found it while reading the excellent blog Applausible who also has a little tutorial how to use the Tapku classes.

Another implementation I also found on GitHub was Alex Fajkowskij’s OpenFlow. But based on a simple test and run I will try the Tapku library in my first CoverFlow app.

... and you are a bit worried about the current review time on AppStore. Look no further than this site. It is made by @daveverwer on Shiny Development. He made a blog entry where he explains a little about the webpage.

And do not forget so submit your own times to him!

When developing iOS and MacOSX apps I have a toolset that I been using for a while now and I wish to share them for others that might not be aware of some of them.

I have gone from XCode3 to XCode4 now and even if the new one still have a lot of bugs I like the workflow and the editors a lot better than in XCode3. Xcode comes with a fantastic set of profiling and analyzing tools called Instruments. Without it I feel completely lost and insecure. Really difficult bugs are traced down in minutes with Instruments like the Zombies, Alloc and Leaks. Also Apple gives us tools for analyzing OpenGL code like the Performance Detective.

To design and make graphic resources I use Pixelmator (I’m not a Photoshop lover). Pixelmator has the strength I need and can handle, also I like the UI.

As a compliment to image tweaking with Pixelmator I use Opacity for making icons and buttons. It is a marvelous tools and not only does it jpg:s and png:s from vectors, it converts the vector graphics to code. UIView/NSView, CoreAnimation and Quartz code. This is really nice, since you can hide the graphic in code and icons and other graphic resources then goes smoothly into static libraries without distributing folders at the side with graphic files.This tool comes in two versions one standard and one pro. It costs not much money and I will assure you that you will benefit from it. You can even learn how to write the graphic code by just looking at the code it generates.

Another tool I use is Accessorizer, a code generator for snippets like servers and getter, dealloc and such. It its latest version it integrates nicely with XCode. It may not save that much code but to those of you that are quite new to ObjectiveC and iOS it makes the memory handling a lot easier because it knows the rules about alloc, retaining and releasing objects. I think this is the most common problem newcomers have when starting to make a iPhone app.

Since most Apple code and frameworks comes without code it is not that easy to find out how it works internally. I use an old tool that where made in the good old NeXTStep days. It is a command line tool called classdump and it creates header declarations out of Mach-O files. Not a decompiler but good enough to get a clue how the inner workings of a closed framework is built. Classdump is the brainchild of Steve Nygard , a longtime Objective-C guru who also have an interesting blog.

After working with AppKit since 1989 (yes, I’m that old, even older than @johaneltes) I am so used to package my ideas in frameworks so when I started to develop for the iOS platform I almost gave up. Why the .... have Apple only granted themselves to use this fantastic concept. Well, it turned out that there are other solutions and I might understand Apple for that paranoid security concern of theirs.

There are other solutions to the problem even though the best parts of the .frameworks are capsulation and the ability to include resources of different kinds.

One approach is to have your classes in groups that are created from folder that you drop into your different projects. But this don’t get you the freedom to write stuff without sharing the code. It is possible to have the code and the resources in the same or in subgroups.

Another way is to write static libraries with the classes you wish to share between projects. How to do this is explained in the iCodeBlog, excellent reading. The drawback with this solution is of cause that the static library can’t contain resources.

In this post I will share a link to a site written by Ray Wenderlich - http://www.raywenderlich.com/ . He is a programmer / gamer on the iOS platform. In his latest post he explains something that most iOS developers hates - Codesigning, a subject driving almost everybody insane. If it has disturbed you, please read it. He has even made an object model over the entities Apple has used.

I decided to restart my blog. Some years has gone since I wrote something on www.kerusan.org, and I lost track of where I have put all my entries. So here is a complete new site with an empty archive. Last time I got inspired by RapidWeaver’s ability to create a nice blog without breaking my neck. In those days it was RapidWeaver 3 and 4, now I have version 5 and I will continue to use it. But it was not RapidWeaver who inspired me this time, it was all the nice people out on the internet that has started to share programming skills to everybody. I hope I can share a little myself and also give some links to blogs that I follow. Many of them are totally awesome and shares insights about programming on iOS and MacOSX, design and life. They make my day and my work a real joy. Thanks to all of you!