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.

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.

Recent versions of Xcode have been a lot better. I’m not sure when they really improved, but in the most recent build of Xcode they take only a split second. So far, they seem reliable. And they work by storing the source in a private git repository, so they’re pretty efficient, too. This does not affect your real git repository, even if you’re using git. This is entirely separate, deep in Xcode’s private directory tree deep in your home folder.

Xcode can run a behaviour when a build succeeds. I noticed a few days ago that there’s also an option to Create snapshot.

You may need to scroll down to see the Create snapshot option.

This means that every time my project builds successfully, a snapshot is created. The snapshots are small, basically containing only the changes since the last build. I expect I can leave this on basically forever without running out of disk space.

I commit to git many times during the course of the day, but occasionally I’ll be in a refactor and I won’t be committing every time the project builds. I’ll make a few changes, build and fix any errors, make a few more changes. I’ll keep this up several times, until I’ve made the full refactor I want. Only then will I fully test what I’ve done and commit.

Sometimes I’ll make the wrong change, and break the build in ways I can’t easily fix. At that point, I either need to struggle my way out of the errors I’ve introduced or abandon all the changes I’ve made. Yes, I could commit to git every time. But the smaller each individual change is, the less likely I am to bother.

In my defence, I still think the way Xcode uses snapshots by default is useless. They’re offered before major but atomic changes, which is right after I’ve committed to my source control repository manually.

But these continuous snapshots are another matter. This means I can back out of any particular change back to the previous working code without losing all the changes so far in what I consider the full, atomic refactor.

I’m thrilled this feature exists, and I’ll be using it from now on. I think you should give it a try, too. Even if you commit to your source control system constantly, this will make commits you won’t think to, and without any action on your part.

Me: Yeah?

Xcode: You want to enable snapshots yet?

Me: No.

Xcode: I’m just asking.

Me: No.

Xcode: They’re good for you, you know.

Me: I’m sure they are, but see, I’ve already backed up my project. In fact, I checked it all into source control. You were there, right?

Xcode: Yeah, but can I enable snapshots? Please?

Me: No. Stop asking.

Xcode: I’ve caught you at a bad time.

Me: That’s not it. I don’t actually want snapshots. They’re redundant, and frankly a bit stupid. It makes me feel like you don’t respect me enough to make my own backups, you know?

Xcode: Oh. I can see that. I’ll ask again later, then.

Open Xcode. Choose Welcome to Xcode from the Window menu. Check Show this window when Xcode launches.

Alternatively, you can turn it back on from Terminal with this command: defaults delete com.apple.dt.Xcode XCShowWelcomeWindow

For all I know, this has always been a feature of Xcode. But I’ve never noticed it before. So for this stunning display of common sense: Well done, Apple!

Rather than set these per project, I have a .xcconfig file I add to my project. I then base each build configuration off this file. Changing the .xcconfig file changes all projects based on it (though with the current Xcode, it’s sometimes necessary to reload the project to get the settings to take).

//
//  MoreWarnings.xcconfig
//
//  Created by Steven Fisher:
//      http://tewha.net/2010/11/xcode-warnings/
//  See also:
//      http://boredzo.org/blog/archives/2009-11-07/warnings
//


GCC_WARN_CHECK_SWITCH_STATEMENTS = YES
GCC_WARN_SHADOW = YES
GCC_WARN_64_TO_32_BIT_CONVERSION = YES
GCC_WARN_INITIALIZER_NOT_FULLY_BRACKETED = YES
GCC_WARN_ABOUT_RETURN_TYPE = YES
GCC_WARN_MISSING_PARENTHESES = YES
GCC_WARN_ABOUT_MISSING_FIELD_INITIALIZERS = YES
GCC_WARN_ABOUT_MISSING_NEWLINE = YES
GCC_WARN_SIGN_COMPARE = YES
GCC_WARN_UNDECLARED_SELECTOR = YES
GCC_WARN_UNUSED_FUNCTION = YES
GCC_WARN_UNUSED_LABEL = YES
GCC_WARN_UNUSED_VALUE = YES
GCC_WARN_UNUSED_VARIABLE = YES
GCC_WARN_ABOUT_MISSING_PROTOTYPES = YES
GCC_WARN_TYPECHECK_CALLS_TO_PRINTF = YES
GCC_WARN_ABOUT_DEPRECATED_FUNCTIONS = YES
GCC_WARN_HIDDEN_VIRTUAL_FUNCTIONS = YES
GCC_WARN_ABOUT_INVALID_OFFSETOF_MACRO = YES
GCC_WARN_NON_VIRTUAL_DESTRUCTOR = YES
GCC_TREAT_WARNINGS_AS_ERRORS = YES
RUN_CLANG_STATIC_ANALYZER = YES

A few notes:

• Like Peter, I don’t turn on GCC_WARN_UNUSED_PARAMETER. Although you can add __unused to each parameter to disable the warning, doing so breaks Xcode’s code formatting. I use code formatting constantly, so anything that breaks it isn’t acceptable.
• The warnings that were the most painful to turn on were GCC_WARN_64_TO_32_BIT_CONVERSION and GCC_WARN_SIGN_COMPARE. If you use int and NSInteger interchangeably, you’re going to have a tough time with these. (I don’t, but some of the internal libraries I use do.) These are also some of the more dangerous warnings to fix; if you’ve got automated tests, you should run them after every few corrections.
• RUN_CLANG_STATIC_ANALYZER will roughly double (or more) the time your project takes to compile. I consider this a good trade: I rarely trigger a static analyzer warning now, but when I do I want to fix it.
• Also note the GCC_TREAT_WARNINGS_AS_ERRORS. If you are applying these to an existing project, you may start with hundreds of warnings. You’ll probably want to start with this set to NO and change it to YES after you’ve fixed the warnings.
• Remember, too, that this changes the defaults for settings. You can still specify different settings in the build configuration! If the static analyzer is taking too long to run in one project, just turn it off in that one project but leave the .xcconfig file alone!

By that, I mean that aside from the standard keyboard shortcuts (Save, Copy… that sort of thing), none of the keyboard shortcuts made sense to me.

So I duplicated one of the keyboard shortcut profiles and deleted most of the keyboard bindings. I was brutal with it — if the combination didn’t make sense to me OR it was something I’d rarely use it was removed. Then I added keyboard shortcuts that I needed. By using about an hour to customize these settings, I ended up having keyboard shortcuts that I fully understood and rolled off my fingertips.

At this point — and this is where it became a useful exercise — I added my ~/Library/Application Support/Xcode to version control so I could easily sync it between computers. So when I find something that isn’t quite working out for me, I make a change and propagate it to my other system.

Am I going to share what I ended up with? No, because that’s not the point of this. Rather, I want to point out a simple fact of Xcode: Xcode will adapt to how you want to use it, and if you feel like you’re suffering at all with it you should spend the time it to takes to make it enjoyable to use.

And when someone tells me I can do something with a particular keyboard shortcut, I switch back to the defaults and see what it’s bound to.

Xcode will automatically recognize iPhone OS 3.0.1 and look for a new SDK at a set path. The problem is that SDK doesn’t exist. The good part is that the iPhone OS 3.0 SDK works perfectly for developing 3.0.1. The only apparent change is the SMS fix.

Assuming you’ve installed to /Developer, the iPhone OS 3.0 SDK is here:

/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0 (7A341)

When using Xcode with iPhone OS 3.0.1, Xcode looks for the iPhone OS 3.0.1 SDK here:

/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0.1

The trick, then, is to build a symbolic link that connects what Xcode is looking for with what it needs to find.

So what do you do? Assuming you’ve installed Xcode in the standard location, this is a Terminal command to fix the problem:

ln -s /Developer/Platforms/iPhoneOS.platform/DeviceSupport\

DeviceSupport/3.0.1

(I’ve split this into three lines to make it easier to copy and paste with the \ line continuation character.)

This will not add a SDK to Xcode’s list, it will just teach Xcode to map your device to the 3.0 SDK.

A few other tips:

• If you still can’t debug restarting your iPhone may help. Most of the iPhones I’ve tried to debug on, I’ve had to restart first.
• If you get an error regarding code signing, try downloading your provisioning profile again and re-installing it. Also, select it again in your build settings.

Based on information from iPhone OS 3.0.1 Advisory.

Like everyone other Mac developer (at least, those not using a seed… no comment otherwise), I’ve been bit by the Mac OS X 10.5.7 bug that causes Xcode to crash almost every time the documentation viewer is used.

Now I’m a reasonable guy. I get that a Mac OS X update has to be thoroughly tested. I wouldn’t want it otherwise. So let me get this off my chest right away: it isn’t the bug itself that bothers me.

Xcode 3.1.3 shipped after Mac OS X 10.5.7. So it should have been pretty easy to add code to Xcode see if the developer has executed a defaults write com.apple.xcode dontevershowthefuckingdocviewer 1 and then never show the documentation viewer, so I wouldn’t lose unsaved work every time I forgot and tried to open it. ((Maybe use a different identifier for it.))

And in the future, the documentation links should be handled via an URL type that can be handled by another application.

And, oh yeah:

Why is the documentation viewer embedded in the IDE?

Splitting the documentation viewer into a separate application would make a lot of sense. Browsers crash! If it wasn’t this, it would be something else that crashed the documentation viewer. This was predictable. This was, dare I say, expected.

But what really, really makes me angry is the developer site. The content is generally pretty good, but the search engine is horrible:

• Fix your summary so it’s actually useful. Apple’s summary: Google’s summary: There’s just no comparison. ((Google, you rock.))
• I don’t need to see every single empty redirect. Showing the same effective document multiple times is just random clutter.
• There are better ways to represent the format of documentation in search results than just including it in the URL.
• Add up those last two items, and you realize: I don’t need PDFs in the search results. PDF should just be linked to from the documentation itself.

I’ll update this when I have more points. The bile has receded enough for me to code again.