Linked by Thom Holwerda on Wed 30th Apr 2014 19:09 UTC
Apple

I deeply, truly, desperately want Apple to add a Files app and DocumentPicker controller to the iPhone and iPad in iOS 8. I've wanted it going on 4 years, and every year more than the last. It is, in my very humble opinion, one of the biggest, most frustrating holes remaining on Apple's mobile operating system, and all the more so because it seems like a model for fixing it has been in successful use for years already. Right now we're saddled with the complexity and frustration of iOS documents locked in app and iCloud jails. We're driven to outdated filesystems like Dropbox because Apple hasn't yet provided a next generation alternative. It needs to happen and so I'm once again asking for it this year and for iOS 8.

iOS has many complexity-inducing frustrations born out of "keep it simple", but none as big as this one. File handling on iOS is so incredibly frustrating and needlessly complex that I have a hard time considering it a mature operating system at all. My line of work requires constant opening and closing of a quarter metric frickton of files, and that kind of stuff is simply impossible on iOS.

Thread beginning with comment 587833
To view parent comment, click here.
To read all comments associated with this story, please click here.
brion
Member since:
2010-11-04

I wouldn't expect a totally generic Unix filesystem browser (though I'm sure you can get them for jailbroken iOS) -- but there are a few possible 'middle road's.

* iOS already has a document-management model that uses iTunes on the desktop as a manager: each application that supports file transfers basically has a subfolder, lists its supported types, and says "you can drop files in and out of here". In theory, a system app could provide a similar view in a Files.app with no changes to the data model, and allow deleting files, transferring files to/from online services or between apps, etc without having to hook up to iTunes.

* Windows Store apps on Windows 8/RT/Phone have a similar sandboxed model, but there are specific extension points in the OS that allow an application to serve as a provider for the standard in-app file picker, both for loading and saving. Whether they literally use the filesystem, a database, or an online sync service to do it is up to the app and abstracted away.

* Over in another thread somebody mentioned document providers on newer versions of Android -- https://developer.android.com/guide/topics/providers/document-provid... -- offhand this seems to fall in this spectrum as well.

In theory it should be possible to create an interface for opening files belonging to another app... and for instance letting the Dropbox app handle *all dropbox files* might be a lot nicer than every app having its own half-assed Dropbox support with no central point of management.

Reply Parent Score: 2

galvanash Member since:
2006-01-25

I wouldn't expect a totally generic Unix filesystem browser (though I'm sure you can get them for jailbroken iOS) -- but there are a few possible 'middle road's.


Oh sure, no doubt. Im not saying it is an intractable problem - its not. But most of the posts here in the past concerning this issue advocate for "generic Unix filesystem" type of solution - ignoring the fact that this is an application centric OS that was simply not intended to work that way.

The kind of solution I would like to see from Apple would be something like this:

1. They offer a versioned filesystem as a service in iCloud (think time machine but with the repository in their cloud service).
2. They write a simple time machine type iOS application to allow users to restore their "files" from a point in time backup quickly and simply.
3. The iOS device essentially has user level "document" folder that synchronizes with this service - all changes are automatically snap-shotted locally (just like time machine) - but importantly the change sets are pushed into the cloud when connectivity is available. That way you only need to keep x amount of history on the device - older stuff gets relegated to cloud storage and removed locally so storage requirements don't spiral out of control.
4. They create a new class of applications that can register to handle specific file types (and allow developers to register new file types). These apps would store their files in this centralized repository. You keep the existing app paradigm for apps that don't want/need to share data - but developers would have the option to go this route where they think it makes sense.

Why? Because this kind of solution avoids all the "do you want to allow this app to do that?" kind of tedium. It forgoes security for recoverability. Its still sandboxed, but its a shared sandbox and it is easy to recovery it to any previous state so users (and Apple) don't have to be so concerned about a rogue app wrecking things.

No bugging users to give permission for things to happen - apps would inherently have full read/write to this central document store. The key is giving users the ability to recover to any previous state easily.

No "file picker" necessary. If the app is registered to see a certain file type(s), it sees those files and can work with them. The app can decide how to present its UI to work with those files (just like it does now). It would be almost completely transparent to users AND developers. The key is to make it easily (and I mean really easily) recoverable - then you no longer really need the obsess with a byzantine security model. You could of course give users the ability to hide certain file types from certain apps if they wanted to - but I think it is extremely important to have the default be "everything can read/write all the file types it registers for" so that the whole simple by default ethos are maintained.

Reply Parent Score: 4

tidux Member since:
2011-08-13

> this is an application centric OS that was simply not intended to work that way.

The hell it's not. iOS is Darwin, the same underlying base as OS X, with a new coat of paint.

Edited 2014-05-01 09:39 UTC

Reply Parent Score: 2