Bluetooth can work, but it is slow as hell, and Apple doesn't support it.

Cloud services are convenient, but you not only you need some signal, but you also uses up your data plan.

If you have USB OTG support, you can simply use a thumb drive, like with your PC, but it is cumbersome and you need the hardware.

There are some somewhat proprietary systems like QuickShare and AirDrop, which are supposed are great when you have support which is not always the case.

Other options include having one phone act as a WiFi AP and host a local HTTP server, there are apps for that (ex: MiXplorer). A bit uncommon, but the advantage is that only one phone needs to do weird stuff, for the other, it is just downloading from a URL.

There are also apps like SyncThing based on P2P networks.

Generally, phones are pretty terrible at dealing with files. Their OS is designed around apps controlling their data rather than around interchangeable files like traditional desktop OSes. The way they want you to work is not by exchanging .gpx files but instead by using some built-in "share" feature of your hiking app. It may be .gpx under the hood, but they don't want the end user to see a file.

But localsend has worked well for me. Yes, it requires an app but if we could get vendors to bundle that rather than a boatload of bloatware.

I know that it would be to optimistic to hope for Google.

See https://localsend.org/

Spread the word.

That's a clearcut case of absolutely willful trademark infringement, and it will not go well for the authors when (not if) Apple happens to cast their gaze in that direction.

Wait, seriously? iPhones still don't support Bluetooth file transfers? I knew this was the case with the first iPhone but I just accepted that's a limitation from the OS being still an early release of a brand new product with limited functionality, I wouldn't have expect this to be the case after 15 years.

Anyway, I'm still baffled we never got a standardized Wi-Fi file transfer protocol, like with Bluetooth but at wi-fi speeds.

Oh right, nevermind, Apple wouldn't have supported anyway versus their own proprietary one that only works on Apple devices.

(If you're talking iphone to Android, nvm)

It's pretty shocking that we don't have a dead-simple cross-platform "send a file to someone over the Internet" solution that doesn't involve cloud servers and accounts and downloading apps.

Back in the old days, we would have used PKZIP or RAR to split the file into smaller pieces.

>ftp is too big a technical hurdle for the guy

Back in the old days, even a secretary could figure out how to use the MS-DOS command line well enough to get her job done. I'm not sure what happened between then and now, but these days people just say "I'm non-technical" and refuse to learn anything that doesn't involve a GUI. FTP isn't hard, it's just a few commands, and it's much easier to tell someone how to send FTP than to use any GUI, since you can type out the exact commands to use:

1. ftp [ip address] 2. type username 3. type password 4. cd dir-to-drop-files 5. put filename 6. quit

These days, we'd use sftp anyway, but you could also use scp in a single command line which they could simply copy-and-paste from an email, after you have their temporary account set up.

Back then there were far fewer non-technical people using email anyway. In my experience people like office admins wouldn't do anything with split archives they would get the local computer person to do it for them (and the same would happen at the receiving end). They were generally aware of zip files, but might get a local tech to compress things for them even if a split archive wasn't needed.

Or they would just send a floppy in the post if the file would fit on there but the email limit at one end or both was less than 1440K. On one occasion because no one was free to help otherwise I remember a secretary driving a floppy between campusesses to deliver updated slides for a talk because she couldn't get it pushed through email (I forget if the biggest blocker was at the sending or receiving end).

Things changed quite a lot when decent GUI zip tools became common, and again when shell-integrated ones arrived in the Win95 era.

Flipping back through time to now, there are two problems that we didn't have back then:

1. Phones don't have particularly good+friendly archivers, and even if one is found security protections might mean said archiver can't access the data it needs from the app that generated it. As well as talking someone through the archiving process you might need to try work out how to open the relevant permissions and describe that to the remote non-technical user too.

2. Often desktop environments are locked down too, and Windows for instance doesn't come out of the box with an archiver, neither CLI nor GUI, that supports multi-volume archives or encryption worth bothering with.

> Back in the old days, even a secretary could figure out how to use the MS-DOS command line well enough to get her job done.

Some would do that, but I wouldn't say they were the majority by quite a margin in my experience. And not just secretaries: higher paid managers & such too. In fact them more so (as they would drop the task on a secretary, who would then enlist the office kid who knew some tech).

> FTP isn't hard, it's just a few commands, and it's much easier to tell someone how to send FTP than to use any GUI, since you can type out the exact commands to use:

The issue with that was (still is) that they will need telling each time. It isn't their job to do these technical things so if they don't have an active interest they aren't going to spend time learning it, so they can work out the exact sequence for next time unless it happens often enough that they learn by repetition. It isn't hard, but it isn't natural or familiar to many. It is only natural to you and I because we do that sort of thing regularly (or have done it enough in the past that it has become wired in).

No, the managers were lazy and insisted on having secretaries print everything out for them, and refused to touch a keyboard.

>In fact them more so (as they would drop the task on a secretary, who would then enlist the office kid who knew some tech).

In my experience in a college, the secretaries could handle their computer-based duties by themselves just fine. They only called for help when they ran into a problem they hadn't encountered yet. But doing basic file management at the MS-DOS command line (this was before Windows) was within their ability.

>The issue with that was (still is) that they will need telling each time.

Yeah, so what? ryandrake above said "I recently had to have a non-technical person send me a very large file, and encountered this", so that's why I countered with this in response to his claim that "ftp is too big a technical hurdle for the guy". It doesn't matter if it isn't natural or familiar; all you have to do is cut-and-paste some simple commands. If you can't do that, you're hopelessly stupid I think. You don't even have to understand the commands! That's my whole point with the utility of a command-line interface in situations like this: you can give someone some explicit commands, and they should be able to follow them exactly, simply by cutting-and-pasting or typing them in. It's not like a GUI interface where you have to try to tell them (perhaps over the phone) exactly where to click, which isn't reliable since you may not be able to exactly duplicate their environment or they might be using a different program or even OS. If you're somehow smart enough to use a computer with a GUI for years (and likely multiple computers: smartphone + PC), but you're too stupid to open a terminal window and cut-and-paste a one-line command, this sounds to me like "willful ignorance".

Anyway, the point is that this is fine for a rare occurrence like this. It doesn't sound like ryandrake has to deal with this problem with this same person on a daily basis.

Available since Android 6 (c.2015)

I've had it be horribly slow, wickedly fast, and also absolutely fail to work at all.

The wickedly fast method seems to involve the two devices forming an ad-hoc WiFi network -- just for themselves. 802.11ac/ax is pretty darned fast when there's no competition, on a network with exactly two nodes, and when those two nodes are separated by only a couple of feet.

IIRC, this is not the default mode of operation.

Otherwise ironical that all of this behaves like the 90s PalmOS which could not store a file unless a program would accept it.

I have a fairly expensive meter at my disposal to use for planning things like this, which analyzes different cellular carriers by frequency, and can output (messy, and with unescaped commas for notes, but eventually-fucking-usable) CSV files of the results -- with GPS coordinates of the measurement location.

This sounds amazing for a person like me in this line of work. But it is not amazing for a person like me in this line of work.

(As a preface for the rest of this, remember: This meter is a tool that is meant to be used in areas of limited or zero cellular coverage -- places where outside RF is problematic for whatever reason.)

1. The meter has a Bluetooth interface that connects to an app on a pocket computer. (This part works fine, usually, except the app often doesn't background properly and silently dies if the user uses their pocket computer to do some other task, which might be fine if the problem was ever reported. [Haha!])

2. The meter expects the pocket computer to have an Internet connection, so it can use that to upload its findings to The Clown. (This part often cannot work, because the whole fucking reason any of this is happening is because cellular coverage is shit inside of a random building.)

3. The meter expects that the pocket computer will provide GPS coordinates, even though it is intended to be able to be used indoors -- without network connectivity, or perhaps even in a Faraday cage. And while modern pocket computers are very good at providing some location data by various means as long as there is internet connectivity or GPS-esque data, all of them fail at this when there is neither Internet nor GPS available. It produces an error [Haha!] when there is no location information available.

4. It does not provide useful errors. It provides errors, but they aren't specific at all and do not promote productive troubleshooting or workflow. ("Oh, there was a problem with your measurement! [Haha!]" is the singular error.)

5. Sometimes, it will even produce an error [Haha!] but record the measurement anyway -- and without recording the error.

6. It stores nothing locally. When an error happens [Haha! Good luck!], it is impossible to quickly see if anything was stored at all, so the only clear path is to repeat measurements that result in an error [Haha!]. This often results in redundant measurements being actually-recorded, but who would know that at the time of measurement. (These measurements often take about 4 minutes each, so these errors [Haha!] and repeated measurements can consume significant portions of an expensive workday.)

7. (Your main point): Exporting a CSV file of [whatever-the-hell was collected] is possible, as long as I want to send it to Google Drive or some other Clown-based service. The CSV is only a few tiny kilobytes at very most, but it won't let me copy the CSV to my pocket-computer's clipboard, or send it in an email, or save it locally on the pocket computer, or send it with Bluetooth to my laptop. It has to be exported to a Clown-based service, and then it can be read from that Clown-based service by some other device. There are no other options presented, unlike in so many other apps in my pocket computer.

8. Continued: While the maker of this meter device has their own Clown, and this Clown is clearly extent on the Internet, this Clown is completely inaccessible outside of their pocket-computer app. I cannot bypass Step 7 by any official means no matter how deep my desktop computing prowess may be.

It is completely shit, and it appears to be the best thing available on the market in this space. (And it isn't even Chinese shit: The company that produces this meter is in Utah.)