On your iPad, point to where your latest video file is. Show me. Where is it? "On The Cloud"? On the iPad itself? Three clicks deep in some random purpose-specific app separate from the soundtrack file you want to integrate into the video? What about five years from now, can you still access that video however and whenever and wherever you please?

Why do you care where the 'file' is? That's an implementation detail. I can copy the video to somewhere else any time I want. I do this all the time with photos and videos from my iPad. It's not the issue you're saying it is.

I know people who are not able to properly manage their own files [no quotation marks needed]. They have copies of files here, there, and everywhere else and when asked which copy of the photograph they edited to their perfection they cannot tell you if it was the local copy, the cloud copy, the copy on the shared folder, the copy through that special app wherever that is... nevermind asking them about the concept of having backups.

Simple point-and-show-me information saves you an organizational migraine.

As it stands, if it’s in the cloud and not on your device there’s an indicator. Try to open it and it downloads. Edit it and the changes get synced back up. Unless something is edited in multiple places while offline, or someone takes your lead and tries to manually manage copying stuff back and forth, there’s no different local copy and cloud copy.

When you start talking about like, starting to edit it, well with video that’s not really how things work. If you tweak the contrast of a photo sure today’s devices abstract that in-place, but assembling multiple media into something that, if not re-encoded is at least re-muxed, why would you assume it to be “the same” file?

Should the audio track be automatically wiped, since it’s now been incorporated into the other file? That makes no sense, and I don’t see how an iOS device treats source material differently.

There are whole categories of stuff you can't do with this approach, because every application now becomes a minimal file manager itself, just to avoid the "confusing" idea that data can live independently from applications.

Imagine if you edited a photo in Photoshop and could only access that edited photo through "Photoshop Live" or some-such.

File management in the wild is dirty. Either "there is only one" or there is the Clone Wars.

This is real. For anecdotal example, a family member had this issue with Picasa [before it was purchased by Google]. "I rotated and cropped thousands of my pictures, but when I look at them in my 'Pictures' folder my edits aren't there. Where are my edits? Why aren't my edits in Picasa in my 'Pictures' folder pictures?"

I'm ok being called a pedantic purist on this type of thing. If you want my help, I need to know what you are talking about. Show me your file. If all I am possibly able to see is not what you want, one of us is in trouble.

So you export the edited version, explicitly overwriting your original. Consumer apps don't care when an "edit" means fresh destructive encoding and overwrite, tools like Photoshop do, but that seems a different discussion. I suppose I'm getting hung up on not at all getting/agreeing with your examples.

For "regular" files where that project/"edit in progress" distinction doesn't apply (text/code for example), whether edit-in-place is accomplished through system file manager or back and forth across apps through piping and callbacks is just an implementation and workflow detail.

I rarely leave the terminal on my laptop, and prefer my stuff always backed up, so that probably what has me predisposed towards the "traditional" iOS cloud storage and x-callback-url approach to working with files and data across apps and gluing them together. It just mirrors nicely.

I get that others have different tastes. But what exactly are yours? Files is confusing because there's also camera roll and the difference between On my device and iCloud isn't clear or something?

Same for grandparent, just makes little sense in the context of like, iOS 8, close to none for 13.

PSD files can be read by other applications. Not perfectly, but can. Many other proprietary formats have been reversed or opened to the point that other applications can read or edit them. And then there's a whole set of formats that aren't tied to any application per se. No app owns JPG, PNG, WAV or CSV.

> whether edit-in-place is accomplished through system file manager or back and forth across apps through piping and callbacks is just an implementation and workflow detail.

It's not an implementation detail. The "back and forth across apps through piping and callbacks" is under control of the app developers, and the extent to which it works depends on the contractual deals they sign between each other. A file system is an universal intermediary layer owned by no one, which maximizes interoperability and doesn't require the user to maintain or be aware of relationships between app vendors.

(Or, look at it from a software design point of view. If you were presented with large and potentially dynamic network of components exchanging data through APIs, you might actually come up with a file system equivalent as a way of separating concerns and maximizing composability.)

> the difference between On my device and iCloud isn't clear or something

That would be an important difference to have. Basically, "I'm on a train and Internet is spotty, or my ISP has an outage, will I be able to open and work on this file or not?" is a question for which the answer is kind of critical. The Internet is not electricity, it's not always available.

But why do you think apps own CSV any more in Files than in Finder? That's where a lot of my confusion stems.

Your view of x-callback seems off too, it's a way for apps to expose functionality in a generic way, so the opposite from being dependent on the relationship between any specific app vendors. Since there are many apps that let you glue together stuff yourself (and Apple provides one).

> Basically, "I'm on a train and Internet is spotty, or my ISP has an outage, will I be able to open and work on this file or not?"

Anything on the local file system is obviously always available. For iCloud there's that status icon I referred to in my first post, but that's no different from desktop.

It's very practical. I know we're talking Apple now, but to give an example of a thing that happened to me last week: I couldn't send my wife a PDF with transaction details via e-mail "on the go", from my Android phone, because there was no chain of sharing that would link my bank's app and Fastmail. I could open (not save, just open) a PDF from the bank app, and I could share it, but under sharing there was nothing that would allow me to save it to the filesystem, and Fastmail app didn't show up on the list either. This could be fixed on either app's end, but a better fix would be for the OS to just provide the "Save to filesystem" share target for everything.

> Your view of x-callback seems off too

Likely - I had very limited experience with iOS (briefly worked with an iPhone that was recent some 3 years ago). It sounds like something similar to Android's intents system. If so, that's a bit better, but if Android's experience is to go by, a lot of linking you'd expect to work doesn't, either because of misconfiguration or purposeful prevention.

> Anything on the local file system is obviously always available. For iCloud there's that status icon I referred to in my first post, but that's no different from desktop.

Sure, but there are voices calling for making cloud and local completely transparent; I'm strongly against that on the grounds I described.

BUT prior workaround was as simple as a basic Workflow share action accepting any input then giving a list of options - Dropbox/Drive, push to desktop over SSH, try "open with" (? can't remember) which for some reason would have a slightly different list of targets... So, file manager is good, obviously, but you weren't crippled before it.

Putting blinders on a horse allows the horse to behave for the driver. I want the horse to behave like a horse.