AirDrop not working from iPhone to Mac: what to rule out first

A file is ready on the iPhone, the Mac is two feet away and awake, and the Mac simply does not appear in the share sheet. Or it appears, the send looks like it went through, and nothing ever arrives. Both of these are almost never a hardware fault. AirDrop is a set of conditions that all have to hold at once, and when one of them does not hold, the failure looks the same from the outside: a device that is not there.

The fastest way through is to stop guessing which condition it is and check them in an order where each step either clears itself or stops the search. That order has changed recently, because Apple added a new requirement in late 2026 that breaks most of the older troubleshooting lists.

What has to be true before the Mac can appear at all

Apple states three prerequisites for any AirDrop transfer, and all three are about the pair of devices rather than about either one alone.

Wi-Fi and Bluetooth have to be on, on both devices. The two do different jobs: Bluetooth handles discovery, and the actual file moves over a direct Wi-Fi link between the devices. This is why turning Wi-Fi off "because the transfer is local" guarantees failure, and why joining the same network is not required. The devices talk to each other, not through a router. A busy office network and a failing AirDrop are unrelated problems.

The devices have to be within 30 feet, or 10 meters, of each other. That figure is a line-of-sight guide. A closed door, a metal shelf, or a desk partition can shorten it considerably, so a colleague at the next desk is not automatically inside the range in practice.

The receiving device has to be set to accept from Contacts Only or from Everyone. On a Mac, that setting lives in Control Center: click the Control Center icon in the menu bar, then click AirDrop. Blue means on. Click and hold, or click the arrow beside AirDrop, to choose between Contacts Only and Everyone.

One more condition changes the behaviour rather than enabling it. When both devices are signed in to the same Apple Account, items are accepted and saved automatically with no prompt at all. That is why sending from a personal iPhone to a personal Mac can work perfectly while a transfer from a colleague fails: the two cases do not follow the same path.

The rule that changed in macOS 26.2

This is the single most common reason an otherwise correct setup stopped working, and most of the guides currently ranking for this query predate it.

With iOS 26.2, iPadOS 26.2, macOS 26.2 and later, someone who is not in the recipient's contacts has to use an AirDrop code. Setting the Mac to Everyone is no longer enough on its own.

The flow runs like this. The recipient chooses Continue, and a code appears on the receiving device. The recipient reads that code out to the sender, the sender types it on their own device, and the item is shared. After that first exchange, the same two people can send and receive for 30 days without another code.

Two practical consequences follow. First, in a meeting with someone new, expect the extra step and say so out loud, because the common failure is both people waiting: the sender staring at a prompt asking for a code, the recipient never noticing that the code is already on their own screen. Second, that 30 day window can be closed early. Open the Contacts app, find the sender in the Other Known list, and choose Forget This Person.

If a transfer between the same two devices worked last month and does not work now, and neither person changed a setting, this rule is the first thing to suspect.

Contacts Only puts the requirement on the other person's address book

Contacts Only is the setting most people leave in place, and it is the one whose conditions cannot be satisfied from the receiving side alone.

For a sender to see a recipient who is set to Contacts Only, the sender has to have that recipient in their contacts, and the recipient's contact card on the sender's device has to contain the email address or phone number associated with the recipient's Apple Account.

That last clause is where it breaks in a work setting. A work email address is the one that gets handed out, while the Apple Account behind the personal iPhone uses a different address entirely. The name is in the address book, the card looks complete, and AirDrop still treats the two people as strangers, because the identifier it matches on is not there.

There are only two ways out, and it is worth knowing which one is being chosen. Either the sender adds the recipient's Apple Account address to the existing contact card, which fixes the problem permanently for that pair, or the recipient switches to Everyone for the duration of the handoff, which fixes it once.

On iPhone and iPad, Everyone reverts by itself after 10 minutes. On a Mac there is no equivalent timer shown, so switching back to Contacts Only afterwards has to be remembered. Leaving a Mac on Everyone in a shared office is how unexpected prompts start arriving.

Where the accept prompt actually appears

A share that looks successful from the iPhone, with no prompt on the Mac, is sometimes not a missing prompt. It is a prompt somewhere other than where it is being looked for.

If you open AirDrop in the Finder on your Mac, the notification to accept or decline appears in the Finder instead of in Notification Center. Source: support.apple.com

So a Mac that is sitting on the Finder AirDrop view, which is the obvious thing to do while waiting for a file, is the one case where watching the top right corner of the screen shows nothing. The decision appears inside the Finder window. With the Finder closed or on another folder, the prompt goes to Notification Center as expected.

There is a second version of the same trap. A Mac with the lid closed, or asleep, is not discoverable at all, and a Mac that woke only because a key was pressed a second ago may not have brought the interface back up yet. Waiting two or three seconds after waking the machine before asking the sender to try again removes a whole class of retries.

A Focus mode makes this worse rather than differently. Notifications still arrive, they just queue silently. When a file is expected, either turn the Focus off for a minute or commit to waiting on the Finder AirDrop view, and watch the right place.

Where a received file lands

A useful number of these cases are not failures at all. The file arrived and went somewhere that was not checked.

Most items open in the same kind of app they were sent from. A photo shared from the Photos app on an iPhone lands in Photos on the Mac. Documents, archives and anything without an obvious owner are saved to the Downloads folder instead. For photos specifically, macOS sometimes offers a choice between saving to Downloads and opening in Photos, which means the destination depends on an answer given seconds earlier and probably forgotten.

Sorting by time is faster than sorting by name here. In the Finder, open Downloads and sort by Date Added. From a shell, the same answer takes one line.

ls -lt ~/Downloads | head -20

Multiple devices on one Apple Account add a second place to look. Automatic acceptance applies across all of them, so a file sent without picking a specific target can be sitting on a Mac that is closed in another room. Checking the intended Mac and concluding the transfer failed is a normal mistake to make.

Reading the radio side instead of guessing

When the settings are confirmed and the transfer still does not start, the next thing to check is whether the interface AirDrop uses is actually running. On macOS it is called awdl0, and its state is readable without any extra tooling.

ifconfig awdl0

The flags in angle brackets on the first line are the answer. UP and RUNNING mean the interface is live. An interface that stays inactive is a real signal, and the response to it is to toggle Wi-Fi off and on, or restart the device. Apple's own guidance for a device that never appears is a restart of both ends followed by another attempt, which is worth doing once rather than three times.

Personal Hotspot and Internet Sharing are worth switching off during a test. When the Wi-Fi radio is committed to serving other clients, the direct device to device link has less to work with.

Two other things change the picture without being obvious. An always-on VPN, common on managed hardware, and a firewall configured to block all incoming connections can both let discovery succeed and then stall the transfer partway. Neither can be confirmed by reading a setting, so turn one off, resend the same file, and see whether the result changes. If nothing changes, the VPN was not the cause and it can be ruled out for good.

One property of AirDrop makes the stall diagnosis clearer. Apple notes that once a transfer has begun, leaving Bluetooth or Wi-Fi range does not kill it: the transfer continues over the internet. So the strict distance requirement applies to discovery, not to progress. A progress bar that has stopped moving will not be helped by bringing the devices closer, and continuing to shuffle them around wastes the minutes that should go into the checks above.

Distance deserves one honest test rather than repeated adjustment. Put both devices on the same desk, a hand's width apart, and send once. That single test separates a range problem from everything else in under a minute.

The order to work through

Guessing is slower than a fixed sequence, because each of these either clears or stops the search.

Step	What to confirm	If it fails
1	Wi-Fi and Bluetooth on, both devices	Turn both on in Control Center
2	Devices within 30 feet, ideally on one desk	Move them together and retest once
3	Receiving Mac set to Contacts Only or Everyone	Set it in Control Center, AirDrop
4	Sender's contact card holds the Apple Account address	Add it, or switch to Everyone for the handoff
5	Non-contacts need an AirDrop code on 26.2 and later	Read the code on screen to the sender
6	Not waiting on the Finder AirDrop view	Look inside the Finder window for the prompt
7	awdl0 shows UP and RUNNING	Toggle Wi-Fi, then restart both devices
8	Hotspot, VPN and firewall off for one test	Resend and compare the result

Anything that survives all eight is a device state problem rather than an AirDrop setting problem. At that point, move the file another way and investigate later, because the work should not wait on the diagnosis.

What to change first

Check the receiving setting and the sender's contact card before touching Wi-Fi, because those two are the conditions AirDrop actually evaluates and neither has anything to do with signal strength. Then confirm whether a code is being requested, since on current macOS that is the step most older guides never mention. If handoffs between the same devices happen daily, the better fix is a fixed location both ends can reach rather than a repeated negotiation, and keeping the folder, the shell and the file in one window is what Atriens is built around.

For reaching a Mac at home from an iPhone without a transfer at all, see From iPhone and iPad. Common questions about how the two sides fit together are collected in the FAQ.