Important: This document may not represent best practices for current development. For current information, see About Apple File System .

Existing third-party utilities may need to be updated to support Apple File System. Consult the utility's documentation, or contact the vendor for compatibility information.

Can I use my third-party disk utilities with an APFS-formatted hard disk?

You cannot share APFS-formatted volumes using AFP. The AFP protocol is deprecated.

Yes, you can share APFS-formatted volumes using the SMB or NFS network file-sharing protocol.

Yes. Apple File System is optimized for Flash/SSD storage, but can also be used with traditional hard disk drives (HDD) and external, direct-attached storage.

You can use Disk Utility to erase an APFS-formatted volume and reformat as HFS+. However, your data will not be preserved when you reformat the volume as HFS+.

If I convert a volume to APFS, can I later revert to HFS+?

The macOS High Sierra installer offers nondestructive in-place upgrades from HFS+ to APFS for bootable volumes. You can use Disk Utility to convert external volumes from HFS+ to APFS format.

Implementation

Why did Apple develop APFS?

Apple File System is uniquely designed to meet the needs of Apple’s products and ecosystem. Apple File System provides strong encryption, ultra-low latencies and limited memory overhead. It is optimized for Flash/SSD storage and can be used on everything from an Apple Watch to a Mac Pro.

HFS+ and its predecessor HFS are more than 30 years old. These file systems were developed in an era of floppy disks and spinning hard drives, when file sizes were calculated in kilobytes or megabytes.

Today, people commonly store hundreds of gigabytes and access millions of files on high-speed, low-latency flash drives. People carry their data with them, and they demand that sensitive information be secure.

How does Apple File System handle filenames?

APFS accepts only valid UTF-8 encoded filenames for creation, and preserves both case and normalization of the filename on disk in all variants. APFS, like HFS+, is case-sensitive on iOS and is available in case-sensitive and case-insensitive variants on macOS, with case-insensitive being the default.

In macOS High Sierra, APFS is normalization-insensitive in both the case-insensitive and case-sensitive variants, using a hash-based native normalization scheme. In iOS 11, APFS is normalization-insensitive as well, using either a native normalization scheme (erase restores only) or runtime normalization scheme (upgrades from previous versions). Runtime normalization will also be available in iOS 10.3.3 and macOS Sierra 10.12.6. Being normalization-insensitive ensures that normalization variants of a filename cannot be created in the same directory, and that a filename can be found with any of its normalization variants. This means that you don’t need to do any additional work to ensure correct normalization behavior in these versions of macOS and iOS.

Some differences between how APFS and HFS+ handle filenames include the following:

APFS implements normalization and case insensitivity according to the Unicode 9.0 standard; this enables APFS to support a wider range of languages for these features than HFS+, which is based on Unicode 3.2.

APFS preserves the normalization of the filename and uses hashes of the normalized form of the filename to provide normalization insensitivity, whereas HFS+ stores the normalized form of the filename on disk to provide normalization insensitivity.

Calling readdir(2) on a directory in APFS returns filenames in hash order, whereas HFS+ returns filenames in lexicographical order.

While both filesystems expect filenames to be encoded in UTF-8, APFS stores filenames on disk in UTF-8 encoding, whereas HFS stores filenames on disk in UTF-16 encoding.

APFS doesn’t allow files to be created with filenames that contain unassigned codepoints in the Unicode 9.0 standard, whereas HFS+ does.

In iOS 10.3 and in the case-sensitive variant of the developer preview of APFS in macOS Sierra, APFS is normalization-sensitive. For these versions, developers should be aware of behavior differences between normalization sensitivity and insensitivity that may arise when a device upgrades macOS or iOS and migrates the filesystem from HFS+ to APFS. For example, attempting to create a file using one normalization behavior and then opening that file using another normalization behavior may result in ENOENT , or “File Not Found” errors. Additionally, storing filenames externally, such as in the defaults database, Core Data, or iCloud storage may cause problems if the normalization scheme of the filename being stored is different from what exists on disk.

To avoid introducing bugs in your code with mismatched Unicode normalization (for iOS 10.3.0, 10.3.1 and 10.3.2) in filenames, do the following:

Use high-level Foundation APIs such as NSFileManager and NSURL when interacting with the filesystem.

Use the fileSystemRepresentation property of NSURL objects when creating and opening files with lower-level filesystem APIs such as POSIX open(2) , or when storing filenames externally from the filesystem.

Can RAID be used with Apple File System?

Yes. Apple File System does not directly implement software RAID; however APFS-formatted volumes can be combined with an Apple RAID volume to support Striping (RAID 0), Mirroring (RAID 1), and Concatenation (JBOD). APFS-formatted volumes can also be used with direct-attached hardware RAID solutions.

Does Apple File System support directory hard links?

Directory hard links are not supported by Apple File System. All directory hard links are converted to symbolic links or aliases when you convert from HFS+ to APFS volume formats on macOS.

Does Apple File System support redundant metadata?

With modern Flash/SSD storage, writing two blocks of data to different locations does not guarantee that the blocks will be written to separate locations. The Flash translation layer typically groups writes together into the same NAND block. Therefore it affords no extra protection to write a second copy at the same time the first copy is written.

What has Apple done to ensure the reliability of my data?

Apple products are designed to prevent data corruption and protect against data loss.

To protect data from hardware errors, all Flash/SSD and hard disk drives used in Apple products use Error Correcting Code (ECC). ECC checks for transmission errors, and when necessary, corrects on the fly. Apple File System uses a unique copy-on-write scheme to protect against data loss that can occur during a crash or loss of power. And to further ensure data integrity, Apple File System uses the Fletcher's checksum algorithm for metadata operations.

Does Apple File System use journaling?

Apple File System uses copy-on-write to avoid in-place changes to file data, which ensures that file system updates are crash protected without the write-twice overhead of journaling.

Does Apple File System support data deduplication?

No. With Apple File System individual extents can be encrypted, making it impossible to examine and deduplicate files and their content. Apple File System uses clone files to minimize data storage and data duplication.

Does Apple File System support TRIM operations?

Yes. TRIM operations are issued asynchronously from when files are deleted or free space is reclaimed, which ensures that these operations are performed only after metadata changes are persisted to stable storage.

Is APFS open source?

An open source implementation is not available at this time. Apple plans to document and publish the APFS volume format specification.