When your iPad application first launches it will be in portrait mode, even if it’s held in landscape mode. The rotate event is already in the queue and is consumed early enough that it’ll never actually be shown like that. So no problem, right?

The problem is that the rotate event will not have been consumed when your viewWillAppear: is first called. Opening a new view controller in viewWillAppear: (whether using presentModalViewController: or a storyboard segue) will open that new view controller in portrait mode, rather than landscape mode. Even that wouldn’t be a problem, except iOS will not add a rotate event added for the new view controller.

This all makes a great deal of sense when you think it through: The rotate events for the initial view controller or controllers are already on queue before viewWillAppear is called. iOS already recognizes the device has been rotated; as far as it’s concerned, the rotation is done. Your app is just lagging a bit behind as part of the startup process, with everything all queued up.

Conceptually, this is a hard problem.

But in practice, there’s a very simple and very elegant solution using blocks.

All you need to do is delay your view controller’s appearance. Before blocks, you might have had to use a timer. But now you can just use dispatch_async to schedule the new view controller for later.

That’s a little confusing, so here’s an example:

I have a view controller that appears when my application is first installed, to walk the user through the signup process. (Later, if there’s an authentication problem, I fall back on the standard username and password alert view.)

This view controller, then, needs to appear when my main view first appears. If I use this code, the view controller that appears will always be in portrait, even if the device is started in landscape.

- (void)viewWillAppear: (BOOL)animated {
    [super viewWillAppear:animated];
    if (freshInstall) {
        [self performSegueWithIdentifier: @"firstRun" sender: self];
    }
}

If I use this code, however, the view controller that appears will match the device (and the view controller it’s appearing over):

- (void)viewWillAppear: (BOOL)animated {
    [super viewWillAppear:animated];
    if (freshInstall) {
        dispatch_async(dispatch_get_main_queue(),^{
            [self performSegueWithIdentifier: @"firstRun" sender: self];
        });
    }
}

Later in this case is still before the user has a chance to interact, or even before the UI really and truly appears onscreen. The block for showing the view controller will be added to the queue. Everything will just work. By the time your block is run from the main queue, the rotation event will be dealt with and your app will really and truly be in landscape orientation. However, it’ll still be early enough for your view controller to look like part of early application startup.

Note: This was done on my “stable” branch, so it was probably on iOS 5. I have not yet tried this on iOS 6, but I’ve read reports this is no longer necessary. Either way, it’s a good trick if you plan on maintaining iOS 5 compatibility (which you should, for a while at least).

Although Objective-C supports exceptions, they’re not commonly used. A thrown exception is usually not caught, making it a fatal error.

The Objective-C Programming Language describes it thus:

Important In many environments, use of exceptions is fairly commonplace. For example, you might throw an exception to signal that a routine could not execute normally—such as when a file is missing or data could not be parsed correctly. Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors. Instead you should use the return value of a method or function to indicate that an error has occurred, and provide information about the problem in an error object. For more information, see Error Handling Programming Guide.

What, then, is the usual pattern for handling non-fatal errors. The answer is the NSError class, along with a few simple conventions:

1. Any method that can fail should return 0 (or an equivalent) on failure.
2. Any method that fails by returning 0 (or an equivalent) on failure should take a pointer to return a NSError instance, which it populates with error details.
3. If the error pointer is NULL, the method should not return an error.

For instance:

- (BOOL)doSomethingWithError: (NSError **)error {

    // other code
    NSError *e;
    if ( ![self bitWithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    return YES;
}

This seems pretty reasonable, but can get unmanageable quickly:

- (BOOL)doSomethingWithError: (NSError **)error {
    
    NSError *e;
    
    if ( ![self part1WithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    if ( ![self part2WithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    if ( ![self part3WithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    return YES;
}

Thankfully, blocks can simplify this for us!

- (BOOL)doSomethingWithError: (NSError **)error {

    BOOL(^fail)(NSError *e) = ^(NSError *e) {
        if (error) *error = e;
        return NO;
    };
    
    NSError *e;
    if ( ![self part1WithError: &e] ) return fail(e);
    
    if ( ![self part2WithError: &e] ) return fail(e);
    
    if ( ![self part3WithError: &e] ) return fail(e);
    
    return YES;
}

Using a fail block has a few advantages:

• You have a single place through which all errors in this method are routed. You can put a breakpoint here, or add logging.
• If you change what doSomethingWithError returns, you change just the return type of the block and the return within the block.
• You eliminate a lot of redundant code, therefore lessening the chance of an error in one of the copies.

Footnote: Usually, if I am writing an if statement, I’ll write it like this:

if (foo) {
    // statement
}

I do this even when it’s not necessary, because what if I expand on it later? And I think this is a good principle. But for a fail block like this, I’m never going to add an extra statement. The whole point of the block is to make sure that the failure code is a single statement.

If I accidentally provide bad XML, I don’t know until my app tries to parse it. That may be some time into its run. If the XML is processed because of a specific user action, I’ve broken that specific user action. So we’re going to build a build phase to validate the XML.

Obviously, I want to test everything in my app before I post it to the iTunes Store. But finding this problem even hours later makes it harder to diagnose and fix. I can detect this error immediately (and fix it right away) by adding a build phase to validate my XML.

I added a run script to my target that does this:

find "${PROJECT_DIR}" -name *.xml -exec xmllint {} ;

See update below.

Xcode will run this script when building my target. It will find all XML files in my project directory, and run xmllint on them. xmllint returns an error if the document is malformed.

I gave this build phase a good name so I can find it easily later, then dragged the script as high in my build phase order as possible to get the results early. This may not actually prevent the project from building, but at least I get a big red error.

This validates all the XML in my project directory. If you have XML you don’t need, you’ll have to do something more complicated:

• Provide a more specific starting path
• Use one of the other variables validate the built .app package instead, or
• Hard code each XML file’s path

Update

This command works better:

find "${PROJECT_DIR}" -name *.xml -print0 | xargs -n 1 -0 xmllint

With this command, the error not only stops Xcode, but Xcode highlights the line that xmllint reports as the offender.