Where your files actually live on an iPhone, and who can see them

Each installed app runs in a sandbox: a private folder tree that only it can read and write. There is no shared C: drive, no /home, nothing an app can wander into. This is the foundation of the platform’s security model, and it is genuinely good — a badly behaved app cannot rifle through your other apps’ data, because it cannot see that the data exists.

Inside its sandbox, an app has a few directories with different rules, and those rules explain most of the odd behaviour people notice. Documents is for content the user created or brought in; it is included in backups, and an app may declare it visible in the Files app. Library/Application Support is for the app’s own working data — databases, indexes — backed up but not shown to the user. Library/Caches is for anything that can be recreated: it is not backed up, and the system will empty it without asking when storage runs low.

That last one is the source of a specific and very common surprise: thumbnails, previews and other derived files vanish after the phone gets full. A well-built app treats that as normal and regenerates them. An app that stored something irreplaceable in the cache has lost it.

The Files app is a browser for a set of places you have granted it: iCloud Drive, any cloud provider that installed an extension, connected drives, and the Documents folder of every app that chose to expose it. It is genuinely a file manager, and for moving a PDF around it is entirely sufficient.

What it is not is a media library. It has no notion of what you have watched, no playlists, no favourites, no resume position, no idea that four files are episodes of one thing. It also cannot do anything with the contents of a file: it will not extract the audio from a video, it will not show you what is inside an archive without unpacking the whole thing, and it will not play half of what a media library contains.

So the practical arrangement on iOS is not “Files app or a file manager app”, it is both. Files for moving things between apps and drives; a media app for the library itself, with its folders visible in Files so nothing is trapped.

Most apps remember a file by its path — the text of where it is. It is the obvious approach and it works until the moment anything moves. Rename video.mkv to Interview.mkv and every favourite, playlist entry and resume position pointing at the old name is now pointing at nothing. Some apps hide this by silently dropping the entry; some show a broken row; almost none tell you why.

The alternative is to identify a file by something that survives being renamed. On a file system that means the inode — the identity the file system itself assigns — checked together with size and modification date, with a content fingerprint as a last resort. Rename, move between folders, or reorganise the whole library, and the row in the database is still the same row.

This matters more than it sounds, because it decides whether you can ever tidy up. A library you are afraid to reorganise stays messy forever.