Devices discover each other with Apple's wireless link, the user picks a recipient, and the file copies over peer-to-peer Wi-Fi. Apple's platform security guide describes the control: discovery can be restricted to contacts, the devices exchange identity, and the transfer itself is encrypted. It is a product, not an Internet standard. It earns a page because people use the name for any nearby share, and the mechanism does not leave Apple's ecosystem.
AirDrop is not a cloud transfer and not a swarm. There is no bucket and no third recipient uploading pieces. Both devices have to be awake, close, and allowed to see each other. Contacts-only mode hides the radio from strangers. Everyone mode shows a name to nearby devices. Receiving always asks. A successful drop puts a copy on the other device. The sender's later delete does not reach it. That is a file transfer, local and direct.
A designer AirDrops a 1.8 GB cut to a producer's laptop in the same room. Discovery succeeds, the producer accepts, and the copy runs over the peer Wi-Fi path rather than the office up link. It finishes in a few minutes. The same gesture fails when the producer is on guest Wi-Fi with peer isolation, when either radio is off, or when the receiver is an Android phone. There is no AirDrop endpoint on Android. A cross-platform job needs a browser upload or a link. Calling that AirDrop in the ticket sends people looking for a share sheet that will never list the other device.
Do not treat AirDrop as access control for a business record. There is no file access log in your object store, no expiry, and no residency setting. It is a local copy with a receiver prompt. For anything that has to be audited, use a portal or an SFTP job and keep AirDrop for the room.
Related
Sources
- Apple Platform Security, AirDrop security
Identity check, AWDL discovery, and TLS-protected transfer
- IEEE 802.11 wireless LAN standard overview
The radio AirDrop uses for the byte transfer after discovery