Do we have to set all properties to nil in -init or is this happening automatically?

Question

I always believed that the runtime automatically initializes all properties with nil when an object is created.

But the release build for the App Store is different than the debug build during development. I have heard Xcode creates more stable builds for debugging with various security check mechanisms around variables and properties that prevent crashes but bloat up the code.

When you build for distribution, so is the myth, compiler optimizations strip out this "unnecessary" debug code to make the code faster.

I have already experienced mysterious bugs that suddenly happened in release builds. But now a developer also told me this: In the release build, the runtime does NOT set the properties to nil. They are uninitialized. Their value is garbage memory, unless you do it manually. So !foobar is not safe to check unless you initialize the properties with nil.

So far all my apps always assume properties are nil unless I set an object.

Is this correct or does the runtime still initialize our properties to nil when we create an object?

Answer 1

The developer in question is wrong and you should hold any other "advice" they've given you as highly suspect.

All instance variables, including those synthesized by @property, will always be zeroed out on allocation by the Objective-C runtime. This has been the defined, documented, behavior of the Objective-C runtime since the language's inception.

Static variables will always be initialized to zero/nil/NULL, too. Local variables will be uninitialized under manual-retain-release and initialized to zero/nil/NULL when using ARC.

There are two key differences between DEBUG and RELEASE builds:

• the linker will strip away any debugging symbols. This makes the code harder to debug, but makes the executable considerably smaller.

• the optimizer will optimize for code size and speed.

It is that second one that causes the "mysterious" changes in behavior between DEBUG and RELEASE. The optimizer will re-use stack space and re-order operations in the code (that can be re-ordered; method calls cannot, for example) as necessary to make the code faster and smaller. This tends to uncover bugs that exist in DEBUG builds, but aren't tripped because the compiler isn't moving stuff about on the stack.