This is a weird one… I have a MacBook Pro and iPhone (Mac is on Tahoe; the phone is on the latest public beta of iOS 26). I have two user accounts on this machine; one for work, and the other for personal use; they are both logged into my iCloud account, just so I can use my Apple Music, Calendar, iCloud Drive, etc., etc. in either context. It’s not clean, but it works, more or less.
I was trying to AirDrop some photos to myself from my phone, and while it was saying they had sent successfully, I wasn’t seeing the files appearing in the Downloads folder on my Mac. I was in my work account, and decided on a whim to hop over to the personal account just to see what was up (I use Fast User Switching to go back and forth on a regular basis). Sure enough, there they were in the personal account’s Downloads folder.
Has anyone had this happen? This sure does seem like some kind of security glitch - if this second account didn’t belong to me, that could have been a real problem…
When you’re choosing the AirDrop destination, does it show just one destination (you, via iCloud) or do you see two (one for each account)?
If there’s only one destination, and you’re using Fast User Switching, then are not both accounts logged in at the same time? How would the AirDrop daemon know which account’s Download folder to drop the file into? There would be no difference between the two accounts.
I agree that you may have found a potential security glitch with the way Airdrop works. From the iPhone it only “sees” the Mac computer and displays its name. It does not identify logged-in accounts on that computer so the user can select where to send the file.
I just tried changing the computer name for one of my logged-in accounts (Settings/General/About…) and, as expected, it also changed the name for the other account. The same for Local Host Name under File Sharing. So no way to separate the view in Airdrop.
It does this when going from computer to phone; when airdropping from phone/ipad to computer it usually goes into the Downloads folder on the computer.
It just shows the computer name, it doesn’t give a choice of user accounts. Both accounts are logged in at the same time, though it does require a password to switch between them, so the way it should work (and the way it’s always worked for me in the past) is that it would only give the option to airdrop to the currently active account.
I also have a computer that I use for work and for personal on two different accounts. When I try to airdrop, it only goes to the computer. Sometimes it goes to the account I have open, sometimes it goes to the one “running” in the background via fast user switching. My hunch was that the first one logged into after a reboot was the winner. Just a guess. I ended up texting stuff to myself.
Interesting! I swear I use this functionality with some regularity, and yesterday was the first time I experienced the files being sent to the account that wasn’t in the foreground! Either way, I think it is insecure behavior. I’m going to figure out how to submit it to Apple as a bug.
Thanks for the link to Blip and recommendation @tommy , I see in the footer it is also available for Linux users, and I’m slowly working in that direction so it’s even more helpful!
You might also take a look at LocalSend. It’s a free and open source (FOSS), cross-platform AirDrop alternative. I haven’t used it, but folks seem to like it.
Looks nice. It appears that it uses standard REST/HTTPS/IP networking, making it portable to anything and everything.
The downside of this approach is that the two devices must be on the same network together. For your own personal devices running in your home, this shouldn’t be a problem, because you probably have them all connecting to the same LAN (via Ethernet and/or Wi-Fi) anyway.
But when your devices are not on the same network (e.g., when you’re away from home, or sharing a file with a guest that’s not on your LAN, or a stranger), it won’t work.
AirDrop’s system avoids this mess by using Bluetooth for the control plane, and by creating a temporary ad-hoc Wi-Fi network for the data transfer. This will work even when the devices are on different LANs, and even if they aren’t connected to any network.
I don’t think there’s a technical reason why a portable FOSS package couldn’t do the same thing, but it would probably require some OS-specific glue logic in order to implement the low-level networking bits (TCP/IP socket APIs are pretty much universal these days, but Bluetooth and Wi-Fi APIs are not).
Blip avoids this limitation, last year I was in Paris and VNCed home and Blipped a file to the iPad I had with me. Both have to be online but it will resume if a connection is broken.