How to make Crash resistant ios apps

Question

I'm now programming ios apps for a while. But still my apps crash regularly and it takes time to make them very stable. I find this very annoying.

So, are there any programming patterns regarding crash proof programming ios app?

Answer 1

• Turn up the compiler warnings. Remove all warnings.
• Run the static analyzer. Remove all warnings.
• Run with GuardMalloc and/or Scribbling.
• Remove all Leaks
• Remove all Zombies
• Write Unit Tests
• Write a high level of live error detection (e.g. assertions)
• Fix bugs before adding features.
• Use source control and continuous integration.
• Read. Improve.

Answer 2

1) Use ARC.

ARC has a small learning curve, and the big problem I read about on SO is that people instantiate objects but forget to assign the object to a strong ivar (or property), so the object mysteriously goes away. In any case the benefit is so compelling you should master this. When you do, most of all the memory management stuff you have to keep straight now goes away.

2) Build clean

You should never ever have warnings when you build. If you have a bunch, when a real problem comes up, it gets buried in the lines of cruft you got use to ignoring. Professional programmers build clean.

3) Use Analyze

Xcode/llvm has a phenomenal analyzer - use it - its under the Product menu item. Then clean up every single warning it gives you.

4) Use the right Configuration

I always have a Release (or Distribution) configuration, a ReleaseWithAsserts, and Debug. I only use Debug when using lldb, as the code is much bigger and it will execute differently than an optimized compile will. ReleaseWithAsserts is similar to Debug, but the Debug=1 preprocessor flag is removed, and the optimizer is set to -Os (the default for Release).

Finally, the Release/Distribution configuration has the following in the Preprocessing Macros:

NS_BLOCK_ASSERTIONS=1 NDEBUG

The first turns off all 'NSAssert()' lines, and the second all 'assert()' statements. This way no asserts are active in your shipped code

5) Use copious amounts of asserts.

Asserts are one of the best friends you can have as a programmer. I see sooooo many questions here that would never get written if programmers only would use them. The overhead is in typing them, since (in my usage) they are compiled away in the Release configuration.

Whenever you get an object from another source, assert its existence (ie:

MyObject *foo = [self someMethod];
assert(foo);

This is sooo easy to type, but will save you hours of debugging when a nil object causes problems thousands of instructions later. You can assert on class too:

MyObject *foo = [self someMethod];
assert([foo isMemberOfClass:[MyObject class]]);

This is particularly useful when you are pulling objects out of dictionaries.

You can put asserts at the start of methods, to verify that you received objects not nil too.

You can assert that some variable has a value:

assert(i>1 && i<5);

Again, in all but the Release/Distribution configuration, the assert is "live", but in that configuration they are compiled out.

NSAssert is similar - but you have to use different macros depending on the number of arguments.

NSAssert(foo, @"Foo was nil");
NSAssert1(foo, @"Foo was nil, and i=%d", i);
...

6) Use selective Logs to insure that things that should happen are

You can define your own Log macro, which gets compiled out for Release/Distribution. Add this to your pch file:

#ifndef NDEBUG

#define MYLog NSLog

#else

#define MYLog(format, ...)

#endif

This points up another point - you can use:

#ifndef NDEBUG
...
#endif

to block out a bit of code that does more complex checks - and its just active for your development builds, not for Release/Distribution.