iOS 4.0 supports a very rapid secure erase called "Data Protection". If you upgrade from 3.0 you need to do a restore to set the stage for hardware encryption of all the data.
If your device isn't capable of hardware encryption (often called secure data at rest), then you can use the Erase all content and settings function. This built-in functionality to secure wipe your iDevice has been around since iPhone OS 2.0
As this doesn't work the same way on all iOS devices, do read Understanding 'Erase All Content and Settings' before you depend on this to clear data securely.
Once you are through erasing the device, you might want to connect it to a clean iTunes library and restore the device and set it up as new. Making a new account on your Mac or PC is an easy way to have a library with no account, no songs, and no apps just to be sure the device has a clean (and easily verifiable) start to it's new life.
It depends on your paranoia level. Because of the way SSDs handle writing data, doing a zero-once on an SSD is not as good as doing so on a hard drive.
When you write a particular data page on an HD, the new data is simply written over the old data, replacing it. Write zeros over the whole disk and all the old data will be gone. SSDs, on the other hand, cannot simply overwrite individual pages. In order to replace the data on a page, the old data must first be erased, and SSDs cannot erase individual pages; they have to erase entire blocks consisting of many pages.
So what happens when you ask an SSD to overwrite, say, page #5, is that the SSD leaves the data on page #5 alone, but marks it as invalid, allocates another currently-blank page (say, #2305), writes the new data to page #2305, and makes a note that next time the OS asks for page #5 it should get #2305 instead. The original page #5 data sits there until some later time, when the drive needs more space, moves any remaining valid pages away from the block, and erases it. SSDs have more physical memory capacity than they expose to the computer, so they can juggle blocks like this for a while before actually having to erase anything (and when they do actually erase something, there's no good way to predict which blocks of leftover data will be chosen for erasure). See this AnandTech review for way more details (warning: it's fairly long, and the relevant stuff is spread around).
Net result: if you write zeros over the "whole" drive, you haven't actually overwritten all the old data. You have updated the controller's translation table so it'll never return any of the old data to the OS (those pages are all invalid). But if someone's hardcore enough to bypass the controller, they could get some of your data back.
Overwriting twice will probably work, but it depends on the controller's allocation strategy. Overwriting twice with random data (diskutil randomDisk 2 /dev/diskN) is a little more likely to work, but still not guaranteed. Both of these also have some bad side-effects: they uses some of the lifetime of the drive, and also increase the logical fragmentation on the SSD, decreasing its write performance.
Note that recent versions of OS X's graphical Disk Utility disable the secure erasure options on SSDs (for the reasons discussed above), but the command-line version still allows them. BTW, I have also seen several recommendations to securely erase SSDs by converting them to encrypted format, but this is (if anything) slightly less secure than overwriting with random data.
The best way to secure-erase an SSD is to invoke the controller's built-in secure-erase feature. This should (if the controller designers did their jobs) truly erase all blocks, and also have the side-effect of resetting the logical page map, essentially defragmenting it and restoring its original performance. Unfortunately, most of the utilities I've seen for doing this (e.g. CMRR's HDDErase) run under DOS, which won't boot on a Mac. I did find a posting on macrumors with (rather complex) instructions for doing a secure erase from a GParted boot CD. It might also be possible to use Parted Magic from a bootable flash drive, but I have not tried this.
Researchers at the Non-Volatile Systems Lab at UCSD have tested various ways of sanitizing SSDs by "erasing" the drive, then disassembling it to bypass the controller, and checking for remnant data (summary, full paper). Their results mostly agree with what I said above (and also show that the built-in secure-erase command isn't always implemented properly):
Our results lead to three conclusions:
First, built-in commands are effective, but manufacturers
sometimes implement them incorrectly. Second,
overwriting the entire visible address space of an SSD
twice is usually, but not always, sufficient to sanitize the
drive. Third, none of the existing hard drive-oriented
techniques for individual file sanitization are effective on
SSDs.
Best Answer
I've done a remote wipe on a MacBook Pro with an SSD running Mountain Lion because I wasn't sure how else to securely wipe the SSD. So I can answer some of your questions.
To start with, Mat Honan was wrong when he said that the purpose of the PIN was so that "the process can be reversed." It is to prevent the thief from using the computer. I believe the thinking is that if the computer has to be taken to Apple to be unlocked, then it is much more likely that a stolen computer would be recovered.
Yes, when you remotely wipe the computer it does a secure wipe. Apple even warns you that it could take as long as a day. However, if your drive was encrypted with FileVault 2, then it is not necessary to erase the disk. It is sufficient to securely erase the encryption key(s) stored on the disk, so that's what they do. It's very quick and as secure as the underlying encryption system is, which for now is very secure. You cannot recover the drive with the recovery key once the encryption key(s) have been erased.
Before starting to wipe the disk, though, Apple installs some kind of lock on the system that prevents you from booting it up from the internal or an external drive. I don't know the details of how this works, I only know that I did not find an obvious way around it.
EDIT
I did this a second time and this time I wrote down the steps.
Now back to our original story...
Below is from memory, so might be slightly wrong in some details. You can read another person's account of the process from MacObserver. (They were able to recover files from their unencrypted mechanical drive, but I believe it was because they entered the passcode and interrupted the wipe before it finished.) I think that after the remote wipe started and the lock screen came up on the MacBook Pro I did not wait very long for it to finish wiping the drive and entered the PIN to see what I could see on the drive. (I never saw anything on the drive, but I also did not take it out of the computer and send it to DriveSavers for them to check out.) I don't recall exactly how I got to powering down the machine post-wipe.
Anyway, after the wipe and power-down, I attached an external Mountain Lion Install drive and powered up the computer. I got a flashing folder with a question mark (meaning it cannot find a boot drive).
I rebooted, holding down the option key to get a choice of boot disks. I had a choice between Macintosh HD (the internal drive) and the external drive. I picked the external drive and again got the flashing folder with a question mark.
I rebooted again, holding down the option key again, but this time chose "Macintosh HD". Then I was presented with a screen to enter the unlock PIN. Which I did. I was then back to the screen where I could choose a boot drive, but this time the internal drive was labeled "10.8 Recovery HD" or something like that. I again chose the external drive and it booted fine. I was then able to reinstall the OS and all was normal from there.
I didn't see about trying to put the computer into target disk mode but Apple is pretty savvy about encryption and security so I expect that the PIN code lock is in the firmware and the computer just won't do anything until it's unlocked. I also suspect that Apple can unlock the computer with some secret procedure, but that would only restore the computer to normal operation: whatever was on the disk would still be gone to the extent the computer was able to erase it before you got it to Apple. (The MacObserver article states that they were not able to put the computer into target disk mode until they unlocked it when it was just remote locked. Mat Honan stated in a follow-up to his original article about getting hacked that the Apple Genius he eventually got to help him "had been able to reset the firmware password" even though he "couldn’t crack the PIN".) What makes the encrypted drives so secure is that all you need to erase is probably just one file system block containing the encryption key(s), so it's done in under a second.