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.
I’m thinking there’s a couple distinct use cases here…
1) Pipelining a single document through multiple applications
Here, having a filesystem that’s not tied to the apps allows the freestanding object to be opened and processed in different ways.
Android’s model can potentially work well here, sending data from app to app via Intents until you end up saving back.
iOS’s inter-app communications are pretty limited right now — basically you can send a URL or you can send a file to an app, and that’s it. Smarter communications could be built on top of that perhaps, for two-way communications but it’s kinda ugly.
2) Grouping documents from different applications into a single project
A single work or fun project might include images, text, movies, etc. The iOS model really, *REALLY* doesn’t play nice with this unless you use a monolithic app that handles projects of multiple document types. (So we have word processors and presentation tools that embed images and text into a single document, and you either are limited to what that app can do, or you have to export/import through another app.)
In particular things like archiving and version control are really hard in this model.
As a programmer, most of what I do lives in this world of grouped projects with heterogenous document types and source/edit apps, which is why tablets haven’t been a huge productivity win for me. (They’re great for poking at the web, checking email, games, and occasional video editing or whipping up a skeleton for a presentation… but I can’t code on one!*)
* Actually I’ve played a little with coding with AIDE <https://play.google.com/store/apps/details?id=com.aide.ui> on Android, but it doesn’t handle any of my real-world projects.
Android applications doesn’t need to do that either, they can grant temporary permissions to a file, without sending the data, only the URI [1] or better yet a Storage Access Framework [2]. iOS needs more than the simple sending and data duplication of early Android versions.
[1] http://developer.android.com/training/secure-file-sharing/index.htm…
[2] https://developer.android.com/guide/topics/providers/document-provid…
Edited 2014-04-30 19:51 UTC
Oh nice, I hadn’t encountered those before. Especially the document provider system looks very flexible…
I am a little confused:
How is multiple programs opening a single file different than sending your file through a sequence of applications? Currently, the only part missing is programmers thinking in a cooperative way.
When you group different type of files to form a meta document, it is more natural to treat the group as a single file. This is essentially the way most office suites adopted. Suppose you want to update a figure in an office document, theoretically, in iOS, you could send it to am image editor, and after editing, you would then send it back to your office suite. If the office suite app is well designed, it would then automatically replace the figure in your document.
Every time I hear about this problem on iOS, I think of this:
http://en.wikipedia.org/wiki/Soup_(Apple)
It seems more likely that Android adopts iOS than iOS adopting anything close to present day Android (pre-4.4 at least).
I suspect big media hiding in the wings, as random RW of files have been a torn in their side ever since personal computers got powerful enough to act as media players.
Hiding in the wings? Pretty much every player is cross-platform between iOS and Android these days either way…
If “Big Media” gets sad because I might use a computer in a manner they don’t approve of (doing anything that doesn’t give them money), well, they can go cry in a corner, screw them… We shouldn’t dumb down the world to make a few rich fat cats even richer.
Edit: Maybe I misunderstood you and you’re saying big media is waiting in the wings to push for the brain-dead views more on Android… But either way, they can go cry in a corner
Edited 2014-05-01 17:29 UTC
Pretty much what you say in your edit.
I swear that ever since Google started offering music and movies in their Android store, they have made some effort or other to lock users out of writing files to storage areas that don’t support strict access controls.
I prefer the 100% app-driven model present in iOS. It’s easier for normal people to understand and enforce developers to keep it simple.
And for me (and the rest of tech-savvy users)… well, for me It’s exactly the same because I already use apps that allows me to access the filesystem. No problem.
KISS. We don’t need to convert iOS in MacOS.
But if that ‘KISS’ leads to more complexity… Isn’t it time to stop pretending it’s KISS in the first place?
The search for simplicity can actually create complexity. iOS’ handling of files is a textbook example of that.
It totally depends on the type of user you are targeting to.
In my humble experience, common people don’t care about files because they don’t understand what a file or a filesystem is. xD
And I think iOS should be a product for common people like my mom or my dad. Tech-savvy people, like you and me, can install a 3rd party app and access the FS… it’s not a problem.
Uhm… That’s the whole problem: on iOS, you cannot.
What you are describing is the situation on Android.
There’s an app for that xD (well, more than one)
Not that Im arguing against your point (I get it), but just to nitpick…
File handling is iOS is incredibly simple – there is almost no complexity at all. Its only “complex” when you are trying to do something that the system doesn’t directly support. I.e. it is complex to try and “work around” the system, but it is extremely simple to use the system as it exists without workarounds – its braindead simple.
What you are calling complexity is not in fact complexity – it is a combination of the side effects of sandbox security and omitted features.
1. Its security in the sense that the designers took the approach that apps should be sandboxed and should not have a view of the entire file system (i.e. each app is an island). This in and of itself is not necessarily a bad thing.
2. Its omitted features in the sense that there is literally no OS mechanism to cross sandbox boundaries as far as local IO goes, short of things that are in central system repositories like music and whatnot. It just doesn’t support doing that at all. All the complexity you see is due to developers/users attempting to plug this gap in the featureset.
Im only saying to point out that if you want 1 (and Apple strongly wants 1 because they run a curated app store and anything short of that is chaos), then you cannot have a “file picker”. It just doesn’t work…
There are probably a few ways to solve the problem, some of them generalized solutions (intent system ala Android), some of them more specialized (adding more system level repositories for certain kinds of data) – but the one thing that is not a solution to this problem is “add a file picker”.
Just saying. It is a problem. It is a horribly bad problem. It is frankly ridiculous that they still have not addressed this problem. But the solution to this problem is not opening up the file system and adding a “file picker”, because doing so cannot be done while maintaining the existing security model the OS is built upon…
Im sure the “but its my damn files and I should be able to do what I want with them” crowd will find this explanation woefully inadequate, I expect nothing less. But it is simply reality. You will never see a generalized file browser on iOS – it just isn’t built to ever support doing that, and I strongly suspect it will stay that way.
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.
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.
> 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
The user doesn’t care, or even know, what the kernel is.
It’s not just the kernel. The entire *BSD/GNU Darwin userland is there too. That’s the real reason Apple won’t ship GPLv3 software in OS X’s base – they’d have to allow people to load custom code on iDevices.
I disagree that it can’t be done. Add a new permission that apps must be granted to access a common file storage area.
Old apps wouldn’t ever try to access it, so no harm done. New apps can just ask the owner for permission.
I completely agree (see my other post) – but that solution does not imply nor require a “file picker” – those two things are completely orthogonal.
Someone could of course write some kind of “file manager” for a common storage area – but the thing is, if apps are sharing a common storage area what exactly is there to manage? Apps can easily just continue working as they do now – they work with the file types they know how to work with however they choose to. What would you “manage” exactly? Apps don’t need (and probably would prefer not to have) to deal with hierarchal folders.
So now we get into user created folders/organization and whatnot – and I personally see no point in ever doing that in iOS. Its not that it can’t be done, I just don’t think it serves any useful purpose (and I suspect Apple agrees with me).
Totally. In many ways, a Segway is simpler to ride than a bicycle, but it’s a vastly more complex and trouble-prone machine. In attempting to make something simple, they added enormous complexity.
Apple did the same with iOS, is making it simple for 50% of tasks, they make it very complicated for 40% and downright impossible for 10%.
I would suggest though, that it’s easier just to stop battling with it. Accept iOS is not for getting work done, and just about doing small tasks and consuming media.
I am not really addressing you main point (which I generally agree with) but I will quibble with this:
As someone who has put more than 6300 miles on my segway over the last 7 years, I definitely agree about the first part, but I am not sure I agree on the second.
I, and the other segway owners I know wouldn’t call them more trouble prone than a bicycle. But then again it depends on what you mean.
If you mean in terms of reparability then your are right, most electronics aren’t that repairable that were made in, say, say the last 30 years. But if your Bike throws a chain, you can fix it on the side of the road. If one of the gearboxes goes out.
If you mean in terms of problem rates, I am not sure if there is good data that compares the two.
In terms of maintenance, I would suggest the average segway owner and the average bicyclist have about the same, but the advanced bicyclist probably has a little more.
But the thing I find most interesting is that you are the far from the first to compare the segway to a bike, and that is IMHO a flawed analogy. To someone disabled (like myself) it is comparable to a mobility scooter.
For general purpose riding/commuting it is like an electric bike, or a motorcycle, etc etc.
Another reason Apple will not open up the filesystem is this:
http://hothardware.com/News/FSecure-Report-Notes-Over-99-Percent-Of…
99% of malware target Android… This is not another security through obscurity tactic.
Sounds scary. Until you realise that what matters is *infection rates*. All this tells you is that malware makers are focussing on Android. It does not tell you if they’re succeeding in any meaningful way.
This is not a very difficult thing to comprehend. Sadly, it will get trotted out every time by people who have no idea what they’re talking about.
Unfortunately it does matter immensely. For one, these are only the ones that are know about. There are probably dozens of exploits that are currently active that no one knows about except the authors. I would venture to guess that of the 275 targeted to Android, most were in the wild making money for their authors for some time. If there is no market… they don’t get written!
You are wrong. The data states that Android is crazy secure. Malware is not an issue on Android, no matter how many antivirus peddlers state otherwise.
http://www.osnews.com/story/27365/Android_is_almost_impenetrable_to…
I’ll gladly change my mind if the data compels me. Right now, the data points to Android being secure. Sorry.
I always shred a tear when I see friends of mine running anti-virus on tablets/smartphones.
They just go into the story they should get one, when buying their devices.
Worse, some of them even get them pre-installed.
Is it so hard to only install stuff from the stores? Even for apps that might be malware, it is just a matter of checking a few reviews online.
Really self referencing….. WOW!
And of course Google has less of a stake it this then the antivirus folks and would never fudge the numbers… Oh wait never mind!
-deleted- mmm … for some strange reason my happy birthday post was not published in the “50 years of basic” thread …
Edited 2014-04-30 21:55 UTC
I’ve moved on from iOS because of this one problem. I was once a happy iOS user for many years until a friend of mine let me borrow his Asus Transformer for a week while my iPad was in the shop. I couldn’t believe how much I missed a file-manager when I used ES File Explorer. I was able to connect not only to my local data but my cloud and NAS servers from home and work all from one app, I was hooked after that and immediately bought a Asus Transformer SL101 Slider, I have been an Android user ever since and I will never go back to iOS until this is fixed. Well this and ability to choose my default browser, widgets, customizing my home screen, etc. So I guess it won’t be soon which is fine as I am very happy with my Nexus 10 and my Nokia 2520.
Yeah, that’s the thing that really grinds me when using iOS compared to Android:
On Android, you’re in control of your files and your default apps, on iOS, you’re not, Apple is.
Even non techy people who start out happy on iOS eventually run into the “default apps” artificial restriction and just that one thing has made as many of my friends switch as a larger screen.
Pretty sure I’ve said this before, ios is a consumption os.
File access isn’t a requirement.
Buy, consume, shut up.
This is an oversimplification. By way of example, my eight-year old this evening used Pages on iOS to write a story. She then searched for some images on Google and added then to the story, and drew a cover illustration on Artrage for iOS which she added to the Pages file. She then emailed the file to her grandmother. This isn’t ‘consumption’. It entailed working with multiple files, but it didn’t require file access. And iOS handled it beautifully.
On the other hand, while she was doing that, I was redrafting a chapter in my textbook to take account of a few recent developments. I was simultaneously working with nine different files across five file types (source material, an SVG illustration, the actual text, etc.) – and that was just one section of one chapter. I need a folder hierarchy to keep the files I’m working with organised, and I need to be able to use the same hierarchy for different types of files. I simply couldn’t have done any of this on iOS – which is why my daughter is now the primary user of my iPad.
So I’d say it isn’t as simple as a creation / consumption dichotomy. It’s probably more accurate to say that Apple is targeting certain types of use (covering both consumption and creation), and as a structures iOS in a way that doesn’t work for other types of use.
If you’ve used finder you get the idea that Apple doesn’t really like file management or file based systems. Apple’s operating systems are more task oriented. I hate it but that has been their approach for a long time.
With ONE sentence — and it seems to be something plagueing UI designers right now be it iOS, OSX, Windows 8, or *nix desktops like Gnome 3 or Unity… Or even web development.
frustrations born out of “keep it simple”
In web development, we have a term for this: False Simplicity. Where something looks simple, or looks good, right up until you try to use it.
http://baymard.com/blog/false-simplicity
Apple is repeatedly guilty of this, and it’s part of why I consider OSX (and MacOS before it) a cute toy OS, but useless for me as a ‘daily driver’… It’s also why (on top of the alleged quality that… well, isn’t) after trying out several different models of iOS products, I went out and got a cheap Andriod powered phone — which I am FAR happier with.
It’s the old saying in action — things should be as simple as they need to be, an no simpler!
It’s why Windows 8 is a giant middle finger to notebook and desktop users, why iOS can be so annoyingly crippled people like myself wouldn’t waste money on anything running it, and why a lot of websites no matter how pretty they are, end up useless to visitors.
Edited 2014-05-02 22:02 UTC