Localsend: An open-source cross-platform alternative to AirDrop
github.com
github.com
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."
If we had good mobile OS I bet we would have a solution for both...
Personally I just use wifi/smb for file transfer and hate it when someone comes with their iPhone and isn't able to send a file to me.
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.
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.
As for WiFi NAN: support for it seems rather limited outside of iOS and Android. From what I can tell the feature is barely tested on Linux and I can't find any generic Windows APIs for it either.
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.
1. Backoff and timer logic to not flood network.
2. Caching entries for the same reason.
3. Handling multiple network interfaces, and detecting when they changed.
for 1. i send a mutlicast of max 512 bytes on 224.0.0.167:26999 every 3 seconds 2. not really caching, just have a map of people that get discovered.
and god bless, I just rolled with this. if people will use the tool and they will complain about it, then it will be a problem for later. for me between my home devices did not notice inconveniences.
in total around 200 lines of golang.
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.
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.
Both UI and CLI with complete feature parity on any device/OS, between the same user's devices and between users.
"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...
Settings > General > AirDrop > turn off Use Cellular Data
That said, I don’t really see why you would disable that. It’s only a backup method for when the peer-to-peer connection fails. Unless you are sending huge files on a regular basis, I wouldn’t expect it to be worth disabling. Also, most metered plans I’ve encountered just cause your connection to be very slow after you hit the data cap.
If you are on a plan that automatically charges you excessive overage fees without warning and there is no other choice, then my condolences.
I stand corrected, and I appreciate that Apple did consider the non-Bay-Area use case :)
> Unless you are sending huge files on a regular basis
I do use AirDrop extensively for sharing photos when traveling. One sharing session could easily eat through my roaming allowance.
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.
Funny enough, I encounter so many problems trying to share things via AirDrop with friends, family, and even my own Apple devices that I just tell everyone to install LocalSend and I find that things work better.
I’m not sure why that is, because AirDrop used to work pretty well for me. But it’s been an exercise in frustration more often than not for me.
(Obviously, LocalSend works only as long as everyone is on the same network.)
Iroh's protocol can figure out if the devices are on the same LAN and avoid going over the internet. It can work without a discovery server too -- i.e. completely LAN.
- Create an ad-hoc Wi-Fi network on one device.
- Connect the other device(s) to that Wi-Fi network.
- Now run Localsend.
The first two steps are a bit of a drag, and the fact that Airdrop handles it is what makes it so frictionless to use.
AirDrop is fantastic for sharing files with people you don't know/just met - if we have to find and agree to join the same wifi before we interact we are no longer talking about the same feature.
If Apple's AirDrop implementation had required people to join the same WiFi first, the feature would never have taken off the way it has among non-techy users. I'm still today mildly surprised I can use AirDrop as a verb in conversation and most of the time the other party knows what I mean.
It works on iOS and Android
Device to device transfer, just a static github page.
gh repo: https://github.com/mbarlow/thinair
Creates QR codes for each device to scan for webrtc. Android to android will do an audible chirp that lets the devices know to switch from qr code mode to opening the camera to scan each others codes. Tested android to apple and working, the audio chirp doesn't get caught by apple. Just wait and eventually the qr code will dissolve to allow scanning step.
Just threw this together. I was playing with audio handshake using bird-like chirp "songs" or old school modem between smartphones. Fun putting phones together as they send audio frames and confirm to start transfer, but unreliable and slow to handshake. I would like to cleanup the flow to improve. I've started using it for sending files between iphone/android/pc without having to deal with apps, emails, accounts, etc. blah.
Also you don't even need a server atleast for now in chrome webrtc transfer can work over a file:// in firefox it doesn't. For signaling you could even use free peerjs tunnel or other when user is connected to internet and otherwise fallback to this QR or offer code sharing. This will become so useful if browsers eliminate those bottlenecks.
also even in localsend speeds are limited usually to my internet speed for some reason.
UI, CLI, Local network, over the internet, anything. P2P + E2EE.
It's Android App don't need LAN to share: https://play.google.com/store/apps/details?id=com.fastfileli...
Been using Localsend to transfer bigger files between phone / laptops, never fails or has trouble finding a device, or stalling.
https://github.com/thiswillbeyourgithub/WebSend
Note that I'm currently refactoring it heavily (the code is awful currently).
If we would have good operating systems, perhaps this would be easier and more widely spread. Otherwise the solution has to come from the device manufacturer.
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.
This one fails the "must not require an existing Wi-Fi network that both peers are connected to" criterion.
From my earlier comment about a similar thread a couple days ago about which file sharing apps people use [3]:
[0] https://github.com/n0-computer/sendme
[1] https://github.com/tonyantony300/alt-sendme
A similar project but this one works entirely in the browser and can connect to clients beyond your local network with "public" rooms
They forked sharedrop after it and snapdrop got acquired and enshittified by LimeWire, whoever that is now.
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.
I am late to the party, but I was also building in this space in the last year,
Basically I did a peer to peer filesystem named keibidrop: https://keibidrop.com/
I made it public last week. It does what local send does, but also via WAN. Still did not launch the mobile apps.
And 1 up is that it has also a virutal filesystem that is synced both ways.
repository is here: https://github.com/KeibiSoft/KeibiDrop
The code is open source, except for the UI, and I did benchmark on loopback vs localsend (local send is faster :D )
https://keibisoft.com/blog/keibidrop-benchmarks-vs-competiti...
and was also trying to get a commenting thread in /r/golang yesterday!
behind the hood I went with PQC, + gRPC + FUSE.
Here I skipped the server part. I just connect two devices.
If they both use the virtual mountpoint
MountAlice and MountBob
They get an underlying SaveAlice and SaveBob on disk.
so what gets dropped in MountAlice gets saved to SaveAlice, and appears in MountBob.
Once bob accesses it in MountBob it gets cached to SaveBob (like saved persistently to disk). But while the transfer happens a mmap is saved to disk to keep track of the segments that were transmited.
If changes happen on Alice for the file, GetAttr metadata is synced when the filehandler on Alice is released. and Bob knows to request the parts of the file that changed.
It did not go for the full-on folder sync. I went for a synced filesystem while the peers are connected.
And because ios and android do not have FUSE, i also added the option to add a file/ pull a file, that does the same thing.
So now, you can add folders/ files on android/ ios. and mount them as a filesystem on your desktop and do magic with them, and if they get changed you can export them back from the phone to the gallery or w/e files
https://keibisoft.com/tools/keibidrop-vs-alternatives.html
its more towards vibey marketing talk and at the same time tried to keep it as honest as possible.
But I warn you, there are still some kinks. Only 75% pjdfstest (filesystem test suite) passes in terms of POSIX compliance. I do not support hardlinks/symlinks by design.
I was trying last to use postgresql on the virtual filesystem, then once the server is stoped, to remove the lock file, and open it on the peer. and some files got corrupted while running this test.
It really helped cement how great open source apps can be for me.
But it has one really big weakness/bug. When you transfer a file and it get interrupted, the half written file on the receiving end is not removed and you get an corrupted file. If you dont notice it, it could look like al files are transfered, but they are not. This is really bad, it is not how files should be "copied/transfered".
Previously I was using syncthing or had to install ftp server, used wormhole after packing all my files into one, etc. Android QuickShare never worked for me (wouldn't help me much with sending to the pc either).
It has some rough edges (ie: on multi-homed devices it's less that ideal to see the one octet that matters, when the list is very long scrolling whilst sending will cause the process to crap out), but other than that it's always reliable.
I'm very happy with it too.
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.
With a CLI tool as well: https://github.com/timvisee/ffsend
Test:
* Does it work in an airplane?
* Does it work in a submarine?
* Does it work in the mountains, when a thunderstorm is approach and you need to share the GPX?
Implementation shall be able to negoiate a connection locally (e.g. Bluetooth) and upgrade to peer-to-peer WiFi if need (Garmin doesn’t need that part, GPX are usually smaller than 1024 KB).
It seems like a lot of extra work to reinvent the wheel and get the security wrong instead of extending a well established protocol with many other tools built on top of it.
I have not really used airdrop, and this app is super useful to me.
Just set this up in a few minutes and it works a peach (quite fast, too). Just nudged me a little closer toward a "just use Linux" default.
Localsend: An open-source cross-platform alternative to AirDrop - https://news.ycombinator.com/item?id=43343574 - March 2025 (1 comment)
Localsend: Open-Source Airdrop Alternative - https://news.ycombinator.com/item?id=37938183 - Oct 2023 (229 comments)
Localsend: An open source cross-platform alternative to AirDrop - https://news.ycombinator.com/item?id=34936796 - Feb 2023 (1 comment)
(Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers)
https://github.com/thiswillbeyourgithub/WebSend
Note that I'm currently refactoring it heavily (the code is awful currently).
I do not love that it is a heavy electron app that takes many seconds to launch on my mid-spec machine and burns 20% of an entire CPU core the entire time it is running.
Why can't we have a simple command line tool that works?
The F1TV app is not available in my country on play store on my Google TV. The first time, I logged into the device using the android debugger to install the APK - I didn't want to use an ad-full app. Then I tried LocalSend, and it is now my default to send the APK from my mac to my android tv. Love the simple experience. Minor quirks in the UI, but gets the job done.
https://web.dev/articles/web-share
https://developer.chrome.com/docs/capabilities/web-apis/web-...
(I'm all for alternatives to AirDrop. I'm all for AirDrop inter-operability. Nothing against those things.)
For LAN file sharing, you can do it with any browser. Implementations like: https://sendfiles.dev/ (though there are many others)
1) require no app installs (at least beyond those you already have).
2) not require the same network
Most solutions fail one or both of these. Of course AirDrop isn't perfect (It doesn't work outside iOS so if you know any Android users you are quickly out of luck).
https://github.com/thiswillbeyourgithub/WebSend
Note that I'm currently refactoring it heavily (the code is awful currently).
Am I correct in thinking community maintainers have little to no visibility therefore?
Additionally, is there any indication what source code is used to build an app store submission? Even a checksum?
Here's my question, y'all. What is the deal with the magic Syncthing uses and why can't we use it for stuff like this? And well, for everything?
(I've been doing this stuff for years and I still can't wrap my head around this question)
In contrast, sftp did hundreds of MB/s
It doesn’t solve every edge case but I don’t need it to.
- for whatever reason, even the same sized directory takes much much longer than its corresponding archive version when using this tool
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.)
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.
[0]: https://libp2p.io/
But I consider my usage of it to be on borrowed time cause there's no way they're gonna let everyone forever beam unlimited data through their servers forever. They're accumulating users before they make you pay, it's just a matter of time. But I'm enjoying it while I can.
End-to-end encrypted, no need to be on the same LAN, upload/download auto-resume, real-time transfers (start downloading before upload finishes), really fast (10 Gbps link, smart chunking).
Also zero-knowledge logins (via OPAQUE), passkey/2FA support, no AI training now or ever, GDPR compatible. 2 GB transfers are free.
Then you can transfer files to and from uncool people with Android or Linux phones/computers using localsend.
I've never found this difficult and often use hotspots when I'm overseas - it's cheaper to get internet for one phone and share it with the others for example.
maybe eventually something like quickshare & airdrop mold into an interoperable thing but i'm not holding my breath