Laggards start with an edge when it comes to migrating to new/updated solutions: most of the problem areas have already been identified, discussed and resolved. Oh really?

Bread and butter: where’s our stuff?

Apple kindly provides an XCode 4 Transition guide. I’ve only skimmed through it and find myself moderately able to build my existing project.

Where is Get Info? It’s kind of been moved to a side panel which is disabled by default. Go to View > Utilities > File Inspector.

I added my file, it’s there! But when I build the file is missing. I had several flavors of this error:

I moved my .pch file; frankly this has nothing to do with xcode4. The location of the .pch seems to be relative to the project folder by default. so if your .pch is in a subfolder then the path should be changed to subfolder/myPrefix.pch or such.

I add files and they get marked red!

My files are still not found. Check what the path is relative to (open the ‘File Inspector’). I was migrating files and I noticed that they got marked as ‘relative to group’, and this caused files not to be found by the compiler. Heck, this is rather confusing.

Where is the ‘build’ button? I love running ‘just a build’ (instead of ‘build and run’), just to make sure my tests are doing OK. Apparently the toolbar can’t be customized anymore. Sigh… So yea, I got no f****g idea where this stuff is gone.
=> however you can build from the Product menu (Product > Build) or learn the shortcut (Cmd+B).

Where is the organizer?
=> Top right button in XCode window.

Where is repository/source control management?
=> in the organizer

How do I rename my project? It can be done in two ways (see below). Both methods will pop an interface where you can select matching entries to rename in project data. It is crude, but works. Unfortunately this doesn’t rename folders created by the project wizard. So MyProject/MyProject would be renamed to YourProject/MyProject (to keep tidy, it may be a good idea to rename your source and test folders to just ‘source’ and ‘test’ right after creating a new project)

In the project browser (click-wait-click onto the project icon/name), in the same way as you would rename a file in Finder.

In the attributes inspector (top right, edit project name) when the project node is selected.

How do I set NSZombieEnabled? Go to the scheme manager and edit environment variables for the matching target. If you can’t find it check this nice post from 42games (pics included).

For a quick, yet more comprehensive tour of where the f***k’s everything in xc4, read pilky.me.

Interface builder…

IB is now integrated within XCode. It’s a bit weird, and also means that we can’t take advantage of a second display to work with IB and XCode simultaneously.

The document window/nib browser has been replaced by a kind of left hand toolbar when opening a nib file. By default this toolbar would show something like unlabeled icons for the file owner, first responder and main view. There’s a tiny triangle at the bottom left that will reveal a hierarchic view that looks like the old nib browser.

Workspaces

Create a new workspace: go to File > New > New Workspace. Easy.

Add a project to your workspace: drag the project file in your workspace/project browser. Drop towards the far left of the project browser (otherwise it will drop inside an existing project).

Workspaces don’t do away with having to setup static libraries as a better way to share code across projects; however workspaces ‘look like they might be nice’. If you’re experience code sharing issues, workspaces may be the best reason to upgrade (to XCode 4, that is).

What can’t I close the ‘extra tabbed editor’?

Go to View > Editor and select Standard.

The good, the bad, the ugly (and ((self=[super init])))

This has always been OK; better than OK in fact, it’s an OC idiom:

if( self=[super init] ){ … }

Now it’s not. It triggers a warning. Well…

if(self=[super init]) is sucky. Instead of having well formed constructors we have this magic incantation that doesn’t even make it rain.

if((self=[super init])) is suckier. It’s ugly.

So I did the suckiest thing. I switched my compiler version to LLVM GCC 4.2(*), which appears to be my so called ‘system default’, and unchecked the missing braces and parentheses warnings. I’m sure you think it’s a bad idea to disable warnings. So I went back to XCode 3.2 momentarily, to find that the warning’s always been unchecked. WTF, there’s more than 100k iOS devs out there, and here we are, wondering why our projects are forcibly ‘upgraded’ the betterest-most-pedantically-improved-style.

(*) I just did it. You can find equivalent solutions whatever compiler version you set.

What do I do with this ‘Missing File’ *.xcscheme is missing from working copy warning?

It appears that when deleting/renaming schemes, the schemes may not be mark-deleted from source control. However XCode keeps track of our working copy, so it will soon be complaining that the file is missing from the working copy.

Use your favorite source control utility to remove the file from the repo; the warning will disappear.

I had hardly managed to download and install this little mammoth of an IDE when a colleague turned up, trying to migrate existing C++ projects to XCode4. Here are the main issues we encountered:

MainWindow.xib not found. The project we looked at didn’t actually used a nib file or a main window (not very surprising with a migrated-from-C/C++-game-type-y-project). It somehow hooked a custom ‘main controller’ object using UIApplicationMain(…). However, the main window was listed in the project’s info.plist.

=> We deleted the MainWindow entry in the plist file (not just removed the name, actually removed the entry). If you list a MainWindow in your plist file, but actually start the app in a different way, XCode 3.x will just ignore the main window (most likely, fail silently). XCode 4.x will ‘fail fast’ (in other words, crash your app).

“Bad codegen, pointer diff linker error…”. This is a linkage conflict that will typically happen when linking against several libraries built within the same project. The somehow likely reason this happens is XCode4 changed it’s default policy for handling external library symbols that do not declare access restrictions. So before these symbols didn’t get exported, but now they do, and the same, intended-to-be-internal-by-default-symbol is duplicated across two libraries or more.

=> Edit build settings for each target (the libraries we’re building and linking against): change the ‘Symbols Hidden By Default’ setting to true (as suggested in this stack overflow item). Now that I’m looking at one of my existing projects in XCode 3.x, I seem to find that ‘Symbols hidden by default’ is already checked).

Linkage error (files not found)

By default, XCode 4.x does not use the same build output directories as XCode3.x. Here we just updated (erased) absolute paths we found under ‘path to search for libraries’ or such.