iPhone: Accessing the Simulator's File System

Anyone working with the iPhone SDK has probably used the iPhone Simulator. While generally it is pretty speedy when pushing new applications to it, or making minor changes to code, and re-pushing your application for testing, there are some times that you may wish to update something non-code related. Like a simple text file, that your application might read occasionally.

Something like this might not even require an app restart. Such as modifying a database table that is re-read every time a certain screen is accessed.

For tasks like this, it may be easier to just modify the file in question on the simulator’s “File system” for real-time changes.  Luckily, such things are possible.

When you run the simulator, it creates a directory under your home directory located at:

~/Library/Application Support/iPhone Simulator/

When you install an application onto the simulator, it creates a sandbox for the application in a path that looks something like this:

~/Library/Application Support/iPhone Simulator/user/Applications/<GUID>

Where <GUID> is a directory with the name being a GUID assigned to the application during the installation process.  The GUID isn’t particularly necessary to find for you application, and the path to your application’s sandbox can be found with a quick display of command-line foo. From the ~/Library/Application Support/iPhone Simulator/User/Applications/ directory, run:

neuron:Applications glitch$ find ./ -name “SQLiteBooks.app”
.//9A08D2DD-58CE-4878-9D75-BE4F0B5E511D/SQLiteBooks.app

And, voila. The returned path is the path is the path to the application’s bundle, and while you can access the “private” data for your app inside that directory generally you’ll want to go to the Documents directory inside the GUID directory.  So, if we go to:

neuron:Applications glitch$ cd 9A08D2DD-58CE-4878-9D75-BE4F0B5E511D/Documents/

neuron:Documents glitch$ ls

bookdb.sql

neuron:Documents glitch$ 

A well behaved app will copy any data that it will be modifying into the Documents directory so that it can be modified without invalidating the application’s digital signature by writing to a file in the bundle’s directory. So, from here we can freely modify any data that your app will modify and test the changes either while the app is running, or with a quick restart from the iPhone Simulator.

Another use for accessing the files directly, is to test user supplied data for tracking down bugs. Or, in the case of the SQLiteBooks demo, copying a new database that contains many many books, to test performance. Having access to the files directly, lets you swap out new files easily, without having to play around with your XCode project.

 

 

 

http://richard.giliam.net/?p=13#respond