How can I prevent iOS from auto-deleting HLS content saved for offline playback?

Question

HLS offline playback was announced at this session in WWDC 2016, in iOS 10. But at about the 21:20 mark, the presenter is talking about how the downloaded files shouldn't be moved from where the AVAssetDownloadTask puts them, because the system might need to delete them if disk space is low. This possibility is also mentioned here in the documentation:

Important

If available disk space is extremely low, the operating system may automatically delete downloaded assets. Before you present to the user that an asset is available for playback, verify that the asset exists and is playable offline.

I'm building an app to play DRM'd audio content with HLS, and I want to support both streaming and downloading, so the user can save the files they want for offline playback. But if the downloaded files get deleted without the user's permission, it's kind of a crap experience.

So my question: how can I prevent the system from deleting downloaded files? Can I just move them, even though the documentation explicitly says not to? Is there a different way I can download the files? There is a new class in iOS 11, AVAssetDownloadStorageManager, that supports setting a storage management policy to default or important...is there any guarantee that the system won't delete "important" downloaded media without at least asking the user first? Roger Pantos says in Advances in HTTP Live Streaming at WWDC 2017 that the system might delete assets to make space for a software update after asking the user, but that statement doesn't mean assets won't get delete automatically for other reasons.

Answer 1

We have been moving downloaded assets from provided location to FileManager.default.urls(for: .documentDirectory, in: .userDomainMask) for couple years and haven't seen any problems so far.

I'm not sure that it's good practice and most likely isn't.

UPD. We rewrote our downloads module from scratch and decide to give a try system to handle assets. After internal QA testing, we found that system could delete downloaded content even without notifying a user. In the end we were forced to start moving downloaded content to app documents folder once again.