One of the most convenient aspects of Air Drop for me is that it selects the fastest available connection between the devices and ability to work without both devices being on the same network.
I tried on three phones, two of which are using the same account, I'm reasonably confident I am technically competent to not make silly mistakes, though the best I've achieved was endless wait.
I had better success with IR and BT file transfers. Hell, even spinning a local http server (with python -m http.server) works better than quick share.
I like kde connect, but find it randomly breaks every month or so and for the life of me cannot figure out why. A week or so later it starts working again.
Recently started using it, it works really well and it's much more reliable than AirDrop. But the UX could be improved.
But I just wish Apple fixed AirDrop, every time I go to use I have so little confidence in it, it often doesn't see devices or if you have multiple Mac users it will confuse them, showing you the same Mac device twice without telling you which user it is
Yup, for me I can see the device but when I try to initiate a send it just doesn't show up on the other device about half the time. I've not found a reliable way to fix it either, toggling AirDrop on and off on both devices seems the best way to fix it but only works like 70% of the time.
I'm curious, what do you people use this for? What are all these (presumably large) files that you guys are generating and transferring, that requires the use of apps like these?
Like in my case, the only files I generate on my phone are photos and videos, and these get backed up by Immich, which I can then share with someone by sending them a link to the files/album in question. I imagine normal folks would use iCloud or Google Photos for the same task.
For syncing other files like documents and such, I use ownCloud OCIS, and I'd imagine most other folks would use something like DropBox or iCloud, or even just email or WhatsApp the files.
For local network transfers of say ISOs or something, I'd just copy them over SMB, which is pretty much universal and doesn't need any special app. Or even just plug in a hard drive, if I'm doing backups.
For me, video is the main one. Sizes from 100MB - 3GB. Getting videos from an Apple device to an Android is a pain in the ass because I need to 2FA log in or click through something relatively convoluted (Dropbox, GDrive) or deal with pulling out some hardware I use once every 100 years (external drives). Localsend is a 2 or 3 click operation and very robust.
Silly apple. They should remove airdrop and tell users they have to rely on an internet connection and use whatsapp or email for quick, one-off file transfers between their iphones and macbooks.
Sending plain text from one device to another. I was debugging my steamdeck and I send code snippet from desktop chatgpt to steamdeck using Localsend to run. Then I send the debug output (also plaintext) back to desktop to ask chatgpt what to try next. Other than this, random small files from time to time. The app is lightweight and just works.
I use it for moving SSH keys, VPN configs, and .env files between my laptop and a work machine. Obviously don't want that sitting in dropbox, pasted into Slack, etc. Localsend on the same network, gone in two seconds no account and no history. Easier than spinning up scp every time.
I only use it for sending a bunch of photos that wouldn't go so well over iMessage, usually on vacation. And sometimes that vacation involves not having cell service. Otherwise I'll usually message a single photo to someone because AirDrop is finicky.
I can't get it to work on my end. Tried sending/receiving with Firefox, Chrome, mobile phone, a laptop.
Got this in the console: `WebRTC: ICE failed, add a TURN server and see about:webrtc for more details.` Not sure how to troubleshoot this. Most of the suggestions I found are for the devs not users.
EDIT: Ok, figured it out. It works if I disable Tailscale.
came with omarchy pre installed, usedd it ever since. bonus points for it being open source too.
i was surprised it is written in flutter. looking at how mutli-platform it is, flutter was the more appealing choice.
Because none of them actually match the capabilities of AirDrop, since they essentially require controlling the full stack (UI, low-level networking including Bluetooth for discoverability, Wi-Fi peer to peer connections without dropping any existing infrastructure connection etc.)
Many have tried, I don't think anyone has succeeded.
Supposedly the EU interoperability mandate will make this possible going forward, though? (The tricky part is usually not getting your device to speak some protocol, but to get Apple devices to actually respond to your attempts.)
It’s not as slick as AirDrop and you have to sort of “prep“ both devices whenever you want to send/receive anything, it’s never just ready to go, but it’s incredibly reliable and will move anything from one machine to another. Just having that consistency across literally any device is so nice.
My problem is that all these alternatives require the devices to be on the same local network.
One beauty of Airdrop is that it creates and handles that local network automatically under the hood (as far as I understand). So you could be out on a hike with friends and Airdrop something.
The workaround I've found after switching to an Android device has been to teather my connection to my friend's device, which ends up creating a LAN that Localsend can work through, but this is not as nice an experience.
Not generally, I just don't have that specific phone that has implemented the workaround, and so this isn't a solution for me.
Apple has consistently done everything it can to self-sabotage their implementations of stuff to comply with EU anti-trust legislation like the stuff with digital marketplaces, so I'm not holding my breath on this.
it's widely expected Apple will find some way to lock it out
I suppose that is "widely expected" from the usual group of anti-Apple internet griefers looking for a reason to moan in public, rather than actually doing some research or knowing things.
To quote a sibling comment:
"Apple contributed the core logic to the Wi-Fi Alliance to build Wi-Fi Aware, which they now also support."
I don’t think this article is actually accurate. It seems like Google just reverse engineered airdrop rather than Apple changing the tech they use. Because quickshare works with all airdrop devices now. Not just ones recently updated.
The protocol Apple uses under the hood is AWDL (Apple Wireless Direct Link), which is a proprietary peer-to-peer layer that runs alongside your existing WiFi connection without dropping it. It uses a time-sliced channel-hopping mechanism so the radio can serve both infrastructure WiFi and the direct peer link simultaneously.
That's the part that's hard to replicate. LocalSend and most alternatives need an existing shared network because they're just TCP/IP, they have no way to negotiate a direct radio link without OS-level support. Even Android's QuickShare, which does peer-to-peer via WiFi Direct, drops your existing WiFi connection on older devices because the radio can only be associated with one BSS at a time.
The EU interoperability mandate lxgr mentions would theoretically require Apple to expose this, but AWDL interop would mean licensing or reverse-engineering some fairly deep radio scheduling logic, so I'd expect compliance via a different (probably slower) path.
AWDL is such an amazing technology, it's understandable that Apple wants to keep it only for their devices as it gives them a noticeable advantage for quick stuff sharing.
it might be interesting to use unused or extra wifi cards to support this. My pc motherboard has both wifi and ethernet and I only use the ethernet. That card does absolutely nothing at all.
I've definitely used STA and AP modes concurrently on my Windows laptop with the operating system's built-in internet connection sharing function to help troubleshoot a problem in the field.
That was around a decade ago. It didn't take any extra effort on my part; I just told it to do the thing, and then it did that thing.
>It uses a time-sliced channel-hopping mechanism so the radio can serve both infrastructure WiFi and the direct peer link simultaneously.
This seems like such a basic solution that I'm surprised that it isn't required by any of the mainstream standards before WiFi Aware. I wonder if this was some sort of a patent issue or similar.
This is misinformation, including most of the comments here, the majority of phones from 2014 support Wi-Fi Direct, and simultaneous group and station mode (2 BSS, yes even different channels). Even most Wi-Fi chips generally not just smartphones for a very long time. They stay connected to your home network.
When Quickshare drops your Wi-Fi connection, its not Direct anymore, that's just soft AP from an error, and if that doesn't work, it fallback to Bluetooth. Bluetooth is used for provisioning as well.
The only reason why many apps don't use it is because of buggy implementation, some phones require a full restart after using Wi-Fi Direct to fix connectivity issues, even Motorola's own product line with Smart Connect use it only with certain models, despite having Wi-Fi direct due to poor implementation (can be forced).
They even have a white list of supported adapter for the Windows app since direct is used as well, can be unofficially force enabled for Mediatek based adapters (rare on some laptops).
Back in 2016 things were much stable on Android phones with Wi-Fi Direct, even with old Blackberry, there were many apps including file managers that used it before it was essentially dropped, even for onboarding/provisioning apps like HP printers...
Apple's Airdrop success is about gaining traction, in the era of Wi-Fi Direct or other methods, most people were not aware of such features, as it required an app to be installed, they used email/messaging, even when Airdrop was first introduced and preinstalled, it took years for the average person to use it.
It is entirely possible to inject (unrelated) wifi frames while being associated to a BSS without violating the existing 802.11 standards. That’s why Apple is able to implement AWDL on standard compliant wifi hardware.
However the path towards this type of interoperability would likely go through additional standardization via IEEE 802.11* and the Wi-Fi alliance. At which point Apple will need to implement and support the new standards. There is no need to reverse engineer AWDL to meet the new European interoperability requirements.
What is needed is for wifi chipset OEMs to implement such standardization.
Something pretty routine of them.
It can be expected that Apple will also maintain the proprietary AWDL in order to support their legacy devices.
AFAIK, Wi-Fi Aware / Neighbourhood Aware Networking is basically the "standardised" version of AirDrop, and as of 2025, iOS's Airdrop transparently inter-operates with it.
> which is a proprietary peer-to-peer layer that runs alongside your existing WiFi connection without dropping it. It uses a time-sliced channel-hopping mechanism so the radio can serve both infrastructure WiFi and the direct peer link simultaneously.
Maybe a network nerd can chime in - is this implementation so difficult that it's unrealistic we'll see an OSS version?
I think the thing that makes an OSS implementation more difficult than iOS/macOS is the friction involved.
Say you've got an android phone, windows PC, and a linux box, and you want to be able to quickly drop files from each one. unless we get some kind of cooperation across all three platforms at the OS level, you'd at minimum need to install some kind of client into each system - when the nicest feature of airdrop is that it's baked into all of Apple's OSs, in my opinion. even if it worked exactly the same way, but had to be installed, I think it would see less use - and there's no real way for a single OSS project to do that across multiple OS platforms, to my knowledge
The physical layer part really isn't complicated, and most Wi-Fi chipsets have supported something like it for over a decade now.
What's tricky is to specify and get everybody to implement the layers on top of it, including device discovery (frequently offloaded to Bluetooth for efficiency reasons), user identification (Apple runs a PKI for this) etc.
Is this working seamlessly? Iirc you needed to switch settings to bypass the contacts only thing. Plus Apple can of course create more adversarial hurdles to lock other vendors out.
And, of course this only solves the phone - phone, and not even all of them. Desktops & laptops have less hope.
There is an open standard for that which is included in Apple devices since the iPhone 15. google implements it since the pixel 3. It’s called NAN. There are no WiFi cards available for consumers to buy which expose that as part of their firmware sadly. But wpa_supplicant has implemented part of the standard.
> It uses a time-sliced channel-hopping mechanism so the radio can serve both infrastructure WiFi and the direct peer link simultaneously.
This is really nothing special as 802.11 implementations go, as it's pretty easy to do as long as you can control the physical channel for at least one side.
Many Windows, Linux, and Android devices have been supporthing this for years. It's usually called something like "simultaneous AP/STA mode".
I'm honestly surprised that WiFi Hotspot doesn't isolate hosts, after companies like Meta have been caught running servers inside their apps and connecting to those to track users.
Yes exactly, that's why another RCE which will be found in Airdrop, if found by bad actor. Will be pretty fun to watch.
Last RCE in Airdrop, could be made into worm, it was found by whitehat, luckily for Apple there are still people, which are willing report exploits for little money, so billionaires can enjoy their life on yachts.
> The workaround I've found after switching to an Android device has been to teather my connection to my friend's device, which ends up creating a LAN that Localsend can work through, but this is not as nice an experience.
Not only that, but with iOS 17.1 or later, AirDrop transfers will continue to work if you go out of Wi-Fi range during the transfer. It seamlessly switches to an Internet-based relay.
Which, in my view, significantly decreases the value proposition, as there is no way to deactivate this feature to my knowledge (at least not without also opting out of other useful features under the "Handoff" umbrella).
A typical Apple feature, dreamed up by engineers that are presumably not aware of the existence of metered data plans...
This. Localsend may be very useful for a set of devices you control or influence. The USP of Airdrop is ad hoc sharing with people you don't really know. Classic case is meeting strangers on holiday and you want to swap some photos of the trip you're on. One or both of you doesn't have data or time to install anything, or it's just too hard to persuade someone they should install random app. Pairing Bluetooth or setting up local networks is way too convoluted and time consuming.
With Airdrop you have trivially easy, "just works" sharing with people in proximity. It works great between iPhones and Pixel phones now they support it. It just needs support to spread to more Android devices.
It really helped cement how great open source apps can be for me.
I wonder if any of the alternatives do the same.
I tried on three phones, two of which are using the same account, I'm reasonably confident I am technically competent to not make silly mistakes, though the best I've achieved was endless wait.
I had better success with IR and BT file transfers. Hell, even spinning a local http server (with python -m http.server) works better than quick share.
This one fails the "must not require an existing Wi-Fi network that both peers are connected to" criterion.
[1] https://craphound.com/spamsolutions.txt
But I just wish Apple fixed AirDrop, every time I go to use I have so little confidence in it, it often doesn't see devices or if you have multiple Mac users it will confuse them, showing you the same Mac device twice without telling you which user it is
Like in my case, the only files I generate on my phone are photos and videos, and these get backed up by Immich, which I can then share with someone by sending them a link to the files/album in question. I imagine normal folks would use iCloud or Google Photos for the same task.
For syncing other files like documents and such, I use ownCloud OCIS, and I'd imagine most other folks would use something like DropBox or iCloud, or even just email or WhatsApp the files.
For local network transfers of say ISOs or something, I'd just copy them over SMB, which is pretty much universal and doesn't need any special app. Or even just plug in a hard drive, if I'm doing backups.
So I don't understand why I should be using this.
Sending a photo over text message often compresses it, which isn't always desirable. (Not actually sure if it gets compressed when sent of iMessage)
I've also used it to send people photos when we were in places without cell service like on hiking and camping trips.
From windows to android to iOS.
Got this in the console: `WebRTC: ICE failed, add a TURN server and see about:webrtc for more details.` Not sure how to troubleshoot this. Most of the suggestions I found are for the devs not users.
EDIT: Ok, figured it out. It works if I disable Tailscale.
What's the main value prop over wormhole? That it works from the browser?
That you can set the recipient so it will auto-accept from the trusted senders.
And for me that in Android I can do Share to....localsend to do it faster than with wormhole.
Many have tried, I don't think anyone has succeeded.
Supposedly the EU interoperability mandate will make this possible going forward, though? (The tricky part is usually not getting your device to speak some protocol, but to get Apple devices to actually respond to your attempts.)
One beauty of Airdrop is that it creates and handles that local network automatically under the hood (as far as I understand). So you could be out on a hike with friends and Airdrop something.
The workaround I've found after switching to an Android device has been to teather my connection to my friend's device, which ends up creating a LAN that Localsend can work through, but this is not as nice an experience.
Apple has consistently done everything it can to self-sabotage their implementations of stuff to comply with EU anti-trust legislation like the stuff with digital marketplaces, so I'm not holding my breath on this.
I suppose that is "widely expected" from the usual group of anti-Apple internet griefers looking for a reason to moan in public, rather than actually doing some research or knowing things.
To quote a sibling comment:
"Apple contributed the core logic to the Wi-Fi Alliance to build Wi-Fi Aware, which they now also support."
https://github.com/KeibiSoft/KeibiDrop
That's the part that's hard to replicate. LocalSend and most alternatives need an existing shared network because they're just TCP/IP, they have no way to negotiate a direct radio link without OS-level support. Even Android's QuickShare, which does peer-to-peer via WiFi Direct, drops your existing WiFi connection on older devices because the radio can only be associated with one BSS at a time.
The EU interoperability mandate lxgr mentions would theoretically require Apple to expose this, but AWDL interop would mean licensing or reverse-engineering some fairly deep radio scheduling logic, so I'd expect compliance via a different (probably slower) path.
Anyway, good to know we can use our NAN signal to send signal NaNs!
It’s a future promising tech though. A much better version of Wi-Fi Direct.
* https://www.wi-fi.org/wi-fi-aware-resources
* https://developer.apple.com/documentation/WiFiAware
* https://developer.android.com/develop/connectivity/wifi/wifi...
I've definitely used STA and AP modes concurrently on my Windows laptop with the operating system's built-in internet connection sharing function to help troubleshoot a problem in the field.
That was around a decade ago. It didn't take any extra effort on my part; I just told it to do the thing, and then it did that thing.
This seems like such a basic solution that I'm surprised that it isn't required by any of the mainstream standards before WiFi Aware. I wonder if this was some sort of a patent issue or similar.
When Quickshare drops your Wi-Fi connection, its not Direct anymore, that's just soft AP from an error, and if that doesn't work, it fallback to Bluetooth. Bluetooth is used for provisioning as well.
The only reason why many apps don't use it is because of buggy implementation, some phones require a full restart after using Wi-Fi Direct to fix connectivity issues, even Motorola's own product line with Smart Connect use it only with certain models, despite having Wi-Fi direct due to poor implementation (can be forced). They even have a white list of supported adapter for the Windows app since direct is used as well, can be unofficially force enabled for Mediatek based adapters (rare on some laptops).
Back in 2016 things were much stable on Android phones with Wi-Fi Direct, even with old Blackberry, there were many apps including file managers that used it before it was essentially dropped, even for onboarding/provisioning apps like HP printers...
Apple's Airdrop success is about gaining traction, in the era of Wi-Fi Direct or other methods, most people were not aware of such features, as it required an app to be installed, they used email/messaging, even when Airdrop was first introduced and preinstalled, it took years for the average person to use it.
However the path towards this type of interoperability would likely go through additional standardization via IEEE 802.11* and the Wi-Fi alliance. At which point Apple will need to implement and support the new standards. There is no need to reverse engineer AWDL to meet the new European interoperability requirements. What is needed is for wifi chipset OEMs to implement such standardization. Something pretty routine of them.
It can be expected that Apple will also maintain the proprietary AWDL in order to support their legacy devices.
Maybe a network nerd can chime in - is this implementation so difficult that it's unrealistic we'll see an OSS version?
Say you've got an android phone, windows PC, and a linux box, and you want to be able to quickly drop files from each one. unless we get some kind of cooperation across all three platforms at the OS level, you'd at minimum need to install some kind of client into each system - when the nicest feature of airdrop is that it's baked into all of Apple's OSs, in my opinion. even if it worked exactly the same way, but had to be installed, I think it would see less use - and there's no real way for a single OSS project to do that across multiple OS platforms, to my knowledge
What's tricky is to specify and get everybody to implement the layers on top of it, including device discovery (frequently offloaded to Bluetooth for efficiency reasons), user identification (Apple runs a PKI for this) etc.
And, of course this only solves the phone - phone, and not even all of them. Desktops & laptops have less hope.
This is really nothing special as 802.11 implementations go, as it's pretty easy to do as long as you can control the physical channel for at least one side.
Many Windows, Linux, and Android devices have been supporthing this for years. It's usually called something like "simultaneous AP/STA mode".
A research lab from TUD worked on a project investigating Apple's wireless ecosystem Link: https://owlink.org/publications/
Also something interesting that I remembered reading closely linked to AWDL?
Link: https://projectzero.google/2020/12/an-ios-zero-click-radio-p...
But it is not super reliable or friendly.
[1] https://github.com/spieglt/FlyingCarpet
It's a pretty polished PWA you don't even need to install as it uses WebRTC P2P streaming in the local network or via TURN over internet.
So a good solution for ad-hoc file sharing without ad-hoc network.
"You could fix that by builing a rail track and using a train."
The whole point of these solutions is to not have to transmit data over the internet, it should work over a local dynamic connection.
Last RCE in Airdrop, could be made into worm, it was found by whitehat, luckily for Apple there are still people, which are willing report exploits for little money, so billionaires can enjoy their life on yachts.
Usually, but not always.
> The workaround I've found after switching to an Android device has been to teather my connection to my friend's device, which ends up creating a LAN that Localsend can work through, but this is not as nice an experience.
A typical Apple feature, dreamed up by engineers that are presumably not aware of the existence of metered data plans...
With Airdrop you have trivially easy, "just works" sharing with people in proximity. It works great between iPhones and Pixel phones now they support it. It just needs support to spread to more Android devices.