NearDrop: Google Quick Share on macOS, With Real Limits

The gap NearDrop fills between Android and macOS

Google's Nearby Share, now branded Quick Share, moves files between Android devices, Chromebooks and Windows machines. macOS is not on that list. NearDrop is a partial implementation of the same protocol for macOS, written in Swift, and it exists to close exactly that gap: an Android phone sends a file, a Mac receives it. The app lives in the menu bar and saves incoming files to the downloads folder. That is the whole product surface. It is not a sync client, not a file manager, and not a cross-platform bridge in the other direction. The README describes it as a partial implementation, and the word matters: protocol coverage is narrower than Google's own client, and the limitations section is longer than the feature list. The audience is narrow too. If you carry an Android phone and a Mac and move photos, documents or links between them, you are the target user. If you want AirDrop behaviour on Android, the README answers that question directly and says it is nigh-impossible, because AirDrop runs on AWDL, Apple's proprietary peer-to-peer Wi-Fi layer, and reimplementing it would require raw packet access and possibly a custom kernel.

How NearDrop receives a transfer over the local network

The repository separates the app from the protocol. NearDrop/ holds the macOS app and the menu bar UI, NearbyShare/ holds the protocol implementation, ShareExtension/ provides the Finder share sheet entry, and PROTOCOL.md documents the wire format separately. That layout tells you the project treats the reverse-engineered protocol as a first-class artifact rather than burying it in app code. The transfer path is local: the Android device and the Mac must be on the same Wi-Fi network, and discovery and the file exchange happen over that LAN. Nothing routes through Google servers. That is a privacy advantage and a capability limit at the same time. Google's implementation supports multiple mediums, including Wi-Fi Direct, Wi-Fi hotspot, Bluetooth, a 5G peer-to-peer connection, and a WebRTC-based path that goes over the internet through Google servers. NearDrop supports one of those mediums. The README explains why: Wi-Fi Direct is not supported on macOS, Bluetooth needs further reverse engineering, and Apple's own peer-to-peer Wi-Fi, AWDL, is incompatible with Google's approach. So the design is not a shortcut. It is the subset that macOS actually permits without driver-level work.

Installing NearDrop and receiving your first file

The README gives two install routes. The manual one is to download the latest build from the releases section, unzip it, and move the app to your applications folder. Because the app is not notarized, the first launch requires a right-click and Open, followed by confirming that you want to run an app from an unidentified developer. The Homebrew route installs the app and clears the quarantine attribute in one line:

brew install grishka/grishka/neardrop && sudo xattr -r -d com.apple.quarantine "/Applications/NearDrop.app"

The xattr command removes the com.apple.quarantine flag that Gatekeeper uses to block unsigned apps. If you skip it, macOS will refuse the first launch until you right-click and choose Open. After the app is running, it appears in the menu bar. Sending from the Mac side uses the Finder share sheet: right-click a file, choose Share, then NearDrop. Links go through the menu bar instead, under File, then Share, then NearDrop, and Safari also exposes a share button on the toolbar. Receiving is the direction most people want, and it has a specific prerequisite. Android listens for BLE broadcasts to become visible automatically, and macOS does not let apps send them, so your Mac will not appear in the Android share sheet on its own. The workaround is a QR code that NearDrop generates. On Samsung devices the QR code, or an equivalent intent, is the only option. On other Android devices you can tap Quick Share inside the Google Files app, or create a shortcut to an activity intent such as com.google.android.gms.RECEIVE_NEARBY with mime type */*. If the Android device shows a PIN and nothing appears on the Mac, the README points at Do Not Disturb: turn it off, and check the notification centre, because the prompt occasionally lands there without a popup.

Visibility, medium support and the notarization trade-off

Two constraints deserve attention before you install anything. First, while NearDrop is running, your Mac is visible to everyone on the same network at all times. Limited visibility, the kind that restricts sharing to contacts, requires talking to Google servers, and temporary visibility requires listening for the trigger behind the device-nearby notification. Neither is implemented. On a home network that is a minor annoyance. On a shared or public network it is a real exposure, and the README itself warns that local network communication may not work on public networks such as coffee shops or hotels, where client isolation is common. Second, the app is not notarized and not on the App Store, and the README gives the reason plainly: the developer does not want to pay Apple's 99 dollar annual fee and opposes the review process. That is a legitimate stance, but it shifts the trust decision onto you. You are running an unsigned binary, and the quarantine removal command exists precisely because Gatekeeper cannot vouch for it. The licence is the Unlicense, which places the code in the public domain, so there is no copyleft obligation and no warranty. For a tool that touches your local network and writes files to disk, read the source before you run it, or at least understand that nobody has vetted the binary for you.

Where NearDrop stops working, and what to use instead

The clearest failure mode is the network itself. If your router isolates wireless clients, or you are on a guest network, or you are in a hotel, the two devices simply will not see each other, and no amount of retrying fixes it. The README says to check router settings to make sure local devices can talk to each other. The second failure mode is expectations. If you want to send from Mac to Android, the share sheet entry is there, but the receiving side still depends on the Android device being in a state where it can accept the transfer, and the README's instructions for that are Android-version and vendor specific. The third is the medium gap: no Wi-Fi Direct, no Bluetooth, no internet path. For anyone who needs transfers to work across networks, the realistic alternative is Google's own Quick Share on a Windows machine, which supports the full medium set including the WebRTC path through Google servers, or a cross-platform tool that does not depend on the Quick Share protocol at all. The difference in approach is fundamental: NearDrop implements one transport that macOS allows, while Google's client negotiates among several. If your workflow requires the others, NearDrop is the wrong tool, and the README is unusually honest about saying so.

Maintenance, releases and upgrade cost

The last push to the repository was on 2026-09-19, and the most recent release, v2.2.2, carries the same date. Before that, v2.2.1 landed on 2026-09-15. The gap between v2.2.0 in August 2025 and v2.2.1 in September 2026 is worth noting: this is a project that moves in bursts when protocol work or fixes land, not on a schedule. Upgrades are manual. There is no auto-update mechanism described in the README, so the Homebrew command is the closest thing to a repeatable upgrade path, and it re-applies the quarantine removal each time. That is a small ongoing cost, not a burden. The licence is the Unlicense, which means you can copy, modify and redistribute the code without conditions, and there is no warranty of any kind. For an unsigned app that listens on your local network, the practical implication is that the trust boundary is your own review, not a vendor's. The README also states that pull requests changing the readme will not be accepted, and that AI-assisted contributions will not be accepted, so if you plan to contribute, check AGENTS.md and CLAUDE.md in the repository root first.

Editorial conclusion

NearDrop suits macOS users who regularly move files from Android and accept a menu bar app that is visible on the local network and not notarized. It is the wrong tool if you need Wi-Fi Direct, Bluetooth, internet transfers, or a curated app store install. Before adopting it, verify that both devices sit on the same Wi-Fi network, that the router does not isolate clients, and that you are comfortable running an unsigned app you opened manually.

Frequently asked questions

Official sources

1. grishka/NearDrop on GitHub
2. Issues
3. License: Unlicense
4. README
5. Releases