Mobile Device File System: What It Is, Directory Structure, and How It Works

What Is a Mobile Device File System?

File system is a software component of the operating system that manages how data is written, read, and organized on physical media. On mobile devices, the file system performs critically important functions: managing flash memory space, controlling file access based on permissions, journaling changes for crash recovery, and optimizing writes considering the specifics of NAND flash memory.

Unlike desktop operating systems, mobile file systems are designed considering the limited number of flash memory rewrite cycles. NAND cells can withstand a limited number of erase operations — from 3,000 to 10,000 cycles for TLC and MLC memory, respectively. To extend the storage lifespan, file systems employ wear leveling mechanisms and TRIM commands. F2FS, developed by Samsung specifically for flash memory, accounts for NAND array geometry and places data in a way that minimizes fragmentation and the number of block erase operations.

Modern mobile devices use a combination of multiple file systems. Internal memory (the /data partition) is formatted as EXT4 or F2FS on Android and APFS on iOS. SD cards traditionally use exFAT for files larger than 4 GB or FAT32 for maximum compatibility. The /system partition on Android is often mounted read-only and uses EXT4 or EROFS (Enhanced Read-Only File System) — a compressed file system developed by Huawei to reduce the size of the system partition.

Directory Structure on Android

Directory hierarchy on Android is based on the Linux structure with the root at /. Each partition has its own file system, access permissions, and purpose. An application can only access a limited set of directories — the rest are protected by root permissions.

/data Partition and App Sandbox

The /data partition is the main partition for storing user data, installed applications, and their settings. Each application receives its own directory at /data/data/<package_name>/. Inside this directory, the system automatically creates subdirectories: files/ for application files, cache/ for temporary files, databases/ for SQLite databases, shared_prefs/ for SharedPreferences. Access permissions to this directory are set when the application is installed and cannot be changed without root access. The /data partition is formatted as F2FS on most modern devices, providing up to 40% higher random write speed compared to EXT4.

/system Partition and System Components

The /system partition contains the operating system, system applications, and libraries. This partition is mounted read-only to prevent accidental or malicious modification of system files. On devices with Android 10+ and Project Treble, the /system partition is dynamic and can be updated via OTA packages without a full reflash. For applications, the /system partition is inaccessible — attempting to write will throw a SecurityException. However, applications can read some files from /system, such as system fonts and configuration files, if they have the appropriate permissions.

/sdcard Mount Point

The /sdcard mount point is a symbolic link to the emulated or physical external storage partition. On devices without an SD card, /sdcard points to a subpartition within /data designated for shared access. This partition is visible to the user when the device is connected to a computer via MTP protocol. Applications access /sdcard through READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions, and starting with Android 10 — through Scoped Storage using the MediaStore API. The /sdcard size is typically 60–80% of the total flash memory, with the remainder reserved for the /data partition.

Directory Structure on iOS

On iOS, the file system is organized through Sandbox containers for applications. Each application receives an isolated directory whose access is restricted at the XNU kernel level. The user partition uses the APFS (Apple File System), introduced in iOS 10.3. APFS supports snapshots, file cloning, and file-level encryption, making it optimal for mobile devices.

Standard Sandbox Container Directories

An iOS Sandbox container includes four main directories: Documents, Library, tmp, and SystemData. Each directory has its own backup policy, data retention period, and access level. Documents are automatically included in iCloud and iTunes backups. Library contains subdirectories Caches (not backed up), Preferences (backed up), and Application Support (backed up). The tmp directory is for temporary files that iOS may delete when storage is low — it is not included in backups. SystemData is used by the system itself and is inaccessible to applications through standard APIs.

let fm = FileManager.default

let documents = fm.urls(
    for: .documentDirectory,
    in: .userDomainMask
).first!

let caches = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let appSupport = fm.urls(
    for: .applicationSupportDirectory,
    in: .userDomainMask
).first!

Each Sandbox container directory has its own protection class. iOS supports four classes: Complete Protection (file is inaccessible when the device is locked), Protected Unless Open (already open files are accessible when locked), Protected Until First User Authentication (files are accessible after the first unlock), and No Protection (files are always accessible after device boot). By default, all files in Documents and Library receive the Complete Protection class, ensuring maximum protection of user data. When creating a file, you can explicitly specify a different protection class if a background application needs access to data while the device is locked.

File System Access Permissions and Security

Access control to files on mobile devices is a key difference between Android and iOS. Android uses the classic Linux permission model (read, write, execute) with extensions for application isolation. iOS uses a stricter Sandbox model, where each application runs in an isolated container and has no access to other applications’ files without special mechanisms.

Permissions on Android

On Android, each application runs under a separate UID (User ID). All files created by an application in its sandbox belong to this UID and are invisible to other applications. To access shared directories (external storage), an application must request READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions. Starting with Android 11, permissions must be requested at runtime, and an application with targetSdkVersion 30+ must use SAF to access other applications’ files. Violating the permission model results in a SecurityException, which is handled by a standard try-catch block. Google Play automatically checks the application’s compliance with permission policy before publication.

if (ContextCompat.checkSelfPermission(
    context,
    Manifest.permission.READ_EXTERNAL_STORAGE
) != PackageManager.PERMISSION_GRANTED) {
    ActivityCompat.requestPermissions(
        activity,
        arrayOf(Manifest.permission.READ_EXTERNAL_STORAGE),
        REQUEST_CODE
    )
}

iOS Sandbox and Keychain

iOS Sandbox is implemented at the XNU kernel level and does not allow the application to leave its container. Even if the application gets access to an external file URI through Document Picker, the operating system creates a temporary copy in the application’s container rather than providing direct access to the original. For file sharing between applications, iOS uses Share Sheet and UIActivityViewController mechanisms, which copy a file from one application’s container to another’s. For secure storage of credentials (tokens, passwords, keys), iOS provides Keychain — an encrypted storage accessible to the system at the kernel level. Keychain is not part of the Sandbox container and is managed by a separate securityd daemon, providing an additional layer of protection even in the event of application compromise.

File System Features: EXT4, APFS, F2FS

The choice of file system directly affects storage performance and reliability. Each file system has its own architecture, optimizations, and limitations. It is useful for a developer to understand these differences to predict application behavior on different devices.

• EXT4 — a standard Linux file system with journaling, supporting files up to 16 TB and volumes up to 1 EB. Used on Android as the primary file system before F2FS adoption. Provides reliability through journaling, but is inferior to F2FS in random write speed due to the need to update inodes and block bitmaps on each operation
• F2FS — a file system developed by Samsung in 2012 specifically for NAND flash memory. Accounts for flash array geometry, uses a log-structured architecture, and provides 25–40% higher random write performance compared to EXT4. Starting with Android 11, Google recommends F2FS as the primary file system for the /data partition
• APFS — Apple’s file system introduced in 2017. Supports snapshots, file cloning (copy-on-write), file-level encryption, and strict data integrity control through checksums. APFS is optimized for SSDs and uses TRIM commands to maintain performance throughout the storage lifespan
• exFAT — Microsoft’s file system used on SD cards and USB drives. Supports files larger than 4 GB and volumes up to 128 PB. Has no journaling, so sudden power loss can lead to data corruption. Recommended for removable media but not for system partitions

When developing applications, keep in mind that different file systems have different file name length limits (255 bytes for EXT4 and F2FS, 255 Unicode characters for APFS), maximum file size, and special character support. For example, APFS allows Unicode characters in file names, including emoji, while EXT4 is limited to ASCII. If your application creates files with names in different languages, test on all target devices — a file name correctly created on APFS may be truncated on EXT4.

Recommendations for Working with the File System

Reliable work with the mobile device file system requires following several key rules. They are based on an analysis of typical developer mistakes and official documentation recommendations.

• Do not use hardcoded paths to directories. Always obtain paths through system APIs: context.filesDir on Android, NSSearchPathForDirectoriesInDomains on iOS. Hardcoded paths change between OS versions and devices
• Handle exceptions of file operations: IOException, FileNotFoundException, SecurityException. On iOS, all FileManager operations can throw errors — wrap them in do-catch. On Android, operations with external storage may fail due to missing media
• Check available space before writing. Use File.getUsableSpace() on Android and URLResourceValues.volumeAvailableCapacityKey on iOS. Warn the user if free space is insufficient
• Avoid storing large files in directories that are included in backups. On iOS, exclude cache from backup using isExcludedFromBackup. On Android, prefer cacheDir for temporary files
• Test behavior under storage overflow and sudden power loss. Use transactional writing: write to a temporary file, then atomically rename it

Pay special attention to cross-platform differences. File paths on Android use forward slashes (/data/data/.../files/), on iOS — URL scheme (file:///var/mobile/.../Documents/). If your application uses a cross-platform framework (Flutter, React Native, Kotlin Multiplatform), unify file operations through platform adapters. For example, Flutter provides the path_provider package, which returns the correct path to Documents or filesDir on both platforms without writing platform-specific code. Never concatenate paths with string operations — use File.join() or URL.appendingPathComponent(), which correctly handle separators on different platforms.