While working on the Exploring iPhone Audio Trail I wanted to look at the audio files that I was recording. My application is getting it’s sandboxed Document directory using the following code:

1
2
3
4

NSArray *paths = NSSearchPathForDirectoriesInDomains(
            NSDocumentDirectory, 
            NSUserDomainMask, YES); 
NSString* docDir = [paths objectAtIndex:0];

• The first statement returns an array of strings that will have a single element containing the path of your application’s Document directory. Each application has it’s own directory.
• The second statement gets the first element of the array returned in the first statement.

For applications running on the iPhone simulator this directory path will look like:

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

• <your username> will be the name of the user account you are logged into.
• <guid> I assume this is a generated GUID (Global Unique ID) because that’s what it looks like. For example I have one that is: 3C17B9C8-76CE-4089-B77E-221968BB3CA5. Because of this you should be able to have multiple applications with the exact same name loaded onto an iPhone.

You’ll have one of these GUID directories for each of the applications you’ve installed on the iPhone simulator. It will contain a file that has the name of your application. This is the application bundle and contains the application executable and resource files. There will also be directories for Documents, Library and tmp. You can look at files that your application is creating in these directories. I was able to record an audio file and then play the file in iTunes.

If you look a level above the Application directory at /Users/<your username>/Library/Application Support/iPhone Simulator/User you’ll see data stored by the built in iPhone applications. For instance, in the Library directory you’ll find Address Book data files, Calendar data files, system preferences, etc.

A problem I’m having right now is that every time I run my iPhone application in the debugger it deletes the old directory and creates a new one with a new GUID. This means if I store files, shut down the application, then run the application again my files will be gone. This makes it hard test persistence in your applications. I don’t believe that beta 1 of the SDK was doing this.

A painful workaround for this problem is to copy the files in your Documents directory to a different location on your hard drive. Then set a breakpoint at the start of your application. When you run your application again and it hits the breakpoint you can then copy the files into the new application Documents directory and continue debugging.