
Apple forces each iOS app to have its own independent system for managing files - kaiwen1
https://plus.google.com/100198164384432656847/posts/JUPAUCe8jQK
======
danilocampos
> 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
> 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.

------
jmillikin
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.

~~~
Negitivefrags
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.

~~~
rayiner
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?!

~~~
strlen
They way I view is similar to de-normalization/"pre-materializing" in a
database: the real solution is for a file to be tagged with pieces of
metadata, maintain a real-time index, and then to be able to perform exact
queries instantly (something like LinkedIn's faceted search) against this
metadata.

E.g., first I want to find all files tagged with "code", then I want to find
all files tagged with "current project". Then I get a list of all files in a
current project and possible tags I could look for (e.g., it will show many
are also tagged with "java" or with "C++" so I can add those tags to my
search).

The problem is historically (that is, until recently) these kind of queries
have been prohibitively expensive in both space and time: there's time
complexity of doing a boolean query on the index, there's the space complexity
of storing the index amenable to those queries both on memory and in-disk.
This is difficult to in the context of legacy desktop machines (think minimal
requirements to run Windows XP: 256mb of RAM, 5400 rpm disk, pentium III cpu)
that were prevalent until just a few years ago.

Instead, the solution chosen is the same solution that folks building
distributed "NoSQL" databases or sharded SQL database setup go for: group all
related data into a few rows (in this case directories) and treat the data as
hierarchical (a return to pre-RDBMS era).

Today if your working set fits in main memory (which is most probably the case
for even the biggest data collections on most people's personal desktops),
there's no longer a performance related reason to use a single-node (non-
partitioned) "NoSQL"-style setup (there may be other reasons to, e.g., wanting
to have a more flexible schema, saving time, wanting to scale out later,
etc...)

I suspect the real reason we haven't done this with file systems is due to
legacy: I have data organized into files and folders going back to ~1998 that
I do not want to lose and can't afford to tag manually.

The support from my theory comes from the fact that the first systems to
embrace non-hierarchical file system have been legacy-free devices where
important storage (for 99% of the people out there...) is either on the SIM
card (addresses), in the cloud (mail) or is de-facto tagged and has to be
copied over in any case (photos which have EXIF tags and are stored in photo
album apps or cloud services).

The same has also been happening on the other end of the spectrum: e.g., large
scale distributed storage system for much similar reasons (i.e., they are the
first of their kind, so there was a "license" to build these systems in a
legacy-free fashion).

tl;dr Hierarchical storage is a non-functional requirement. Functional
requirement is being able to do complex _exact_ queries.

------
azov
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?

------
randall
>> "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.

~~~
anigbrowl
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.

~~~
coldtea
> _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.

~~~
anigbrowl
It arose partly because people were finding it such a hassle to move audio by
saving it one app and opening it in another.

~~~
coldtea
No, it arose because "saving audio in one and opening in another" is not how
you work with sequences, plugins and effects in real time. You have to stream
music and control data from one to another. It doesn't solve the "copy/paste
audio from app to app" problem, it solves something totally different.

Obviously this is a problem that doesn't exist for most file types that don't
have to be passed in real time between many apps to be manipulated at once
(i.e almost all of them).

------
vinnybhaskar
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...](http://venturebeat.com/2013/03/07/f-secure-android-malware-
report/)

~~~
jayfuerstenberg
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).

------
ghshephard
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
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.

~~~
ghshephard
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)

~~~
shawn-butler
Ummm.. they did. [0] Let me know if you have any questions, happy to answer
them but I really get the feeling you're not an actual mobile app developer?

[0]
[http://developer.apple.com/library/ios/#documentation/FileMa...](http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/DocumentInteraction_TopicsForIOS/Introduction/Introduction.html#//apple_ref/doc/uid/TP40010403)

~~~
ghshephard
Definitely not a mobile app developer, actual or otherwise. But, as a user, I
look forward to the day when I can, say, take a newspaper article, and send
them to GoodReader, or grab my boarding pass on singapore air, and put it into
Omnifocus.

It is a little frustrating when I see the Doc/Object right in front of me -
and I can't send it anywhere.

My current model of sharing files/docs between Apps is usually to Take a
screen shot with the Home/Power button, which gets it into my camera roll,
from there I can copy/paste the image into various apps that take paste..
Screen Shot + Camera Roll + Copy/Paste is my current iPhone Inter-App sharing
process. I have to believe there is something more efficient in the future.

------
arpit
I wrote about this a while back: [http://arpitonline.com/blog/2010/03/28/is-
the-file-system-an...](http://arpitonline.com/blog/2010/03/28/is-the-file-
system-an-outdated-concept/)

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.

------
parasubvert
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.

------
kalleboo
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.

------
pkaler
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>

------
mitchty
Title is just a skosh editorialized.

~~~
fpgeek
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.

------
long
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.

