I love POC

POC stands for Plain Old C structure. A POC contains no references nor pointers, but only primitive value types or other POCs. No C++ elements (no user defined constructor, operator, etc)

The good of POC is that it is guaranteed to be allocated within a continuous memory space, so classic memory functions such as memcpy, memset works nicely on POC or array of POCs. Additionally, you get a free assignment operator, which is quite important for data types.

POC works very good with NSData for local file storage. Just copy the memory content of a POC into NSData and call writeToFile, saving the whole byte string to the file, easily done. If it's not a POC... well good luck manual-serializing fields of an instance while saving and de-serializing them while loading, don't get the order wrong! Of course, using POC you probably need to mind the debug/release settings, for the compiler may pad within POC, causing a different size between debug and release mode. Files written by application compiled under different modes may not compatible.

Tips to Use Interface Builder As Much As Possible

The Interface Builder of the XCode Suite is particularly powerful. It is very handy when developing for iPhone/iPod touch. However, it comes with some difficulty when you actually want to generate and place your widget programmingly. For example: you have a scroll view with several buttons inside that align vertically, however the number of buttons and the texts on them are decided at run-time so you can't simply drag some in using Interface Builder. But neither do you want to go after all these tedious API calls to create buttons then configure formats manually either; what then?

You can actually design a "sample button" using Interface Builder, have all the formats done (which is nice and easy using IB), then put it at the root of the widget hierarchy. Since it is not a sub-view of any other widgets, it is not shown at run-time. Then you can use the following code to copy this button as you want, place it anywhere you want, without worrying the format:

NSData *archived = [NSKeyedArchiver archivedDataWithRootObject: button_sample];

//Initiate buttons based on a sample

UIButton* b = [NSKeyedUnarchiver unarchiveObjectWithData: archived];

//set text, change position...

...

Mix C++ code with Objective C for iPhone

Objective C is not the only language you can use to program for iPhone; you can use C/C++ and mix the C/C++ code with your Objective C code. And I recommend to do so:

Reason 1: for cross-platform purposes. If you use only Objective C then you are locked on the Apple platform. Don't give up the chance of porting your program to other devices such as Zune HD.

Reason 2: for the better C++ standard STL library. IMHO the STL library is much better than Objective C Cocoa libraries; it is portable and easier to use. Especially the container part.

To those who are worried, iphone run-time have full support for C++, including virtual function, exception handling and RTTI. And Xcode does support template.

There is no explicit boundary between C++ and Objective C when you code for iphone. You can write Objective C code in C++ classes/functions, and vice versa. But notice that the source code file other than headers should be named as ".mm".

Althrough you can mix C++ and Objective C, a good idea is to separate them for better portability and maintainability. When comes to a problem that both C++ and Objective C have solutions, I prefer to write the C++ code when possible and only write Objective C code where Cocoa library provides an easier solution, or when only it has the solution. For example, the Cocoa container classes suck but they do provide very easy to use persistance functions; so I use STL container and only translate the content to the Cocoa counter part when I need to save the content to a file.

A trick is that, you can provide Objective C implementation for C++ classes. I would use multiple implementation files for a C++ class interface: keep C++ only impl in one and Objective C impl in another.

The Matrix Phone Improved - been Objective C, now go back to C++

The first version of The Matrix Phone is submitted to AppStore and is pending for review; however, this is far from the end. I'm now planning to develop a better game scheme for The Matrix Phone.

(Now the geek part)
As my first application that is written in Objective C, it is far from optimal: I were not familar with Objective C at that time - now I realize that the code is a mess, and is almost impossible to refactory to support new gaming schemes. After a period of struggling, I decide to re-write it in C++ (plus some Objective C code for iphone); I just have to do this anyway, maybe The Matrix Phone can be on Microsoft Zune.

Been Objective C, now go back to C++:
I know the STL containers are not the only way, but without them and use NS containers of Objective C just don't feel right! Basically, the NS containers is generic typeless "store-by-pointer" containers like those in Java - but without garbage collection. And you can't store regular C structure by value; and there is no auto boxing/unboxing so even if it is int you have to pack it/cast it back manually with NSNumber. So I avoid using it and end up with stinky malloc.
And string operation using NSMutableString is so painful. Even putting two strings together is a hard job. No simple "+" like Java; no container-like operations like std::string. So I just use C string but that's no better...