What does the /private prefix on an iOS file path indicate?

I tried this from the debugger and discovered that URLByResolvingSymlinksInPath "fixes" the /private/ addition.

(lldb) p (NSURL *)[NSURL fileURLWithPath:@"/private/var" isDirectory:YES](NSURL *) $1 = 0x1fd9fc20 @"file://localhost/private/var/"(lldb) po [$1 URLByResolvingSymlinksInPath]$2 = 0x1fda0190 file://localhost/var/(lldb) p (NSURL *)[NSURL fileURLWithPath:@"/var" isDirectory:YES](NSURL *) $7 = 0x1fd9fee0 @"file://localhost/var/"(lldb) po [$7 URLByResolvingSymlinksInPath]$8 = 0x1fda2f50 file://localhost/var/

as you can see, file://localhost/var is what we really want here.

Because of this, it seemed obvious that /private/var is a symlink to /var.However, @Kevin-Ballard points out that is not true. I confirmed that he is correct, and /var is the symlink to /private/var (sigh)

(lldb) p (NSDictionary *)[[NSFileManager defaultManager] attributesOfItemAtPath:@"/var" error:nil](NSDictionary *) $3 = 0x1fda11b0 13 key/value pairs(lldb) po $3$3 = 0x1fda11b0 {    ...    NSFileType = NSFileTypeSymbolicLink;}(lldb) p (NSDictionary *)[[NSFileManager defaultManager]   attributesOfItemAtPath:@"/private/var" error:nil](NSDictionary *) $5 = 0x1fda4820 14 key/value pairs(lldb) po $5$5 = 0x1fda4820 {    ...    NSFileType = NSFileTypeDirectory;}

So URLByResolvingSymlinksInPath is doing something funny here, but now we know. For this particular problem, URLByResolvingSymlinksInPath still sounds like a good solution that works for both the simulator and the device and should continue to work in the future if something changes.

In Swift 3, URL has the standardizedFileUrl property, which will remove any symlinks and resolve relative parts within the path like ./.

As of writing the documentation is pretty useless but it looks like it is equivialent to NSURL's standardized property.

To actually answer your question:

I believe /private was a prefix added when they released OS X (I don't think it was there in NeXTStep, but it's been decades). It seems to exist to house etc, var, and tmp (and, oddly, tftpboot; I didn't know my PBG4 could do that), perhaps so users don't wonder what this silly folder called etc is and try to delete it.

On device, Apple decided to store user data in /private/var/mobile (the username is "mobile"). I'm not sure why they didn't pick /Users/mobile or just /mobile, but it has no more significance than /var/mobile would on a "normal" Unix.

On the simulator, your user account can't write to /var (for good reason). User data is stored somewhere in ~/Library/Application Support/iPhone Simulator. At one point, they started using different directories for different simulator versions.