On the one hand, that may be an artificial limitation. If this turns out to have some bug that overwrites the encryption keys, they could of course say "we warned you", but it would not be good PR. Also, if beta developers report intermittent smaller data-losing bugs, they might want to study the affected drives to see what went wrong with it. Not having encryption enabled on them will make that a tiny bit easier.

On the other hand, if the new ability to partition drives with flexible partition sizes includes separate encryption keys per partition, and encryption/decryption is done by the block driver, they may have work to do to keep that block driver informed about what blocks should get encrypted with what key.

Err, per [1]

> APFS supports encryption natively. You can choose one of the following encryption models for each volume in a container: no encryption, single-key encryption, or multi-key encryption with per-file keys for file data and a separate key for sensitive metadata. APFS encryption uses AES-XTS or AES-CBC, depending on hardware. Multi-key encryption ensures the integrity of user data even when its physical security is compromised.

[1] https://developer.apple.com/library/prerelease/content/docum...

I wonder why they went this route.

Most apple volumes are already logical volumes (check diskutil list).

FileVault itself is, right now, implemented as part of corestorage (see diskutil cs for the encryption/decryption commands).

I assume they decided they just wanted to go the entire ZFS route and get rid of core storage in favor of a pool model, but still ...

Could be for performance reasons rather than a technical blocker. That said AES-NI instructions do make encryption pretty fast so it's anyone's guess at this stage.

What would be really neat is if this is because FileVault is going to be filesystem-level when they ship APFS.

It's wishful thinking, I know.