For a while, though, Xcode has supported a build option Create Info.plist Section In Binary, also known as CREATE_INFOPLIST_SECTION_IN_BINARY. If on, this will embed the target’s Info.plist into the executable as a data segment.

I couldn’t find any documentation on how to get it out, though. After a lot of searching, I came up with getsectbyname. This is defined in mach-o/getsect.h like so:

extern const struct section_64 *getsectbyname(
    const char *segname,
    const char *sectname);

(There’s a 32-bit version as well, but I was only interested in 64-bit.)

One of the fields in section_64 was the address of the data in memory, another its size. Easy to wrap with a NSData, right?

Not so fast. This worked in debug and release builds when run in Xcode, but didn’t work when run on Terminal or Instruments. There, accessing the raw bytes caused a segmentation fault.

A tweet from Greg Parker put me on track.

The difference turned out to be Address space layout randomization (ASLR). You can read all about it on Wikipedia, but the gist of it is that in order to make it harder to exploit a vulnerability many operating systems have implemented a system where executables are randomly located in the address space. This makes it harder for injected code to access application or system code. The results returned by getsectbyname don’t take ASLR into account.

Instead of using getsectbyname, I had to use getsectiondata. getsectiondata would return a pointer to the exact data I needed. It took me quite a while to find anything relevant online.

It’s declared like this:

extern uint8_t *getsectiondata(
    const struct mach_header *mhp,
    const char *segname,
    const char *sectname,
    unsigned long *size);

But what’s that fist thing, the mach_header?

It took me a long time to find anything relevant, but I eventually found out that I needed to use _mh_execute_header from mach-o/ldsyms.h.

The resulting code looks like this, and works:

#include <mach-o/getsect.h>
#include <mach-o/ldsyms.h>

- (instancetype)init {
    self = [super init];
    if (!self) return nil;
    
    NSError *e;
    unsigned long size;
    void *ptr = getsectiondata(&_mh_execute_header, "__TEXT", "__info_plist", &size);
    NSData *plistData = [NSData dataWithBytesNoCopy:ptr length:size freeWhenDone:NO];
   _infoPlistContents = [NSPropertyListSerialization propertyListWithData:plistData options:NSPropertyListImmutable format:NULL error:&e];

   return self;
}

This only works in the application; if you need to do this from a dynamic library, try this approach from Cédric Luthi.

Full credit to those two, but I wanted to post something about this so that future searches might find it. Thanks, guys!

There’s also C99 initializer syntax.

The main advantage to the C99 syntax is that it gives you some very Objective-C like syntax, where the fields are close to the values rather than implied by positioning. (That’s not to say this is intentionally similar, or that it’s the only advantage. But it is nice.) It also provides type checking, and since fields are named it catches drifts in meaning that you otherwise wouldn’t catch.

It’s sometimes slightly more typing, but I use it everywhere now.

The syntax

Consider the CGRectMake way to make a rectangle:

CGRect a = CGRectMake(a+c/2, b+d/2, c, d);

In order to understand this, you need to understand the order of the parameters. You also need to be able to catch the commas easily with your eyes. In this case, that’s pretty easy, but if the expressions were more complicated you’d probably be storing them in a temporary variable first.

The C99 way:

CGRect a = (CGRect){
    .origin.x = a+c/2,
    .origin.y = b+d/2,
    .size.width = c,
    .size.height = d
};

It’s longer, but it’s more explicit. It’s also very easy to follow what is assigned to what, no matter how long the expression are. It’s also more like an Objective-C method. After all, if CGRect was a class, it would probably look like this:

CGRect a = [[CGRect alloc] initWithOriginX:x originY:y width:w height:h];

Note that any field you don’t explicitly initialize is initialized to zero. This code, for instance, will create a rectangle with an origin of 0,0.

CGRect smallRect = (CGRect){
    .size = mySize
}

The C99 syntax is a nice compromise; it’s more compact than class construction, but still names field values.

Catching changes

Naming fields might seem like extra work, but it’s also extra safety. If the names or meanings of the parameters change, you’re going to get compiler errors. The compiler will help you find these, now! And if you write new code based on the old rules, compiler errors will point out what you’ve done.

This isn’t much of a concern for CGRect; it is how it is. Apple is probably never going to redefine it. But many years ago, QuickDraw used edges for its Rect structure instead of points. If you were still trying to break that habit, the compiler would complain every time you did this:

CGRect a = (CGRect){
    .left = 0,
    .right = 100,
    .top = 0,
    .bottom = 100
};

In your own code, this may be an active concern to you. You may have structs (or use C libraries that have structs) that will change layout in the future.

Type checking

That’s only the start of C99 initializer coolness, though.

You can also do things like this:

CGRect a = (CGRect){
    .origin = myOrigin,
    .size = computedSize
};

Here, you’re building a rectangle using a CGPoint and CGSize. The compiler understands that .origin expects a CGPoint, and .size expects a CGSize. You’ve provided that. All’s gravy.

The equivalent code would be CGRectMake(myOrigin.x, myOrigin.y, size.width, size.height). By using CGRectMake you’re no longer expressing the same kind of meaning to the compiler. It can’t stop you from assigning part of the size to the origin. It also won’t stop you from assigning the width to the height. It doesn’t even give you a good clue about which is the X and Y; if you’ve used APIs that provide vertical coordinates first, you’ll get it wrong. If you’re used to APIs that provide two points or something else (like QuickDraw’s edges) instead of a point and size you’ll also get a compiler error.

You can assign part from a structure and part from floats as well:

CGRect a = (CGRect){
    .origin = myOrigin,
    .size.width = c,
    .size.height = d
};

Drawbacks

As I said, this is more typing than CGRectMake. What I didn’t say is that it’s even more typing than you expect, because as of Xcode 4.6, you still can’t autocomplete the field names. You really do need to type all that extra code.

I think this is a good pay off for being able to read the code so easily later, but you may disagree.

Conclusion

The CGRectMake function predates C99. I have no evidence to this effect, but I think if C99 had come first CGRectMake probably wouldn’t exist at all; it’s the sort of crusty function you write when your language has no direct way to perform the initialization. But now it does.

This doesn’t only apply to CGRect. Any of the simple struct types can be initialized this way, such as CGPoint, CGSize and NSRange.

Avantages:

• Explicit: You’ve named the parameters.
• Type safe: You’ve provided enough meaning to the compiler that it can help you not screw up.
• Easy to read: Especially with longer expressions, you’ve eliminated needing to scan for commas when you read the code later.

Disadvantages:

• More typing: You read code a lot more than you type it, so I think this is a great tradeoff.

Averaged over time, anything you can screw up you eventually will. Using defensive techniques makes sense. Try it for a while; I think you’ll like it!

Special thanks to:

• Peter Hosey for reminding me how QuickDraw worked and inspiring “Catching changes.”

• Luke Bernardi for reminding me that Xcode’s autocompletion can’t suggest field names.

• BJ Homer for tipping me that unnamed fields are initialized to 0.

Let me start with this bold statement, then I’ll back up and explain it: Use instancetype whenever it’s appropriate, which is whenever a class returns an instance of that same class.

First, some definitions:

@interface Foo:NSObject
- (id)initWithBar:(NSInteger)bar; // initializer
+ (id)fooWithBar:(NSInteger)bar;  // convenience constructor
@end

For a convenience constructor, you should always use instancetype. The compiler does not automatically convert id to instancetype.

For initializer, it’s more complicated. When you type this:

- (id)initWithBar:(NSInteger)bar

…the compiler will pretend you typed this instead:

- (instancetype)initWithBar:(NSInteger)bar

This was necessary for ARC. This is why people will tell you it isn’t necessary to use instancetype, though I contend you should. The rest of this answer deals with this.

There’s three advantages:

1. Explicit. Your code is doing what it says, rather than something else.
2. Pattern. You’re building good habits for times it does matter, which do exist.
3. Consistency. You’ve established some consistency to your code, which makes it more readable.

Explicit

It’s true that there’s no technical benefit to returning instancetype from an init. But this is because the compiler automatically converts the id to instancetype. You are relying on this quirk; while you’re writing that the init returns an id, the compiler is interpreting it as if it returns an instancetype.

These are equivalent to the compiler:

- (id)initWithBar:(NSInteger)bar;
- (instancetype)initWithBar:(NSInteger)bar;

These are not equivalent to your eyes. At best, you will learn to ignore the difference and skim over it. This is not something you should learn to ignore.

Pattern

While there’s no difference with init and other methods, there is a different as soon as you define a convenience constructor.

These two are not equivalent:

+ (id)fooWithBar:(NSInteger)bar;
+ (instancetype)fooWithBar:(NSInteger)bar;

You want the second form. If you are used to typing instancetype as the return type of a constructor, you’ll get it right every time.

Consistency

Finally, imagine if you put it all together: you want an init function and also a convenience constructor.

If you use id for init, you end up with code like this:

- (id)initWithBar:(NSInteger)bar;
+ (instancetype)fooWithBar:(NSInteger)bar;

But if you use instancetype, you get this:

- (instancetype)initWithBar:(NSInteger)bar;
+ (instancetype)fooWithBar:(NSInteger)bar;

It’s more consistent and more readable. They return the same thing, and now that’s obvious.

Conclusion

Unless you’re intentionally writing code for old compilers, you should use instancetype when appropriate.

You should hesitate before writing a message that returns id. Ask yourself: Is this returning an instance of this class? If so, it’s an instancetype.

There are certainly cases where you need to return id; namely, if you’re returning a different class. But you’ll probably use instancetype much more frequently than id.

When?

This is straight from Clang Language Extensions:

• the first word is “alloc” or “new”, and the method is a class method, or
• the first word is “autorelease”, “init”, “retain”, or “self”, and the method is an instance method.

Left unsaid is whether it’s better to actually specify instancetype for these rather than rely on automatic promotion of id. Most code I’ve seen relies on the automatic promotion. I’m not sure what combination this is of momentum, readability, compatibility and convention. I’ve kept to using id in these cases, but that’s mostly due to momentum.

However, you should certainly use instancetype if you want to specify that an instance of the receiving class is returned in cases where autopromotion doesn’t occur, such as a convenience factory.

For example, in this case:

MyObject *bar = [MyObject objectWithParameter: foo];

…you would want MyObject to specify that objectWithParameter returns an instancetype rather than an id.

See also:

• Mattt Thompson: instancetype.

In this article, I’ll discuss the advantages of @property which make it worth using, and discuss “dot syntax.”

Properties

Properties are awesome. A @property declaration formalizes some things that previously had to be explained in comments or by convention.

Without properties, you’d specify a getter and setter like this:

@interface Bar : NSObject
- (void)setFoo: (NSObject *)foo;
- (NSObject *)foo;
@end

With properties, you can specify it like this:

@interface Bar : NSObject
@property (readwrite, atomic, strong) NSObject *foo;
@end

Whereas a set accessor defines only the owning object and the new value, a @property declaration specifies the memory management model for the new value. Is the setter going to copy it, own it, or just assign it? With ARC, these become even more useful: You can copy it, specify that it’s kept via a strong reference, specify that it’s a weak, zeroing reference, or specify that it’s a weak reference that could become a dangling pointer.

Further, you can specify whether the property is atomic: If two threads try to access a property at the same time, is the behaviour fully defined?

Even more useful, if your getter and setter are trivial Objective-C can synthesize them for you. (In older compilers, you needed to specify this with @synthesize; in the latest version, the compiler will do this for you.)

Note: If you write your own getter/setter, you’re responsible for making sure it complies with the memory model and atomicity you’ve specified in the @property. The @property is a promise to other compilation units, and your object is not held to that promise by the compiler.

What is dot syntax?

Dot syntax is syntactical sugar for accessing properties. Whereas the @property statement defines the property, dot syntax is an option for calling it.

Excluding dot syntax these are equivalent:

_view1.frame = _view2.frame;
[_view1 setFrame: [_view2 frame]];

There are some unexpected gotchas involving dot syntax. This, for instance, does not compile:

_view1.frame.size.width = 10;

The reason is it’s equivalent to this:

[_view1 frame].size.width = 10;

You can’t change a field in a rvalue like this. Instead, you need to do this:

CGFrame frame = _view1.frame;
frame.size.width = 10;
_view1.frame = frame;

This shows an important distinction: dot syntax may look like struct access, but it isn’t the same thing at all.

Using dot syntax

In some cases the compiler will even let you get away with dot syntax for methods that aren’t properties. But you really shouldn’t; Objective-C isn’t Visual Basic (where this is supported) and this runs counter to the language. In the past, I’ve seen Apple engineers argue that doing so is taking advantage of a compiler limitation that will probably eventually be fixed. Or maybe it’s a compiler limitation that they’ll never get around to fixing. In either case, it’s taking advantage of a compiler limitation.

There’s a huge grey area here. Some will argue setting a property shouldn’t have side effects, shouldn’t perform an action, or many things between.

Clearly, setting something without side effects is a property. I think most Objective-C developers will agree with this, though some argue that calling code at all makes dot syntax inappropriate. The argument is that it looks like struct access, so it should behave exactly like struct access. I don’t agree with this, but some very wise people do.

By UIKit convention, visual side effects (such as changing a frame) is acceptable. Some of these are true properties, complete with a @property definition. Some lack the @property definition, as @proeprty predates much of UIKit but make sense as properties anyway. (I picked UIKit here because it’s more modern than AppKit, but the same applies there.)

However, a method that takes no parameters but does not return a value is clearly not a property. Obviously, a method that takes parameters that do not conform to a getter/setter signature does not represent part of a property.

This, while legal under some configurations, is never appropriate:

obj.release;

Dot syntax should be limited to things that are semantically properties only. Whether you further limit that to things that are only defined with @property is up to you. I do for my own objects, but I prefer to believe that Apple would fix UIKit’s missing @property definitions before enforcing this at a compiler level. If I’m wrong, it’ll be easy enough to remove dot syntax from the affected code. But I think it’s more likely that Apple won’t enforce this at the compiler level.

There are even greyer areas to this. What constitutes a property? For instance, is NSArray’s count a property? I would argue it isn’t; it’s an attribute, a side-effect based on the other properties of the NSArray. But Apple template code uses the count of an array as if it was a property, and the result is not horrible. You could certainly argue it’s wrong, but I view it as just over the line.

Conclusion

Embrace @property. The additional information it supplies regarding memory management and thread safety is great. Not only that, but it’s less code than the old way of declaring your getter and setter.

Use dot syntax where appropriate. You need to decide where the line is for yourself, as there are no hard rules about this. Everyone has an opinion over it, and the only thing you can be sure of is that there’s little consensus, except that some things are always inappropriate.

You may have code that looks like this:

if (_foo) {
    @synchronized(self) {
        // stuff here
    }
}

This can also be expressed more simply:

if (_foo) @synchronized(self) {
    // stuff here
}

Note that you can’t use this if your if has an else statement.

This is also true of @autoreleasepool, and may be even more handy there:

for (NSDictionary *item in items) {
    @autoreleasepool {
        // lots of stuff here
    }
}

Can become:

for (NSDictionary *item in items) @autoreleasepool {
    // lots of stuff here
}

Now, always making C statements compound in a condition or loop is a pretty common convention. And if you stick by this convention in other places (as I do), that’s fine. But the reasoning behind it doesn’t really apply with @autoreleasepool and @synchronized: you can just consider them part of the opening bracket.

Unfortunately, you can’t do this at the top level of message handlers. Wouldn’t that be nice?

I started at the most basic level, wondering at the language. What are these brackets? What’s with the @ signs? What’s the difference between a - and a +? These aren’t hard things to learn, but understanding the reasoning behind them helps. And then there’s a point where it suddenly makes sense.

But the framework was confusing. How do I do this? Though I was less confused, this one isn’t solved directly. I became competent. And I started to ask the best question: “Why?”

The patterns were still confusing. Why does this work this way? What’s the purpose of this? Why is this done, but not this other thing?

And then there was a point where the patterns became obvious. More, the pattern in the patterns became obvious to me. And now, I look to find more examples of patterns, and patterns of patterns, to better build my knowledge.

It took me a while to get here, and it’s the same for every language. I’m feeling pretty confident about Objective-C now.

Back on the first day, I was confused and lost.