Apple forces each iOS app to have its own independent system for managing files

https://plus.google.com/100198164384432656847/posts/JUPAUCe8jQK

by kaiwen1 • 13 years ago

39 51 13 years ago

plus.google.com

mitchty• 13 years ago

Title is just a skosh editorialized.

fpgeek• 13 years ago

I disagree. The post ends with "We HATE it!", with "HATE" bolded. The title (rage included) is a pretty accurate summary of what you're going to read.

Now if you're asking if this is a useful way of starting an HN discussion about whether or not iOS should change its file managment... I'd say probably not, but that's a different question from whether or not the title accurately captures what the link points to.

damian2000• 13 years ago

Conjures up a 2 year old who's been denied a piece of candy.

benatkin• 13 years ago

Someone with access to edit headlines on HN fixed it. When I first saw it, it said "hate apple for" while the actual post said "hate it". That changes the meaning of it.

jmillikin2• 13 years ago

Android has direct filesystem access, but I can't think of the last time I ever used it. The "sharing" mechanism provides a much nicer experience than forcing the user to fumble around in a tree abstraction that hasn't changed in ~40 years. I eagerly await the day when filenames become completely opaque identifiers, never exposed in the UI.

iOS's problem is that there is no standardized way for third-party apps to allow other apps access to a particular document. That's what the OP is actually asking for. Just because desktops have historically implemented this feature as an N-ary tree of (string, blob) pairs doesn't matter.

seppo00102• 13 years ago

Android's data provider interfaces are so neat on this subject. I can't believe iOS did not implement anything like it yet.

shawn-butler3• 13 years ago

If you mean ContentProvider [0] that is really only useful for highly structured data. Falls apart pretty quickly for non-relational data files and documents as well as media, or do you have some counter examples I could consider?

[0] http://developer.android.com/reference/android/content/Conte...

Negitivefrags2• 13 years ago

There seems to be a prevailing attitude among some that the "users" don't like trees of files and we should all move to something more advanced. It has always seemed weird to me.

Is something being 40 years old make it bad? Humans naturally like to put things in hierarchies. It is a very well understood concept by everyone.

petsos• 13 years ago

> It is a very well understood concept by everyone.

No it is not.

tuananh• 13 years ago

tree hierarchy of more than 3 levels is a big mess.

jmillikin2• 13 years ago

I'm a user. I hate file hierarchies. IMO, the ideal interface to a computer's data storage system would have two ways to find a document:

1) A list of most-recently-seen documents. Each application would have its own list of documents it had seen, and there would be a per-user list for documents from all apps. Documents are added to the lists when they're created, opened, downloaded, etc. There is no limit on number of documents in the list, and the list is searchable. Some modern applications have primitive equivalents, but not as the primary document-opening interface.

2) Give each list a search box, with results as a flat list of extracted metadata. Honestly, just clone the current standard web search engine UI and use that. A search box is the closest computers have come to being user-friendly, and is certainly nicer than dropping the user into a file manager.

---

Example: Firefox's "recent documents" list would be a combination of browser history and downloads panel. To open a file you just downloaded, find it in either Firefox's list, or the global list, and click/tap it. To open a web page you just created in a text editor, you would click/tap it in the global documents list and indicate that Firefox should handle it (e.g. with an Android-style app selector).

Keep existing file-management API calls as they are, and don't tie them into the document system. I don't want a game to add a new document entry for every .so or .png it loads. Application developers can decide how best to represent their document in terms of low-level filesystem objects (a directory, a flat text file, a binary blob, whatever fits the document best).

rayiner• 13 years ago

Who actually puts things in hierarchies, besides technical people? That always struck me as the most ridiculous thing about the "folder" metaphor--when have you ever seen people put folders inside folders?!

m_eiman• 13 years ago

It is a very well understood concept by everyone.

Yet the first thing anyone does when they're looking for something is to Google it, not go to Yahoo's front page, look for the relevant category, find a suitable sub-category, ad nauseam. There's a reason search won that battle.

mooism2• 13 years ago

People can cope fine with hierarchies when different things go at different levels of the hierarchy. Recursive hierarchies? A bit harder.

So: God at the top, then the king, then the barons/lords/etc until you get to the peasants at the bottom. Easy to understand.

Or: shopping centre at the top, then different floors in the shopping centre, then various shops, then aisles in the shop, then vaguely demarcated lengths of aisle, then shelves, then individual items on shelves. Fine.

But: a folder at the top, then more folders in that folder, and further folders in those folders? And all those folders look the same (only the names are different. Actually, sometimes the names are the same as well). That is a bit confusing for most people.

Also consider menus. A menu bar across the top, with a single level of drop down menus underneath? Easy peasy. A start button with a pop up menu, that contains more pop up menus, that contain still more pop up menus? Disorienting. Microsoft thought the only thing holding back deep hierarchical menus was mouse control, so when they refined that for Windows 95 they went crazy with menus inside menus inside menus. Mistake. They've been trying to flatten and differentiate different levels of the start menu ever since.

Meanwhile, programmers need to be good at abstraction, so have no problem with undifferentiated folders within folders within folders.

coldtea4• 13 years ago

>There seems to be a prevailing attitude among some that the "users" don't like trees of files and we should all move to something more advanced.It has always seemed weird to me.

The opposite should feel weird to you. The notion that files belong in some kind of tree structure. It's just an artificial implementation we came up with, more Platonic than realistic.

A file doesn't belong in some "node" in a "tree". It belongs to multiple nodes all around the tree, including "nodes" that only make sense for that one only.

A tree hierarchy FS doesn't reflect that (except if you go crazy with symbolic links). And then it doesn't scale with lots of tags, or tens of thousands of files.

A tagging/metadata system is a far better way to manage those files, and closer to they way we think (associating attributes with objects, remembering based on keywords, etc).

yareally• 13 years ago

Filesystem is mostly useful for a number of cases (though perhaps not the average person), but I am glad it's there and one can access external storage or /system (read only) without root.

It's pretty useful for the following conditions:

1) root users that want move around and change config files (boot animations, system wide theming, etc). Also for flashing stuff in recovery where you need to point to the file you want.

2) ROM modders/developers - looking at various files live on the device and also for low level things such as filesystem access in recovery to get yourself out of a jam.

3) app developers - I like to use sftp on my device and sshfs on my pc to directly access sqlite dbs for apps I am working on and play with the db directly without having to reinstall the app to update it.

4) Those that want apps that obey filesystem rules versus global (like for a music player, I use one that reads by directory instead of just dumping everything in by tags).

jimmaswell• 13 years ago

I use Android's filesystem to move files from SD to internal or reverse, from the downloads folder to more appropriate categorized folders, and to find files to delete for more room. I appreciate having this ability a lot. Things like this should just be standard for any OS. I also open some local html files with file:// on firefox mobile sometimes.

kaiwen1• 13 years ago

That's correct. I'm not advocating a tree-based file system. I'm advocating a shared file system. If that system improves on the tree, I'm all for it.

shawn-butler3• 13 years ago

Isn't this exactly what UIDocumentInteractionController, etc accomplishes? [0] Each application registers the data types for which it is a "viewer". Application with the content provides a way to open the document interaction controller with reference to the document, iOS supplies icons of apps that can open it, user selects app and it opens with a different launch options so it opens the content directly.

There is nothing more fine-grained than file-type but mime-types, win32 registry keys, etc have always just been conventions really outside of a few well-known types. BFS (beos) tried to add in metadata attributes to the filesystem and it was pretty slick, admittedly.

I guess I can kind of see the complaint about wasting space on duplicates but if one app is a viewer, and the other is an editor... well I think the OP comment is kind or obtuse. Sandboxing files is a much better approach for lots of reasons.

Apple made the right decision, let each application organize access to its information in the way it best sees fit. If it's a tree view, ok if it is some skeumorphic bookshelf, ok.

[0] http://developer.apple.com/library/ios/#documentation/UIKit/...

vinnybhaskar• 13 years ago

I guess this guy does not understand what sandboxing is and the benefit it brings in terms of security. Android today has 79% of malware issues and IOS is at 0.7% — thanks to policies like sandboxing.

Reference: http://venturebeat.com/2013/03/07/f-secure-android-malware-r...

jayfuerstenberg• 13 years ago

Agreed.

Developers are generally intelligent people but unfortunately many users are not. Sandboxing is for those people and it does its job well.

I do think however that there is a case for allowing a vendor-level sandbox so that apps made by the same vendor could share data amongst themselves.

This would facilitate free-trial to paid app upgrades.

In any case, give it time. Apple tends to start off with a solid base and build from there (rather than throwing everything onto the wall to see what sticks).

randall• 13 years ago

>> "Does anyone benefit from this?"

Yes, users. Presumably, in Apple's view, the filesystem is a poor metaphor for users. Users think of their files as "in iTunes" or the like. Removing the filesystem separates concerns by requiring more strict ways of passing files around.

>> "each app must copy every file it needs access to" >> "Each and every developer must reinvent the file system"

These points are fair criticisms, but to claim blankly, "Apple needs to make a full U-turn on this" seems a bit much. I think there are a lot of potential fixes for this issue, and even though the author dismisses Dropbox, it seems like an obvious potential solution. There are other OS-level potentials though, like web intents, etc.

The claims, however, seem like a one-sided argument which fails to understand Apple's line of reasoning whatsoever.

anigbrowl3• 13 years ago

It became such a pain in the ass for audio users that a new inter-app standard, AudioBus, was given the greenlight by Apple after accumulating signups from thousands of musicians who wanted to push audio & MIDI data between apps.

coldtea4• 13 years ago

>It became such a pain in the ass for audio users that a new inter-app standard, AudioBus, was given the greenlight by Apple after accumulating signups from thousands of musicians who wanted to push audio & MIDI data between apps.

AudioBus doesn't have anything to do with sharing files on some folder. It's about passing audio and midi information around, which is different. You can do that, and still have every application perfectly isolated and deletable at will.

danilocampos2• 13 years ago

> Stop it Apple! Every minute we spend dealing with this nonsense is a minute of lost productivity and a minute of aggravation. Collectively we've clocked up billions of these minutes and we hate it! You understand, Apple? We HATE it!

Do you remember that Leave Britney Alone kid?

Speaking as a developer, the ability to do interesting things with files has improved dramatically over the years. You can do the email attachment thing, iTunes sync, clipboard, Dropbox... In my day, we put things on S3 and passed custom links around. And we liked it! (Not really; it was terrible.)

As a user, now, I call bullshit. It's occasionally weird but it's definitely not a rage-inducing condition. Besides that, Apple has found an easy-to-communicate means of enabling their users manage the limitations of their storage:

Every app has its own weight. Need room? Dump an app. Don't worry – nothing you do in any other app will be affected.

Does it make for some duped data? Probably. Maybe tons for certain workflows. Doesn't matter.

The hermitcally sealed environments of each app let a larger swath of their userbase manage things without outside help. Limited complexity makes it easy to understand the scope of possible problems and solutions.

tl;dr: Ain't no Santa Claus and keep on crying.

derefr• 13 years ago

> Every app has its own weight. Need room? Dump an app. Don't worry – nothing you do in any other app will be affected.

To put it another way: apps need to communicate large blobs of information (i.e., documents). You'd say, from first principles, that they need a nonvolatile Inter-Process Communication mechanism.

In most OSes, apps pass documents between them with the moral equivalent of "shared memory" IPC: files that both apps have read/write access to.

In iOS, on the other hand, apps use the moral equivalent of message-passing-with-copy.

Thus, apps get all the same benefits from this that, say, Erlang processes get from in-memory message-passing-with-copy IPC. The primary one being that when the process/app is removed from the system, all its resources can be released, without having to disentangle them from any other process/app that might be depending on them. This gives you the dual philosophies of "let it crash" and "just delete it", respectively.

arpit• 13 years ago

I wrote about this a while back: http://arpitonline.com/blog/2010/03/28/is-the-file-system-an...

Not having a mess of folders I need to deal with is mostly a welcome change in the new devices. On iOS I never have to think about the files, but if I do uninstall an app (say if I get a better drawing app or something), all my work done in app 1 is lost. On Android thats not always the case though I do find folders of data written by apps that I have uninstalled and had no idea was still around.

I think having a file system is a good thing, but it doesnt need to be very much in a user's face. A middle ground may be where a user doesn't see a file system but can get a prompt like "Get data from app..." that then negotiates with the other app to actually find the relevant directories.

azov• 13 years ago

It's a tradeoff. Not sharing files means that rogue/buggy apps can't mess up data from other apps, app developers can change file formats without worrying about other apps reading their files, you don't need to worry about files left over after you delete an app, etc.

On the flip side, nobody except Apple can implement utilities that work with "data regardless of what kind of data it is" - things like synchronization, compression, encryption.

Personally, I agree with the OP in a sense that I don't like the choice that Apple made, but I can see their logic... And given that choice, what I would really like to see is more apps using UIFileSharingEnabled key, which allows me to copy files between app sandbox and my computer via iTunes - you hear me, Dropbox?

long• 13 years ago

It seems like Apple is doing kind of a "pure" filesystem (i.e., no global state).

If hard drives get fast enough, I can see that being what you want.

ghshephard4• 13 years ago

I'm sure there is a use case for sharing files between applications beyond what we currently have (Photos, Contacts), but, in the 5+ years I've been using my iPhone (and it's 200+ current apps installed currently on my phone) - I've never run into it. I (personally) love the fact that everything is reasonably sealed off. In fact, the major problem I had with the iPhone was that it allowed applications to access my address book without my explicit permission (since resolved) - it wasn't sealed off enough.

I'll be the first person to sign a petition requesting that Apple continue to enforce their absolute separation without really explicit guidance from me. The tradeoff (lack of flexibility versus increased security) is one that I'm very happy to make.

dthunt• 13 years ago

I ran into that on my first day, and a bunch of times since. I guess you've never been in an airport, and realized you left that audio book at home, and though to yourself "Oh, right, I'll just copy it over."

Surprise, unless your scp application has a built in audio player, tough nuggets.

It's infuriating when you're dealing with ebooks in other languages (particularly Japanese) as iBooks and a bunch of other apps are not very good at supporting these. With no way of sharing books between apps, you wind up needing to find a new way to smuggle your book app to app in order to find out that this one doesn't work, either.

I'm sick of all the apple apologists acting like this isn't a pain point or that inability to do these things is somehow good. It's bad, it's a major pain point, and it's not about malware. It's about limiting your choices.

I'm also willing to attribute the lack of app-app sharing of data to intellectual cowardice.

ghshephard4• 13 years ago

I'm not an Apple apologist. They make some miserable choices, and a some of their apps are complete crap (Their podcast app should have never, ever been released.) I've never been happy with any of their cloud applications, mobile me was crud, their web photo sharing system is still next to useless, and photostream is barely useable - you'd think after a couple years they would have been able to figure out how DropBox syncs so reliably. Battery Management is horrible - I can't tell what's heating up my iPhone and sucking down my battery. Background applications STILL can't download files, even when you have 100% battery, are plugged in, and are on WiFi (Seriously - when is Apple ever going to figure that one out - When will my NYT app be able to download a newspaper, OmniFocus Sync my Tasks, Downcast download my Podcasts, etc..).

I could go on and on about the things I don't like about Apple, and Apple products - but, the one thing they nailed is 100% App Separation on the iPhone. Malware is already starting to make it's way onto the iPhone, and the more they can do to lock down that platform, the happier I'll be.

Does this mean that I don't have the flexibility with my Phone that I have with my Laptop? Yes. But does it mean my phone is about 10x more consistently reliable than my Laptop - Also yes.

But, with all that said - could Apple come up with a mechanism to allow some kind of Inter-App sharing, wherein you could explicitly (I.E. User Initiated, not App Initiated) send data from one application to another - Almost certainly. John Siracusa has been on them to do this for at least a couple years now - and if they'd simply use one of his (very well informed) rants as their PRD, the IOS platform would certainly evolve. But I'm hoping they do it in a way (Copy / Paste?, Sharing Icon?) that guarantees the same level of separation, reliability, and simplicity that we currently enjoy.

Until then - Media viewing/consumption apps like GoodReader usually offer a pretty broad variety of input options, including just reading from your Dropbox folder (among many, many choices)

pkaler• 13 years ago

This isn't a very well informed rant. Sandboxing exists so that malware doesn't get access to all of your files. The address book used to not be protected and look at the crapstorm that caused when Path accessed the address book without informing users.

And a file tree is a poor abstraction for "mere mortals". John Siracusa has a much better discussion of why an exposed file system is a bad idea in the last episode of the Accidental Tech podcast. http://atp.fm/episodes/6-live-like-other-people

kalleboo• 13 years ago

The lack of file organization is fine for what iOS is right now. But if Apple is pushing this platform as a place to do real work, there ought to be a way to group assets by project, save/restore them as a group, etc. Maybe this could be done as tags, but I don't know if users actually prefer that to folders.

For instance, on the Mac you have the "Web Receipts" folder for all your saved purchase receipts. On iOS, where would those go? The Apple solution would be a dedicated "Receipts" app, where otherwise a generic PDF viewer would do the same job.

iOS is kind of the opposite of the Unix philosophy - every app has to do everything.

parasubvert• 13 years ago

As I replied to this developer, I think a device-level file management store and UX is very 80s.

The solution to the current trade off IMO is to maintain the sandboxes, but to fix pervasive search across apps and devices - expose more data facets, make the UX ubiquitous, ensure strong default privacy controls, and oh yes, ensure the FAST=TRUE setting is enabled. That's how you outflank DropBox.

I'm not sure if many here use iCloud search today (for mail), but it is abysmally slow and unreliable. This isn't just my personal pipe dream - apple really needs to fix search... but they could do it in a way that is consistent with their long term goal of eliminating the hierarchical file system for regular users, and really revolutionizing data access/sharing UX.

Apple forces each iOS app to have its own independent system for managing files

Related Stories