1. 1. Manage memory properly, but resist the urge to use 

      1	retainCount

      , it’s a bad idea. Also, it’s better not use

      1	autorelease.

   2. Draw on the available toolset to improve the quality of the code: Instruments, to find the root cause of bugs; Shark, to improve performance; Clang Static Analyzer, to get the most detailed and comprehensive compiler warnings.
   3. Try to anticipate every iOS update, because there will always be changes to be made.
   4. Develop re-entrant code, because every method could be interrupted and the app could get any message in any state: it’s very important to remember this before coding every method. Read the open-sourced iPhone app code available on the net: the idioms and the patterns are very different from the Java/C++ paradigm.
   5. Beware of using SQLite with flash memory I/O: it will block the GUI.

The tools to decompile iPhone apps are quite well-known:

• Otx, an advanced disassembler based on otool
• class_dump_z, an updated version of the old class-dump for the iPhoneOS, to extract Objective‑C class interfaces
• Hex-Rays, the most advanced decompiler ever, also supports ARM binaries (based on Datarescue’s IDA Pro)

Unfortunately, there’s no easy way to obfuscate iPhone apps, even if the iPhone is 4 years old. The easiest approach would be to take advantage of the LLVM source-to-source feature to recompile the mobile apps to an intermediate high level-language and transform the source code using a specialized tool like TXL to modify the control flow before generating the final binaries. Delving into the LLVM route, it would be ideal for using more sophisticated obfuscation techniques to bring the superb DynInst into play, but it doesn’t support the ARM instruction set. As a final point, there is a commercial tool to obfuscate Objective‑C, Morpher, although there are not outside reviews about its value.