> This is incorrect. Secure deletion should cover the entire disk no matter how much data was used before, in order to deny an attacker any information or to guide their recovery efforts. I would absolutely expect a secure deletion process to take the exact same amount of time regardless of how much data is used.

That's a fair point. Still, mobile devices typically employ FDE to avoid the need for scribbling over the entire flash (also improves the lifetime of the flash in that way).

> It’s worth pointing out that a true secure delete is actually a write not a delete

Flash storage doesn't work that way unless you're referring to something else. To write a block you have to erase it first (makes the block all 1s or all 0s depending on the chip). An update of a block is technically then a read/erase/modify/write (although flash translation layers will elide the first 3 steps by writing to a free block & marking the old one as GC'able). Writing random patterns into flash to my knowledge generally isn't needed anyway as it was with magnetic storage. The only purpose of writing in a secure erase scenario is to try to overwhelm the flash translation layer to force every block to be touched.

> although last time I did a reset it took much longer than that.

I haven't profiled it, but any slowness erasing an iOS device is probably because the flash storage backing the secure element is optimized for reads rather than writes. Additionally, it may be erasing various metadata/caches in the OS storage that aren't covered by the encryption key.