APFS Filesystem Features

All modern filesystems, for example, ReFS and btrfs, checksum at least metadata. APFS also supports checksumming all the metadata blocks. In APFS, checksums are calculated based on the Fletcher algorithm.
64-bit pointers. One of the reasons why APFS was developed is that the previous one, HFS+, used 32-bit pointers and could address only 2^32 blocks which obviously was not enough considering the modern device sizes and the total amount of data stored. APFS can address 2^56 blocks and assuming a 64KB block size will give us about 4EiB.
Copy-on-write. If the filesystem driver needs to update a metadata block, it allocates a new block rather than editing the existing. Once the new block is successfully created, the old block is discarded from the bitmap. Such behavior results in many copies of metadata stored across the APFS-formatted volume and only the filesystem driver knows which ones are the most recent.
Time in nanoseconds. APFS uses a more accurate time up to nanoseconds in the range from 1970-01-01 to 2554-07-21. Previously used HFS+ worked with time intervals accurate to a second. Again, this time accuracy was possible due to the 64-bit fields reserved for storing time in APFS metadata structures.
Snapshots. A fairly common feature in modern filesystems. For example, Linux btrfs and Windows ReFS both support snapshots. The essence of a snapshot in APFS is that snapshots are created at the volume level rather than the entire container being, in fact, some kind of a "canned" state of the volume blocks. Blocks storing file data cannot be removed until they belong to at least one of the snapshots.
Encryption. When creating an APFS container, you can choose an encryption option. Unlike HFS+ and FileVault, encryption on APFS works only for the blocks actually storing data rather than for the entire storage device. Such an approach helps reduce the wear of SSD disks.
Data cloning. APFS can detect identical piece of data within a volume and duplicate only metadata rather than file content.
Space sharing. All disk space of a device is divided into bocks, which form a single pool of free blocks for an APFS container. For the volumes on the container, the blocks are allocated from the shared pool, as well as released blocks are returned to the pool. On the one hand, such allocation makes it possible to create volumes of a non-fixed size, on the other hand, after deleting data, a block previously belonging to a particular volume may be then allocated for another volume.
Sparse files. It is believed that APFS supports sparse files, although we were not able to get it working.