I'm creating small encrypted disk images (under 10 GB) to be used to secure and transfer data between systems running High Sierra (for now) and Mojave. Are there any technical reasons to prefer HFS+ (Mac OS Extended, Journaled) over APFS for these images. The images will be created as .sparsebundle files if it matters.

Edited to add: .sparsebundle files will be stored on an APFS file system in all cases.


Whether you choose APFS or HFS+ for the sparse disk image will matter very little. They are synthetic filesystems and pass through iOPS and data to the underlying filesystem. That will have some technical details to consider and illuminate the differences how each relies on the storage to store filesystem data and work with or against the hardware that records the bits physically.

HFS+ has more third party data recovery options and is further backward compatible so those are two main technical reasons to potentially prefer HFS+ over APFS. If you’re storing the data on a spinning disk, that might be a technical advantage or might not. You’ll have to test that on your kit as benchmarks vary widely there.

You give up the metadata protection checksums, crash protection of copy on write and encryption advances of APFS as well as the redesign of the filesystem to take advantage of flash/ssd. You also lose snapshots, clone copy and don’t receive the more flexible space allocation features of APFS.

Speed chould be a wash on flash / ssd for your use case, but I would still benchmark your sparse images on both file systems. HFS+ might be far better tuned for a HDD still ( or possible for evermore) as APFS sacrifices HDD performance for flash and ssd performance today as implemented.

  • I do not understand this answer. Q asks for small encrypted images. Transferred between .13 + .14. I read this A as primarily about FSs on real disks? – LangLangC Mar 20 at 23:03
  • These general considerations shouldn’t matter for sparse images. We don’t need to know if the Macs are SSD or HDD and it likely won’t matter if the transfer is either. I read this as what filesystem should OP choose for the device doing the transfer. Can I make things better @LangLangC or just wait for OP to confirm I have it correct or wrong? – bmike Mar 20 at 23:21
  • IDK. For images I would think compatibility is more of a (theoretical?) concern, especially if encrypted, then perhaps performance of images, how do they benchmark in RAM, how APFSonHFS vs HFSonAPFS etc. – LangLangC Mar 20 at 23:52
  • If the format for the image doesn't matter, but the real FS does, than that might be worthy of addition? – LangLangC Mar 20 at 23:54
  • @bmike I'm more interested in which filesystem is better for use in an image than for a physical device. The information about choosing for a device is also important and appreciated. – user11421 Mar 21 at 1:00

In addition to @bmike's very good answer, some legacy programs expect the directory listing to be pre-sorted as it is in HFS+; this is an uncommon issue but some things (especially ones which implement their own custom file selector for whatever reason) run into it all the same.

  • Nice details. Wouldn’t the sparse bundle cover the sorting, though. The OP gets to choose a FS on the transfer device and a FS for the sparse image. Perhaps this it the point @langLangC is making. I didn’t go into that in my answer. – bmike Mar 20 at 23:22
  • @bmike I was referring to the directory listing on the virtual filesystem itself (i.e. what the thing mounting the sparsebundle sees); the OS itself probably doesn't care about the directory sort order of the sparsebundle's spans. :) – fluffy Mar 20 at 23:33
  • Yes - my +1 on your answer remains. You caught the real question where I missed it initially (or backed into it at the end of my answer.) – bmike Mar 21 at 1:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .