What issues do people most commonly run into with LocalSend?

I’ve seen both praise and complaints online, but nobody really explained the details. What kinds of issues seem to come up most often for users?

I used LocalSend for the usual stuff, phone photos to a laptop, PDFs from a Mac to Android, random text snippets between devices. It runs on your local network, so no internet is needed once both devices are on the same Wi-Fi. No account setup, no cable hunting, no cloud upload in the middle. You open it on both ends, wait a second, and the devices usually show up.

Why people stick with it

The big draw is simple. It works across Windows, macOS, Android, and other platforms without forcing you into one ecosystem. I liked being able to move a file from a PC to a phone without signing into anything. If your setup is normal and both devices sit on the same network, transfers tend to be quick enough for daily use.

For home use, it fits. For office use, same deal, if the network rules are loose enough. Photos, videos, docs, small batches of files, all of it feels easy when it behaves.

Still, I hit rough spots. Firewalls get in the way. VPNs break device discovery. Some routers seem weirdly picky. And big folder transfers do fail for some people, depending on the system and folder contents.

So my read on it is mixed, but useful. For everyday local sharing, it does a lot right. Small setup, decent speed, no cloud dependency, better privacy than tossing files through someone else's server.

Where it usually breaks

The issue I saw most often was discovery failing. Your phone and computer are on the same Wi-Fi, yet one refuses to see the other. Most of the time this points to firewall rules or router settings blocking the ports LocalSend needs.

VPNs are another common mess. If one device has a VPN turned on, LocalSend often loses sight of the local IP address and the apps stop detecting each other. I had to shut the VPN off to get things moving. Some setups let you exclude the app, which helps if you do not want to disconnect the VPN entirely.

Folder transfer bugs are a thing

Single files usually go smoother than full folders. Once folders enter the picture, weird errors start showing up. I kept seeing reports like this one, users report issues, and the pattern matches what people describe on Windows in particular.

The annoying part is the vague error text. 'Missing permissions' does not tell you much. Which file failed. What permission is missing. Whether the problem is the folder name, a hidden file, or some OS restriction. You end up poking around and trying again, which gets old fast.

Security talk and plain old reliability

I also ran into debate regarding the security of the web app version. That discussion makes sense. Anything exposed across a network deserves scrutiny, even if the tool is local-first and open source.

Then there is the less dramatic issue, Wi-Fi being Wi-Fi. If your signal drops or jumps around, a long transfer might die halfway through. Bigger files make this more obvious. When that happens, you are stuck checking what copied, what did not, and whether any file got damaged in the process. It is not rare. I saw it enough to stop trusting wireless transfers for large jobs.

A wired option when you need less drama

If you are moving huge batches of files, or large media libraries, wireless tools start to feel shaky. In those cases, I would lean toward a wired connection. On Mac, one option is MacDroid, which connects an Android device to macOS over USB.

What stood out to me is how it shows the Android device in Finder like external storage. You work with files directly instead of waiting for devices to rediscover each other over Wi-Fi. A cable is less convenient on paper, sure, but it cuts out a lot of failure points.

What you get with it:

  1. Access to internal storage and external storage, including SD cards.
  2. Two connection modes, MTP for normal file transfers and ADB for faster or more advanced work.
  3. The option to edit files from your Mac and save them back to the Android device without extra steps.

For large transfers, this route avoids the usual LocalSend pain points, stalled uploads, dropped connections, partial copies, missing files. It also keeps everything local, which matters if you do not want your files passing through cloud storage at all.

2 Likes

Most complaints fall into 4 buckets.

  1. Device discovery fails.
    This is the big one. Both devices sit on the same Wi-Fi, but one never appears. Often it is guest Wi-Fi, AP isolation, strict firewall rules, or a VPN hijacking local traffic. @mikeappsreviewer mentioned this, and I agree it is common. I’d add campus, hotel, and office networks are worse than home setups.

  2. Transfers stall or fail on big jobs.
    Small files usually go through. Large videos, lots of photos, or whole folders are where people get mad. You see hangs at some percent, random cancels, or one side stops responding. This hits weaker Wi-Fi harder. It’s not only a LocalSend issue, but users still blame the app, fair or not.

  3. Folder handling is flaky.
    This gets reported a lot on Windows and Android combos. One weird filename, hidden file, permission mismatch, or storage restriction and the whole send blows up with a vague error. That part needs better error reporting, no question.

  4. Background restrictions on phones.
    Android battery saving and iPhone network behavior sometimes kill discovery or interrupt receives when the app is not in front. People think the app is broken, but the OS is often doing the damage.

Less common, but still seen.
Slow transfer speeds compared with what people expect from local Wi-Fi.
Confusion over where received files were saved.
Security concerns from people who do not like opening local network services.

My take, LocalSend is great for quick sends. It gets shakey for big libraries. If you move huge batches from Android to Mac often, MacDroid is a safer bet becuase USB removes the Wi-Fi mess entirely.

The complaints are pretty predictable once you look past the hype.

Biggest one is not actually transfer speed, it’s inconsistency. LocalSend can work flawlessly for a week, then one day a device just refuses to appear. @mikeappsreviewer and @sognonotturno already covered discovery issues, but I’d push it a bit further: a lot of people call it “buggy” when it’s really super dependent on network conditions it does not control. That’s not a total excuse, just reality.

The common pain points I keep seeing:

  1. Devices not showing up
    Usually caused by network isolation, firewall rules, or VPN routing. Also happens on “smart” mesh networks more than people expect.

  2. Sends that fail halfway
    More common with large video files, giant photo dumps, or mixed folders. Small files make the app look rock solid. Big jobs expose all the cracks.

  3. Folder transfers being weird
    I actually think this is one of the more annoying problems than people admit. One locked file, odd filename, or storage permission issue and the whole thing can throw a vague error. Not super helpfull.

  4. Mobile OS interference
    Battery optimization, background app limits, sleeping screens. People blame LocalSend, but Android and iPhone both love killing background activity.

  5. Receive location confusion
    This sounds minor, but it comes up a lot. People send something successfully, then can’t figure out where the file landed.

I’d slightly disagree with the “great for office use” angle though. On locked-down office networks, LocalSend gets sketchy fast.

For quick one-off sharing, it’s awesome. For repeated Android-to-Mac bulk transfers, I’d honestly use MacDroid instead. USB is less exciting, but way less flaky for large batches.

I’d put the most common LocalSend complaints into one bigger theme: it is excellent when the environment is simple, and fragile when anything is slightly unusual.

@sognonotturno, @boswandelaar, and @mikeappsreviewer already covered discovery, stalled transfers, folders, and phone background limits, which are absolutely the main buckets. Where I’d add nuance is this:

  • Version mismatch causes weird behavior more often than people realize. If one device is on an older build, you can get odd failures that look like networking problems.
  • Enterprise or “managed” devices are a pain. Work laptops with security software can silently block local traffic even when Wi-Fi looks fine.
  • The app can feel too opaque when something breaks. This is honestly my biggest criticism. Users get a failed send, but not enough detail to know whether it was permissions, path naming, storage access, or the network dropping.

I slightly disagree with the idea that it is mainly “shaky for big libraries” only. Even medium-size transfers can be annoying if there are lots of tiny files. That is where overhead, indexing, and folder structure issues start showing up.

What people usually praise:

  • No account
  • No cloud relay
  • Cross-platform
  • Fast enough for casual sharing

What people usually complain about:

  • Device not detected
  • Transfer dies midway
  • Folder send fails for vague reasons
  • Can’t find received file afterward
  • Works one day, breaks the next on the same network

So the pattern is pretty clear: great for quick, casual sends, less trusted for repeat bulk transfer workflows.

If someone is just tossing a PDF or a few photos around the house, LocalSend is usually fine. If they’re regularly moving giant Android media batches to a Mac, I’d personally stop fighting Wi-Fi and use MacDroid instead.

MacDroid pros

  • USB is generally more stable than local wireless discovery
  • Finder integration is easier for drag-and-drop bulk file handling
  • Better fit for repeated Android to Mac transfers

MacDroid cons

  • Mac only, so it is not the same cross-platform solution
  • Needs a cable, which some people specifically want to avoid
  • Less convenient for quick phone-to-phone sharing

So yeah, LocalSend’s reputation makes sense. The praise is real, but so are the complaints. It is not usually “bad,” just very dependent on network conditions and OS behavior in ways normal users cannot easily diagnose.