I don’t envy the programmers who write IDEs like Xcode or Visual Studio; they’re tasked with designing an incredibly complex piece of software that’s both powerful and easy to use, and their end users (other programmers) are a particularly cranky bunch.
But still. I’m not really an IDE power user (I still edit code outside the IDE using vi; how’s that for old-school?), and I’m willing to overlook many quirks, as long as I can get my work done. But over the last year or so of using Xcode, I’ve run across a few bugs that were irritating enough to merit special mention.
These are all bugs that have existed since before Xcode 4.0, and still exist in the most recent version that I’m using (4.2.1 at time of writing).
1. Header maps cause #include confusion
Let’s say you have a C or C++ header file that declares some math functions, and you put it in a header file called “math.h”. You might expect that this include directive
would include your header file, while
would include the standard math header (containing the usual declarations for cos(), etc).
Well, you’d be wrong; both will include your own math.h, causing all sorts of problems.
To work around this, you can, of course, rename your header file to something else (e.g. “mymath.h”), which will fix the problem (until some poor sap creates a header file called “string.h”).
Alternatively, you can disable the use of “header maps”. In your target’s build settings, click the “Add Build Setting” button, and choose “Add User-Defined Setting”; the name of the setting should be USE_HEADERMAP, and the value should be NO.
2. Folder references containing resources are not considered dependencies
If you have a folder full of data files that you want to be included in your application bundle, you can add each file individually to the project. If there are a lot of files there, and you are often adding or removing them, this quickly becomes a headache, and you might want to instead add a reference to the folder, so any new files you add to that folder are automatically added to the bundle. You can do this in Xcode by selecting the “Create folder references for any added folders” radio button when you are selecting files to add to your project.
If you do this, though, the files in that folder will not be considered a dependency of your build target. So, for example, if you make any changes to the files in that folder, the new versions will not be copied to the application bundle unless you clean the build first.
Workarounds: remember to do a Clean before building after updating data files; or add a “Run Script” build phase that touches the folder before the “Copy Bundle Resources” phase of each build.
3. Projects that depend on static libraries built by other projects don’t always link to the right library
If your workspace contains a project that builds a static library and an executable that links that that library, Xcode is supposed to magically detect the dependencies, so changes to the library’s source code cause the library to be rebuilt and re-linked to the application. Unfortunately, sometimes Xcode gets confused and, after rebuilding the library, links the application to an old version of the library. So you make a change to your library’s code and run your test program; you see Xcode compiling the library and linking your test program; but when your test program runs, it’s running the old code.
Doing a clean before each build will fix this, but who wants to do that?
A fix I’ve found to work is to select the icon in the application’s project that represents the library in the Project Navigator; then in the File Inspector, set the “Location” drop-down to “Relative to Build Products”.
4. Apps fail to start in the iOS simulator
I run into this one all the time. I try to debug my app in the iOS simulator, and I see from the output that the debugger is trying to attach to the process, but the app never actually starts. If I try to run again, it usually manages to attach right away. It’s a minor inconvenience, but it happens often enough to drive me just a little bit nuts.