You may not always prefer this default action – for example, if a JavaScript file is imported, Xcode does not know what to do with this file type so a compile warning is generated, see the example below:

I ran into this recently when I added a JavaScript file that is associated with an Openx ad that I wanted to displayed inside my application, using a UIWebView.

There is a simple fix, drag/drop the offending file(s) from the Compile Sources folder to the Copy Bundle Resources folder within the applications Target, which will simply include the file in the application bundle with no processing of the file (this is where you will typically see image files, sound files, etc).

In the image below, the file foo.js has been moved into the Copy Bundle Resources folder:

This is the first post of what I hope is many where we can share tips and tricks on working with Xcode.

Tip #1 – Split Editor View Vertically

If you like to have multiple code windows open at once, the Split Editor option is your friend (see the little square grid icon shown below).

By default, the windows are split horizontally. If you prefer to view your code side-by-side (nice for comparing), here’s how to tell the split to be vertical

1. Hold down Option key when clicking the Split Window icon

Tip #2 – Comment Out a Block of Code

You can quickly comment out a block of code as follows:

1. Select one or more lines of code to comment
2. Command-/

To uncomment a block of code, repeat the steps above.

Tip #3 – Toggle Between .h and .m Files (aka Switch to Counterpart)

Within your current code window, you can swap between the .h and .m file as follows:

1. Command-Option Up-Arrow

Tip #4 – Map Keys to Actions (Key Bindings)

The Switch to Counterpart tip above is a real time saver. However, I often find that if I map logical key-strokes to actions I’m much more likely to get into the habit of using them. For example, I mapped the Switch to Counterpart to Option-S, as in Swap or Switch.

Here’s how to set key bindings in Xcode

1. From the Xcode menu choose Prefereces
2. Select Key Bindings
3. Click on one of the Actions in the list
4. Tap on the Keys column on the right
5. Enter the keystroke you want to map to the action
6. Click Ok to save your changes

Tip #5 – Jump to API Documentation

Showing relevant API documentation for anything within the SDK(s) is as simple as:

1. Option Double-Click on relevant code

For example, in the screenshot below, after Option double-clicking on UIToolbar, a popup window shows a summary of the class information.

Tip #6 – Traverse File History

As you open and edit various files, Xcode keeps a history list of your actions, not unlike when using a web-browser. You can move through the list using the directional arrows as shown below:

The keystoke equivalent for the above is:

1. Option-Command Left-Arrow goto to previous file
2. Option-Command Right-Arrow goto to next file

Tip #7 – Set a Bookmark

I can’t imagine coding without having the option to set a bookmark as a placeholder for what I’m working on. I do this regularly when I need to segue to another file to find a snippet or otherwise poke around outside the current file I’m working on.

Setting a bookmark is as simple as:

1. Control-D
2. Enter a name for the bookmark

Tip #8 – Jump to Bookmark

There are two options to jump to a bookmark. First, you can select the bookmark icon in the upper right corner of the Editor window.

You can bring up the same menu as shown in the above figure using this keystoke:

1. Control-4

Tip #9 – Indent / Un-indent Code

You can indent a line of code or a selected block of code as follows:

1. Command-[ move code left
2. Command-] move code right

The above works regardless of where you are in a line of code, in other words, you don’t have to be at the beginning of the line.

Tip #10 – Zoom Editor

You can toggle between Detail view and Editor view by clicking the Editor button as shown here:

The keystroke equivalent of the above is:

1. Shift-Command-E

Have an Xcode Tip to Share?

If you have a favorite tip or trick, please post a comment or send tips to me here. Killer Xcode Tips and Tricks – Tips 11 to 20 will be posted next week, and suggestions are welcome!

Path to Xcode Simulator Files

The path to the simulator files is here:

/Users/USER_NAME/Library/Application Support/iPhone Simulator/User/Applications

USER_NAME is the current user logged in on the machine. There is a unique identifier created by the simulator, one value for each application. The figure below shows how this looks on my machine, notice there are two entries in the Applications folder, one for each of the current applications I am working on.

In the application App-Vol1 you can see that I am creating a custom plist file Favorites.plist and storing the file in the Documents directory. This is the file I referred to earlier that I update whenever the user quits the application.

Easy Access to Simulator Files

To make access to the simulator files quick and easy, I keep an entry on the left side of Finder titled iPhone Simulator. Simply navigate your way to the simulator files and drag/drop the folder on the left sidebar. You can rename this folder by right-clicking and choosing Rename.

Static analysis does a deeper parsing of your code than a traditional compilation. It looks through each potential code path and can find potential problems that are not obvious to the compiler (and may be missed by you as well).

How it Works

The code below compiles just fine, no warnings. However, Xcode 3.2 will flag a few potential problems when running an analysis of the code. To run the analyzer, from the Build menu, choose Build and Analyze.

- (BOOL)getSomeValue:(int)x
{
  BOOL positiveFlag;
 
  if (x < 0)   
  {    
   positiveFlag = NO;   
  }   
  else if (x > 0)
  {
    positiveFlag = YES;
  }  
 
  return positiveFlag;
 
}

If you look in the Build Results window, you’ll see more information:

• Variable ‘positiveflag’ declared without an initial value
• Uninitialized or undefined value returned to caller

The problem occurs in this code if the value of x == 0, given the variable positiveflag has no default value set, it may not return what you expect.

Showing Control Flow

Here’s an interesting option you have within the integration of static analysis in Xcode – click on one of the entries in the Build Results window (as shown below):

and Xcode will highlight the flow of the code, and help you pinpoint the potential problem:

Run Static Analysis with Each Build

By default, you request a static analysis of your code by selecting Build and Analyze in the Build menu. If you would like a static analysis run whenever you build a project with the debug configuration, you can check the Run Static Analyzer in the Build Options as shown in the image below:

Let’s start with how to get your system working with Snow Leopard:

Install Xcode/SDK for Snow Leopard

1. Install Snow Leopard from DVD
2. Install Xcode 3.2 from Snow Leopard DVD
3. Download and install iPhone SDK 3.0 for Snow Leopard from Apple Developer Connection

Once installed, upon opening a project you may see something similar to the following (which I received when opening a recent project):

Notice the reference to “iPhone Device 2.2.1 (missing)”. This project was built for 2.2.1 before I upgrade Xcode. On a similar note, if you open the dialog to set the device and distribution settings, here is how things will look:

Again, the references to earlier SDK’s are no longer available.

Targetging 2.2 or Earlier Version of iPhone SDK

The trick to targeting earlier versions of the SDK is now done through the Deployment section in the Build preferences. In the image below you’ll see a reference to iPhone OS Deployment Target along with a list of available OS target options.

Choose the target you need, clean, rebuild, and with that, you should be good to go.

For ad-hoc builds of your application, by default, iTunes will display a generic icon for your application. The default artwork for an ad-hoc build looks as follows:

To add artwork so beta testers will see an icon within iTunes, you add a file with the name iTunesArtwork to your application bundle.

Add iTunes icon to Xcode Project:

* Create a png or jpg file that is 512×512 pixels
* In the Groups & Files list, right click on Resources group
* Choose Add, followed by Existing Files…
* Select the file you created, iTunesArtwork
* In the popup dialog, check Copy items into destination group’s folder
* Click Add

Clean and rebuild your project. When you add the application to iTunes, you should now see the artwork now tied to the application.

Caveats:
So the above sounds simple enough, which it is, however, there are a few gotcha’s that made this simple process go from what should of been 10 minutes of tinkering to an hour of hair pulling.

Let me point out the steps that may trip you up:

#1 – The file must be named iTunesArtwork with no extension, and don’t forget to capitalize the T and A (hmmm, there’s a joke in there somewhere).

#2 – I now know that you can’t start with a filename that has an extension of jpg or png and simply rename the file. For example, I had a 512×512 image that I created for the App Store. Seemed a reasonable assumption that if I renamed the file, everything would be copacetic. I went into Finder, right clicked on the file and removed the extension. No go. I could add to the project as shown above, however, the icon would not show up in iTunes.

After trying various file types (png, jpg), adding the file in different locations (root of the project, resources folder, etc), I decided to create a new image altogether thinking maybe the image was wonky. When saving the image in the image editor, I specified not to add a file extension. Shazam, that was the problem!

You’ll know if you’ve done this correctly as the file within the Resources folder will show up without an extension:

as compared to this:

#3 – There was a known bug within Xcode in an earlier version that generated the error 0xE8000058. This would happen when you switched from creating an ad-hoc build to a debug version and attempted to install on a device.

If you run into this error, remove the file iTunesArtwork from your application bundle (you can leave the file, just delete the reference to it) and rebuild.

In this post I will show you two ways to access the imported resources, one by specifying a path, one using an application bundle, both examples will focus on working with images. The code below is an example of building a path to a resource, avoiding a hardcoded path by using index values maintained within the application.

int modelIndex = 2, imageIndex = 5;
...
NSString *imageName = 
  [NSString stringWithFormat:@"/Model-%02d/coverflow/CoverFlow-%02d.jpg", 
   modelIndex, imageIndex];
NSLog(@"image: %@", imageName);

The output in the debug console looks as follows, notice the full path to the image:

2009-06-09 08:20:30.732 AppName[25154:20b] image: /Model-02/coverflow/CoverFlow-05.jpg

You can create a UIImageView referencing the file using the code shown below. The method imageNamed: looks for the image in the application’s main bundle if this is the first request for the image. If the image has been loaded previously, the image is retrieved from the system maintained internal cache.

UIImageView *wallpaper = 
  [[UIImageView alloc] initWithImage:[UIImage imageNamed:imageName]];

There are times when you will need to reference resources by working with the main application bundle. Following on the same theme of working with images, caching of images is not always a good idea (see the post Images and Caching for more information). In this case, using the method imageWithContentsOfFile: is a better option. However, there is one difference we need to account for when using this method, namely, imageWithContentsOfFile: loads image data from a specified path, however, it will not look in the application bundle by default.

Creating the proper path can be as simple as:

NSString *path = 
  [[NSBundle mainBundle] pathForResource:@"Splash" ofType:@"jpg" inDirectory:@""]; 
UIImageView *background = 
[[UIImageView alloc] initWithImage:[UIImage imageWithContentsOfFile:path]];

In order for imageWithContentsOfFile: to work with images imported from the file system as I demonstrated in Part 1, we need to specify the full path to the resource, here’s how that code might look:

NSString *dir = [NSString stringWithFormat:@"Model-%02d/coverflow", modelIndex];
NSString *file = [NSString stringWithFormat:@"CoverFlow-%02d", imageIndex]; 
NSString *path = [[NSBundle mainBundle] pathForResource:file
   ofType:@"jpg" inDirectory:dir];
UIImageView *wallpaper = [[UIImageView alloc] 
  initWithImage:[UIImage imageWithContentsOfFile:path]];

Working with files directly imported from the file system can be quite useful, even more so when there are many files to manage within an application. However, you will need to keep in mind how to access the resources, either through a full path or by working with an application bundle.

Although this is nice, for the most part the file structure as stored on the system is still flat. In other words, Xcode manages this information internally, it does not create corresponding folders on the file system.

In a recent application I was working with large sets of images. The question was, how to best manage all the images within Xcode such that I could leverage the inherent nature of folders and sub-folders on the file system. Let me explain a little further.

From the figure above you can get an idea of how I chose to break down the content. There was a total of 12 models, for each model there were up to 40 images in the folder /coverflow (see the image on the right), a separate folder for wallpaper images, with an image that corresponds to each coverflow image, as well as a handful of other images such a headshot, MenuButton, etc.

On the file system this is a logical breakdown of content, and if I were to use this same structure within the application I could build a path to the appropriate folder in the resource bundle using an index value to specify which folder I am after (/Model-01, /Model-02, etc). This would allow for code that can access the same files, regardless of which model the user selected, no hard-coding of file names and paths.

There were two tricks to get this to work within Xcode. The first trick is to properly import the file contents into Xcode. Here’s how you do that:

Step #1: In the project, right click (control-click) and choose Add -> Existing Files:

Step #2: Choose the folders on the file system to import:

Step #3: After clicking on Add, you will be prompted with the dialog box below. Chose to copy the files into the project as well as create the folder references in the project:

You’ll know that all is well if the folder references appear as blue folders (shown below).

The second trick was to properly reference resources within the application. This was straightforward for images that I wanted the system to cache, however it required a few extra steps for those images I didn’t want cached. More on this, and the code to make it all work, in Part II.

I’ve been working with some monster projects as it relates to content. What that translates to is really long lists of files inside of Finder. Since I bounce between a handful of projects over the course of the week, more often than not I opt to open a project from by browsing the files within Finder and opening the file with the extension .xcodeproj. With folders having many files, I quickly tired of scrolling down the file list looking for the xcode project file.

To bubble the project file to the top, I simply rename the project file and place an underscore at the front of the project name. For example, SomeProject.xcodeproj becomes _SomeProject.xcodeproj. This has no effect on the project (from Xcode’s perspective), however you may need to update your source code control system with the new (renamed) file.

Trivial as it is, a hand tip none-the-less.

I thought this same information might be helpful for others, so I consolidated all the notes into one document.

There are a few caveats:

• The list is not necessarily the shortest path to create a distribution.
• A few redundant steps are listed, mostly done as a sanity check to ensure nothing was missed.
• This list will be helpful primarily to those who are about to adventure upon their first deployment.

Download: iPhone Distribution Build Cheatsheet

This list was written with Pages on a Mac and printed to a PDF file. If anyone has a suggestion on how to embed the document into this post, please let me know.