You also ONLY need Android File Transfer on Macs because Apple is too shit to implement MTP and wants to cripple non-Apple devices. On Windows/Linux/BSD you just plug in your android device and it works. A lot of devices support USB 3 speeds too so transferring is fast and not miserable unlike most iPhones and iPads.
They also have a Nearby Share app for Windows that lets you use Nearby Share on Windows. Would be nice if there was a Linux version.
Hey, if you don't mind a question...I need to help a friend back up all the photos off an Android phone and have had a lot of difficulty doing it on my Mac for the reasons you've stated. I do have a Windows notebook at work, are you saying if I plug the Android phone into a ThinkPad, it will just show up like a drive and let me copy photos?
It's critical that the photos (thousands of them) keep their original EXIF data and filesystem dates, and the methods I've found to get them onto my Mac don't accomplish this.
I'm not who you asked, but yes this is correct. If the photos are from the phone's camera they will be in the DCIM folder. There is also a Pictures folder that stores photos downloaded from other apps. At least, that is how my Pixel Fold is.
HN may dislike it because it's an old protocol and it's more reliable than the newest crap today's developers are promoting, but I like PrimitiveFTP for this task. The .apk file is available at f-droid.org. MacOS should have tnftp(1) which is a preferred program of mine. Type ftp -h on the Mac to check.
The entire process can be scripted according to preference.
There are many way to do it. The following should work
Put phone and laptop on same network
For example,
192.168.1.1 is gateway
192.168.1.8 is phone
192.168.1.9 is laptop
Start PrimitiveFTP on the phone
On the laptop use tnftp to retrieve the photos
# get list of the photos, where PrimitiveFTP has been set to use port 2121
echo ls DCIM/Camera|ftp -P2121 ftp://192.168.1.8 > photos.txt
# get the 1st 100 photos
(echo cd DCIM/Camera;sed 's/.* //;s/^/get /;100q' photos.txt )|ftp -P2121 ftp://192.168.1.8
# get all photos created/modified in 2023
(echo cd DCIM/Camera;sed 's/.* //;/2023/s/^/get /' photos.txt )|ftp -P2121 ftp://192.168.1.8
For avoidance of doubt, 192.168.1.x in the example means a network that user set up, using a router chosen by user, running OS that user compiled from source. It does not mean a network open to the public, or someone else's network. Apps like "Airdrop" and other "secure" file transfer apps seem to encourage use on other people's networks, and many of them require an internet connection, and often use third party servers by default. In the example, neither phone nor laptop has an internet connection, only a connection to the router that user controls. The router does not have an internet connection either. (Compare using Wi-Fi Direct via a closed source app from Apple.)
Best solution: Do not take photos with a "phone". Use a "camera".
The biggest valid concern about FTP is that it’s not encrypted. If you access files through any network that’s being even casually monitored, the monitor gets access to the username and password for you phone’s FTP server.
In my experience, a lot of security-related pushback on HN specifically is because many of us have seen how easy it is to forget that not everyone knows to be careful or how.
The best way I have found is to create a SMB network folder on your local wifi network (you can do this in Windows and Mac, its usually the default folder share method in the OS, or you can use a NAS) and then use TotalCommander to move the entire Android filesystem (or just the DCIM folder) to that network folder in one go. It took me about an hour to transfer ~128 GB over wifi.
Do not use Android File Transfer (its a horrible app that transfers in a weird slow serial mode over a wired connection). Do not use Pairdrop/snapdrop/etc. Those Airdrop clones do not handle big folders of files well.
If you have Windows available, ignore my advice and do that. It probably isn't as difficult as Mac.
The best way to transfer files reliably off an Android device has always been an FTP server app on the phone in my experience. MTP can be really buggy with big files and it can be tough to reliably resume interrupted transfers.
A license covers "1 Mac OS device" - what about PC?
Also, what happens once 1 year is up? Any upgrade discounts? Is old version still downloadable?
Anyway, good job, I was in need of something like this recently and used LocalSend https://github.com/localsend/localsend , any notable differences between it and you app?
Not the OP, I've used LocalSend successfully (Mac and Android phone), it's great when it works but every now and then it's unable to find my phone to send stuff to.
Still no automatic and seamless WiFi ad-hoc network creation for fast offline file transfer.
Please stop claiming to be an "AirDrop for Android" if you can't implement this.
Also Samsung's QuickShare and Google's NearbyShare not only have gotten a lot better but are merging together and being incorporated into Windows and elsewhere
Surprised no-one mentioned https://syncthing.net/ yet. That would seem to be the main competitor for such an app. Still, perhaps there's a market for something a little more user friendly and streamlined. Nice work!
To be fair, the developers of Syncthing have been explicit that Syncthing is not intended to be a file transfer application, and that you should avoid doing so. Syncthing is designed to keep two folders on separate devices in sync at all times.
That said, I have used it at times to "transfer" a single file that I copy paste elsewhere and then delete from the sync folder. Sorry Syncthing devs..
I have my Android and laptop running Syncthing with the Android end read write so when I move the files out of the receiving directory on the laptop it is automatically deleted on the Android device. No need for separate copy and delet, just move.
Thanks, I've been emailing myself photos in Gmail 5-6 at a time like a caveman for the past several years... any app I tried was a non-cross-platform disaster or cost too much and had major feature bloat. This looks dead simple.
What sucks is that there's no foolproof way to make sure it keeps running. Not so much of an issue for a techie, but I tried to use it so my mom's photos keep getting backed up, and I have to remind her at least once a month to start it again. And that's despite having all the energy saving stuff disabled for the app, and having Autostart allowed. I don't know whether there's still some heuristic to kill apps that run in the background and haven't been interacted with in X days or something.
And then, at least on my phone, it rarely seems to goof up when the app starts the actual syncthing process. Syncthing-fork then just keeps showing "syncthing is starting up" on the status page and the battery drains quickly. It's still the best solution imo to have your photos reliably get backed up no matter where on this planet you are without resorting to Google/$PHONE_MANUFACTURER Cloud.
That's unusual if that's the case, in my experience. I rely on syncthing to keep my notes synced between devices/applications (and photos) and using "run according to time schedule" for "5 minutes" has never produced a problem for me, through reboot and months between opening the app sometimes.
Just plugging tour phone in (eg. with the charging cable) will do the trick, though on Apple-hardware, you'll need to install OpenMTP (https://github.com/ganeshrvel/openmtp) or somesuch.
If you meant more freely aharing than that: apologies, misunderstood. But isn't that the problem Dropbox solved?
Fellow caveman here. That's the way I've been doing it for years also, haha. Just tried Sharedrop.io mentioned in another post on HN and it works great if your phone and computer are on the same network (make sure your VPN is off if you have one).
It's not an Airdrop competitor if it doesn't even meet the basic requirement of Airdrop - to be able to arbitrarily send a file to someone without being on the same network.
I understand that, and LocalSend looks great for what it does. But AirDrop is so insanely useful to many of us because it allows us to share a large file with a person, regardless of whether we are on the same network or whether there is a network at all. If you need that and you can't, it's quite frustrating.
The original post was about being an AirDrop alternative, which it really wasn't.
> Sending files via a messaging apps can be a security risk, as you are sharing your files with the messaging app first and then to your other devices. You cannot tell what those companies can do with your data, such as keep a copy of them, modify or sell them.
Why would I trust Ubidrop more than I trust messengers?
Interesting timing, just yesterday I was looking for solutions for file transfer between android and windows. My main issue is how android presents as a very limited mtp device (i think?). Microsoft's phone link works, but only when opening a scrcpy-like screen with the android file manager. Very weird.
If possible I wanted to actually mount the device as a drive. I stumbled upon sshfs-win[0] which mounts sftp shares as drives. Couple that with prim-ftpd[1] and voilà: android mounts as a drive. Tailscale[2] can also make it fairly lan-independent.
Primitive ftpd supposedly starts on boot and keeps running but I found it stopping inconsistently at times, requiring a restart. Still, I'm quite satisfied. I suppose dav could work as well, but no apps popped up on fdroid.
It boggles my mind that the easiest way to send a picture from my phone to a notebook sitting next to it is to bounce it over servers on the other side of the world trough whatsapp/mail instead of some kind of 2 second discovery/highest speed negotiation/transfer over whatever hardware/protocol those devices dynamically agree upon..
For a Show HN thread it is oddly devoid of OP's participation. Combined with the dated nature of the material, it looks a low-effort promo rather a genuine attempt to share one's work.
I used to carry around an old phone running Pirate Box. Sometimes people would connect to it at coffee shops and put interesting things on there. That's how I found out about the band Death Grips!
I have a project that's more like AirDrop, doesn't require a local network and configures the hotspot automatically: https://github.com/spieglt/flyingcarpet
> windows 11 now has nearby devices in the share-sheet
That sounds great, but after reading this...
> you can share over Wi-Fi if the Windows 10/11 PC you’re sharing to is connected to the same private Wi-Fi network. Otherwise, *you can share over Bluetooth.*
(emphasis mine)
Bluetooth file sharing is one of the most frustrating, painfully slow experiences (on Windows, at least), to date. It frequently randomly disconnects, all while taking hours to transfer small files. Nobody ever uses this, or if they do, they don't want to.
I'm surprised file sharing is so bad when so many breakthroughs
have been made in Bluetooth, and wireless networking tech in general.
It seems wrong that we're now on WiFi 6E, and this is still a thing.
P.S. Is the protocol for Nearby Sharing public? It would be a great shame to lock this behind Windows -- it could be a very good solution in the end.
When using Apple devices I often feel like ordinary people sat down and said "I wish I could do X", and so Apple make that work, and they make it insanely easy to do.
AirDrop, syncing stuff, backups, auto adjust volume for headphones, no screen flicker on startup, trackpad that freaking works, etc.
When I use Windows, I feel like a committee decided something over a long period of time, and it is as convoluted and painful as the many decision makers could make it.
I feel like Apple sat down and said "how can we make sure this NEVER works unless you're only using Apple devices?" and intentionally sabotaged open standards.
The last time I had to do this between two Android devices I just used wifi direct and it worked flawlessly. And yet Apple doesn't support WiFi direct? I can't explain Windows, but the fact that iOS won't interoperate with Android seems like an intentional choice by Apple to make their customers' lives harder.
> The last time I had to do this between two Android devices I just used wifi direct and it worked flawlessly
And you had to disconnect each device from the wifi they were using, separately.. and you couldn't use the internet during the transfer. That's a no from me.
I've needed to transfer files between an iOS device and an Android device pretty regularly lately and it's simply impossible, I've literally been waiting months to transfer a few files because the person who has the files has an iPhone and has difficulty using any method other than Airdrop (e.g. Dropbox.) Which I view to be an intentional design decision by Apple. WiFi direct would be fine, Airdrop is proprietary and useless here.
I dunno, I use Bluetooth to send files regularly, and it seems alright. The only reason I do this is because it doesn't really require anything particularly special, though it's not particularly fast.
Other than that, there's so many ways to send files that it's hard to pick one as an obvious "best" way to go. However, for something that is reasonably versatile and noob friendly, I pick Wormhole.app. Anything with a modern web browser can use Wormhole.app just fine. I can't speak to how much good its 'end-to-end encryption' is, but it does seem like it mixes some of the best of all worlds for point-to-point file sharing, allowing direct connections but also allowing temporary storage in the someone-else's-computer too.
Of course, will Wormhole.app be around in 10 years? Dunno. I also frequently use Tailscale, rsync, SMB shares, etc. for different purposes. Of course this is only fair as sometimes I'm sending files for different reasons, and I would never use Airdrop to do all of those things, so it's not like it's fair to say the fact that I don't use one solution is an indication that there is some big failure.
Airdrop is indeed convenient, but it being hard to audit does make me a little nervous about stuff like that. There's a lot of reason to be at least a little cautious[1]. Of course, there's no single alternative that is installed by default, has a better track record and more auditability, so I think it's hard to just say that this nullifies any benefits of Airdrop.
It is indeed a bit madness that there are so many options and none of them are the "obvious" right way to go. I think this is a problem that can and will be solved eventually though. Miracast is slowly solving the problem of having a "remote" display as I effortlessly can cast my Linux desktop to a random Samsung TV just by being in close proximity; We basically need a lot of parties to agree to something like that but for point-to-point file sharing.
It's probable that security concerns, though, are indeed one of the main reasons why this continues to be difficult.
Nope! Like I said, I often just use Bluetooth to send files. That requires neither an app nor a visit to a website.
I am really miffed that this is your exact takeaway from what I said. I gave you a way that someone can do this:
* I have a file on a device I own.
* I wish to send it to another device.
* I send it.
Yes, it is in fact just as easy to do this via Wormhole.app as it is Airdrop, except it also works across the Internet when not in close proximity.
The problem here is mainly 1. Wormhole.app is just some website some entity runs, not a standard. We should have a good standard specifically for point-to-point sharing, and 2. It's not integrated into the OS. It's just as easy to pop open Safari and go to Wormhole.app as it is to go to the Share menu and select an Airdrop target, but one is vastly easier to discover than the other.
However, what you said was that you think it's "crazy" you can't just share a file between two devices. You in fact can, easily, without downloading random apps, in numerous ways, from Bluetooth to websites using WebRTC like this one. The Bluetooth one even has pretty good discoverability on Android as I would typically just use the share menu.
I will admit that it is unfortunate that there is no "obvious" solution but that's kind of how the ecosystem works outside of Apple. A lot of things will compete on solving a given problem before we actually get an answer that everyone agrees on. This has its pros and cons, and one of the definite cons is that not everyone is sure what to do. But it's weird to point at this and say "Look! You can't even send files between devices easily!" Yes I can. Lack of a single standard solution does not make it significantly harder, even when doing it between me and some random person that may use a different kind of device than I do.
FTP was created 52 years ago. SFTP[0] Has been around for nearly 30. The latter is usually how I transfer files between two machines that I can connect to each other.
So your story is that when I turn up to a new university and want to send my powerpoint to their computer, I just call the support staff and tell them "install mDNS and a GUI"?
If the computers don't already have mDNS and a GUI, they should start with installing an OS shipped in the last 20 years, yes.
My point is that the technology to do this is already everywhere. People who control the software that runs on most computers would rather it be less convenient so they can push their own "solutions" to the "problem" though. Airdrop is a pinnacle example of this.
+1 for KDEConnect, it's a great piece of software.
The other day I figured out my last problem with it: My phone was coupled with my laptop and desktop computer, but desktop and laptop were not coupled to each other. This lead to awkward behaviour, when all three devices were turned on.
For one reason or another I never thought about changing that, but coupling desktop and laptop fixed all problems I had occasionally with kdeconnect.
Am I missing something? The submission under which you posted this comment literally solves the problem you're complaining about, and directly contradicts the claim "you still have to be on Apple" for this experience.
That's a feature, not a bug. Why should I have to be locked in to a proprietary file sharing mechanism that my device manufacturer unilaterally declares I must use?
To have 37 different implementations to achieve this, might be a feature. To have 37 different protocols surely is not.
There should preferably be one open protocol for proximity based wireless ad-hoc file sharing. This protocol can then be implemented by operating systems and/or userland implementations
Yeah! I'm not praising Apple here! Maybe they refuse to let non-Apple devices interoperate, and it's their fault. I'm just saying that the rest of the world absolutely has not got it together.
If price is your main concern here, recommending switching to Apple seems completely unhinged. Don't get me wrong, Apple has a lot of advantages, but price is absolutely not one of them.
This never worked for me somehow, but would love alternatives for Airdrop, it’s so buggy and the interface is horrible if you have more then 3 devices in your neighbourhood
Oof! A very cool thing, solving a real problem I have, but if you're taking feedback on pricing: I could never justify paying for local filesharing.
I've been this close to building my own version of something like this, multiple times over (and actually built a browser-based one as a way to learn .net core when that first started), because - like I said - it's a really handy utility.
But I could only justify paying for something premium, like wide area sharing or torrent-like sharing for faster and resumable transfers. To get a file from one device to another can be cumbersome, for sure. But a cable and and an adapter would cost less than your solution, and have benefits (and drawbacks!) of its own. So I just couldn't figure a subscription* for something that, in the worst case, is a tedious pain to set up myself and in the most practical case is replaced by a simple, if cumbersome, process. Maybe others are doing different calculus on this (everyone has their own threshold for 'too much hassle' or 'not accessible enough'), but it's a pass from me without free local sharing.
*not sure what's 'free updates for a year' would mean other than "you will need to pay another $19, to continue receiving updates" which is a subscription, by my definition.
The chase for subscription revenue is destroying a lot of potentially-great software. Not just in pricing structure, but in how software is designed in the first place.
Compare this to something like Magnet, which is great software that I use almost every time I turn on my wife’s MacBook and costs $2. Once.
My guess is the people who made Magnet just aren’t getting rich off of it, but maybe we shouldn’t expect to get wildly rich from making a useful utility.
> The chase for subscription revenue is destroying a lot of potentially-great software.
Phone OSes aren't nearly as well-optimized for backwards compatibility. Speaking as someone who works in this field, your phone app is almost never "done." Once you hit publish, you're signing up to continue providing updates for the life of the product. I've got binaries from the 90's that will run on Windows 11, no issues. But apps? Forget it, we just had to publish an update to a racing application for Android for literally no other reason than the binary was old and google said so, or we'd lose our Play store listing until we did.
And in the process of doing that, while changing basically nothing you actually use as a user of that app, we had to update several permissions-seeking dialogs to be compatible with newer versions of Android, along with some changes to how we share files. You might notice the second one if you look hard. That took one of our developers about 4 days of work, and a fair amount of testing after that.
Like, you can hate the game, I certainly do, but the way both Apple and Google go about arbitrarily changing and updating the OS, you just have to update your apps, which takes labor and time. And we have no mechanism to gate updates behind price tags. So like, I get the frustration, I really do and I share it a lot of the time. But I also understand the economics at play here and I won't ask someone to work for free for me.
Part of this is that it’s only been recently that mobile OSes have started to approach a similar level of maturity as their desktop counterparts, while also introducing and developing new concepts that desktop OSes never had (like permissions). For some number of years a high level of churn was inevitable.
As for the, “binary too old” thing on the Play store that could be a low effort way of weeding out apps with security vulnerabilities due to old dependencies. There isn’t really an equivalent on Windows for this because it doesn’t have any kind of centralized, hosted app management (at least that people actually use). It’s not uncommon for maintainers of Linux package manager repos to remove “abandoned” (as in hasn’t received any updates in X time) packages for similar reasons, leaving users who want them to source them elsewhere.
How demanding/complex upkeep is may be a big factor here.
For something like a single platform utility, the burden is relatively low because the number of things that can break is bounded (as long as public APIs are used, private API usage is another matter). With a Mac app like Magnet there’s one time each year chance of breakages occurring is high (new OS release), which devs are given several months ahead of time to find and fix.
Multiplatform apps obviously multiply that burden, with some platforms being more problematic than others — e.g. Android phones sometimes have weird per-device-model quirks that apps need to work around, which is not something one typically sees on Windows PCs, iPhones, or Macs.
Anything with an online/server component unavoidably needs to be babysat to keep running and secure, and the more functional that component is and the more surface it has exposed the more vigilant one needs to be. There’s also hosting costs, which can be quite high in the case of an independent dev who relies on cloud services to make up for lack of resources.
Which is all to say that it makes sense that a Mac-only tiny utility could more sustainably be a cheap one time purchase than many other types of project could be.
> Multiplatform apps obviously multiply that burden
They also multiply the number of potential customers, so I don’t see that being a problem.
> with some platforms being more problematic than others
That _is_ part of the problem. As a developer, you have to compare your programming effort with expected revenues, so if a platform is “more problematic”, you’d only develop for it if you expected to get more revenue from it (either by getting more customers, by getting each customer to pay more for the product, or, sometimes, by getting more revenues on other platforms because you also support this one)
> They also multiply the number of potential customers, so I don’t see that being a problem.
This is something I believe requires some research, because each platform is a bit of a different market. Point in case, the market for Magnet exists only because macOS has no Aero Snap type system built into its window management — a utility like it probably wouldn’t sell enough copies to justify Windows or Linux ports.
There’s plenty of software where multiplatform makes sense, but it’s not certainly not universal.
I love Magnet and also paid for it. Coming from Linux to Mac, I _rarely_ pay for any kind of utility .. but I did here. Maybe that says something in itself.
Subscriptions for desktop software sucks; but I can deal with yearly licenses .. assuming the app is maintained, you have a chance to actively consider the value you're getting before renewal. A subscription feels far more passive.
I resonate with this. I can even stomach the JetBrains subscription if I rationalize that this is the equivalent for paying again for e.g. the 2024 edition. And they are good about letting you continue to use the software as of your last paid update.
I can’t rationalize paying monthly or even annually for something I expect to continue working exactly the same. Continued development on something like that almost guarantees it’s going to eventually change in a way I don’t want it to, anyway.
Edit: except in the cases where the monthly subscription is paying for supporting infrastructure, of course. That’s easy to rationalize.
> except in the cases where the monthly subscription is paying for supporting infrastructure
How do you feel about cases where there is supporting infrastructure, but that infrastructure is artificial and just designed to allow subscription fees?
Also, there's snapdrop[1] that does almost the same thing, for free, without the need to install anything. It'd probably be wiser that snapdrop were a native application; then it's dev would not need to pay to host the client application anywhere.
I would pay 100$ for parts and spend hours setting something up if it meant avoiding a subscription, ANY subscription. Ive spent as much on SDR equipment so i can read aircraft ads-b signals, something availible better and free on a variety of websites. Thats what being a nerd means.
Doesn't qualify as a "Show HN" - it's already been posted twice in the past few years and there's been no updates for more than a year [0]. Sounds like an attempt to get a few clicks by labelling it as "Show HN".
Previous posts only count if the post has had significant discussion which this one doesn't appear to have had in the last year. If you think there's something else wrong with the submission just email the mods.
That is what flags are for, it's just that the post was a valid Show HN and accusations like 'doing it for clicks' belong in flags and emails to to moderators and not in the thread.
KDE Connect has been around for at least 5 years : https://apps.kde.org/kdeconnect/ . It is quiet amazing and does way more than only file transfert : clipboard sharing, multimedia control, ping, messages, remote keyboard/mouse, etc.
> KDE Connect has been around for at least 5 years : https://apps.kde.org/kdeconnect/ . It is quiet amazing and does way more than only file transfert : clipboard sharing, multimedia control, ping, messages, remote keyboard/mouse, etc.
I also love KDE Connect; the clipboard sharing is so unobtrusive it feels almost magical. It takes less effort to copy and paste across my devices than it does between only Emacs and Vi on my desktop!
It seems to be not yet possible to share entire folders with KDE Connect, so I use Syncthing for that, which is also polished in its own, somewhat different way (more technical to use but optimised for large amounts of data).
>It seems to be not yet possible to share entire folders with KDE Connect
KDE Connect expects you to mount the phone's directory to transfer folders, a decision I will never understand. You can use globbing to send every file in a folder though.
I tried to use it with my linux laptop but it didn't work. It assumes you're in the same wifi and that the usual broadcasting works, right? This is not what airdrop does.
Airdrop is fast and works by physical proximity. You don't need to be in the same wifi, just near each other. That's what makes it so useful, otherwise I could just use a cloud solutions as I usually have internet access when I'm in a wifi.
When I see comments like this one, I think that we should do Show HN posts like: 'I intend to build an app Airdrop-for-Android, what are the most important features' ;-)
It feels like very often when I see a Show HN project, the HN comments point out some critical missing feature.
KDE Connect has definetly made my life easier in school. I could just photo scan files with my phone and drop them on my 2in1 for editing. KDE Connect does require all devices to be in the same network, however, for which I needed to create a hotspot to get that "just works" feel
I think that's a bit harsh - most of the comments here (including my own) are discussing existing file transfer methods, so it's hardly an abject advertisement. Show HN posts typically get more attention than regular posts anyway.
> Why not use Android file transfer?
> Android File Transfer is Google's tool for transferring files from your Android to your desktop.
> The tool has not been updated in a long time and feels dated.
> Also, it is 2022 and the future is wireless.
It's not 2022 anymore, and Google just released an update to their Nearby share called Quick share. Or rather, they're adopting Samsung's Quick share.
https://www.cnet.com/tech/mobile/google-is-adding-samsungs-q...