Thursday, November 22, 2012

Transcribed - The Potential For More Confusion

I like to listen to podcasts on my drive to and from work - it helps me soak up knowledge that I wouldn’t otherwise have time to learn. I’m an Apple tech geek, and sometimes I like to listen to indie Mac/iOS developers talk to each other about coding, how their software and the platforms work, the issues they run into, etc. The deeper actual code I’m not familiar with so I’ll usually skip those sections. :)

Recently I sent in a question to one of my favorite podcasts, Core Intuition. This podcast is between Daniel Jalkut of Red Sweater, developer of MarsEdit, Black Ink, and FastScripts, and Manton Reece of Riverfold Software, developer of Tweet Marker, Tweet Library, and Watermark.

In Episode 52, they answered my question! With permission, I have transcribed the answer here so it’ll be searchable for me and others. At time marker 14:57 into the podcast, we have the following:

[M] All right, it’s time for a listener question. This week, we have one from Chris Denesha, and the question is:

"As a techie user and not a dev, I was wondering if you could spend some time on this. If a sandboxed Mac app is deleted, will all the preferences necessarily be deleted as well? i.e. must all prefs live inside the bundle?"

[D] Ok, good question, Chris. As some of our listeners know, but probably not all of our listeners, the way sandboxing works is twofold. First there are a number of access restrictions on what the app can open, what it can connect to, what it can read and write on the system. Then there is the aspect of limiting its access to the system, that is, giving it a virtual ‘bundle’, as Chris described it, which is like a virtual copy of the home directory, the user’s home directory, and that lives in ~/Library/Containers. So if you look in there on a Lion or Mountain Lion system, you’ll find various bundles for each of the sandboxed apps on your Mac. The question was, “if the app is deleted will the preferences be deleted as well?” I think, Manton, that this is one of those situations, in this sense it is not any different from any non-sandboxed app in that when you throw out the app binary it doesn’t automatically do anything to clean up anything in your home directory that that app may have left there.

[M] Right, and this is a difference from iOS, where when you delete the app, it does delete all of the data and preferences.

[D] Right!

[M] And I kind of prefer the Mac way actually.. I don’t know, I kind of like having those separate because it seems like too much magic going on if you delete the app and then a bunch of other stuff gets cleaned up too.

[D] Yeah, I think I could see Apple going, moving in that direction. I could see, maybe sometime down the line, 10.8.2, .3, .4 they add a feature or something that when you emptied the Trash, if there is a sandboxed app in there, then it says “would you like to delete this app’s files as well?”

[M] Right, a prompt.

[D] There are some third-party apps out there, like, I know Hazel does this, when you throw something out you can have it automatically go out and try to find all the files that are related to the app and throw those out as well.

[M] Yep.

[D] But I don’t think that Apple has anything like that right now. So to answer Chris’ question: No, the preferences will not necessarily be deleted, and the nature of that Containers file, the way that that Containers folder is created and hooked up to the sandboxed app that owns it is by bundle ID, I believe, so that would imply that if you did then down the road download the sandboxed app again and run it on the same system then you would instantly have access to all the original files you had saved with it before.

[M] Right. And I think that’s the safest thing. Cause I can think of a lot of cases where you’d want to delete the app and download it again or something, and you wouldn’t want the data to go away. It definitely speaks to the larger issue of where Apple is going with hiding a lot of things, you know, even the whole ~/Library folder itself is hidden by default.

[D] Right.

[M] Certainly with iCloud syncing and documents in the cloud, it’s not obvious where this stuff is anymore, which is a big change from what we’re used to on the Mac. I get where Apple is going with it, but I think there is also the potential for more confusion, especially for so-called power users or people who are used to managing their own files, not having a clear sense of where things are. With iCloud in particular, I’m really.. the more I use apps that have iCloud, the more disappointed I am that it’s so hard to know where things live. For example, I used an app the other day that syncs some stuff to iCloud, and I decided I didn’t want to sync to iCloud. That data is probably on iCloud somewhere, I can’t access it, I can’t delete it, I can’t clean up that data.. it’s in the cloud somewhere. Maybe I don’t want it there anymore, and there’s nothing I can do about it.

[D] Where was I hearing about this recently? I think it might have been Merlin Mann when he was on John Gruber’s Talk Show. I don’t know if you heard this recent episode. They were just talking about it (I hope I’m not dramatically misattributing this to the wrong show), but I think they were talking about this, and Merlin was talking about how there is a kind of a loss of a sense of place for your stuff. It used to be, Yes, you could have everything on a Zip drive or whatever, and you lose the Zip drive and you’re screwed. At least you knew what you were dealing with, you knew how to manage where stuff is. What you’re saying, it sounds like you’re a little squeamish about.. how many copies of my data are there, which copy is the canonical ‘It’? The more Apple adds these affordances that take away the sense of ‘file system’, the less sense of ‘place’, I think, there is for this stuff. It’s like “where is that stuff? It’s in the app”. And that speaks to another issue, of course, which is the whole sandboxing approach with the idea of cloud based storage, is very counter to the idea of open formatted documents that are shared and usable between different apps.

[M] Yeah, absolutely. Then the documents in the cloud stuff in Mountain Lion is.. certainly, it goes so far in this direction that.. it discourages, I would say, moving documents between apps in some ways.. just because everything is so focused around the app itself. But the fact is, when you’re talking about this Container like Chris says, some documents for an app live in the Documents folder, which is outside this Container, it’s in your home folder.. you can just say File -> Save and you save it there and the sandbox allows you because there is user intent for saving it there, it allows you to save the file there, you know exactly where it is. For some types of apps that don’t have traditional documents, that aren’t document based apps, their documents are really in this Container, they’re in a hidden folder, it’s not obvious where they are, and certainly just the names of the folders discourage people from digging in there. I can see a lot of people confused about where things live now.

[D] What you were just saying reminds me of something I think would be cool, is if the existing user space / home directory concept could be maintained, where you have the Documents folder and your Preferences folder.. and at the same time there is also this concept of the Containers bundle where it’s hiding away all your stuff in a single spot where it could be thrown away easily. The whole unix idea of symbolic links supports this idea.. I could have the safe, locked down copy of all my stuff in my app’s sandbox Container, but then what if as far as the user is concerned stuff can either be “in the app” which is in that sandbox, or they can save a copy out to the Desktop and it lives there, but maybe just as a symbolic link to the sandbox. I had this idea because if you look at the sandbox, the way that the Containers folder structure works (listeners who haven’t poked around in there - just go in and look at what a typical Containers folder looks like) because there’s lot of links to stuff, there’s lots of stuff in there, like links to the standard Music folder for instance.. so they are already doing some kind of trickery in there to make the sandboxed home directory look like the real home directory to the app. It would be kind of cool if Apple could take this sandbox idea and say ‘What if the Desktop folder is just the merge, the union, of all the Desktop folders from all the sandboxes’?

[M] Right.

[D] And that’s what the user sees, and then you get to preserve this idea of shared, customizable, interchangeable, while also having a clear ownership of every file. If you throw out the app and it does one day have that ability to clean up the files for you then it would be able to wipe it all out, and at the same time all of these links to the file could be wiped out from wherever they are on the system. That’s just a kind of a fun idea.

[M] It’s interesting.. you just got to be careful, I guess, that when you introduce these kinds of layers of things you don’t make it even harder to tell where things actually live. It seems that at some point it’s gonna just fall on the UI of apps to handle some of this more. If the type of app you have, if it’s important for the user to be able to access their data and documents, it’s a little more on you to have a UI that allows the user to access stuff and move things around. You can’t rely on the Finder or the actual folder locations making any sense.

[D] Right.