Since the preferences folder lives in the app, the preferences are deleted when the app is deleted, or reinstalled. That's what I've seen.
According to the docs, (and the scratch files in your /library folder if you use the simulator, everything is in the app and nowhere else. If reality is different, I wonder why it conflicts with what the documentation says. If "every app is an island", then I don't see how what you say an be true. I hope you are right, however. And restricting general access to the file system is a royal PITA. On Aug 22, 2012, at 7:37 PM, Graham Cox wrote: > > On 23/08/2012, at 1:18 AM, Alex Zavatone <z...@mac.com> wrote: > >> Regarding Sandboxing on Mac OS or iOS, the situations I want to see >> addressed are these: >> >> The app gets regularly updated. Preferences must exist out side of the app. >> What easy and straightforward method that does not require the developer to >> jump through hoops supports preservation of app preferences when an app may >> be deleted or upgraded WITHOUT using "the cloud", as this is completely in >> violation of many companies' policies. > > > Well, much as I hate the sandbox implementation (and note, that's the > implementation, not necessarily the concept, though I believe that the > concept as it stands isn't well thought-through) this particular aspect isn't > a major factor. > > Your preferences live in your sandbox, to which you have free access without > jumping through any hoops, as long as you use the usual directory discovery > APIs, or NSUserDefaults. Upgrades are not a problem. Deletion of an app could > be a problem but AFAIK the sandbox for an app is not automatically deleted if > you trash an app in Mac OS (in iOS, that's another thing, as you have only > one means to trash an app and it deletes its sandbox). The sandbox itself is > not inside your app bundle, it lives elsewhere, so you can trash the app and > leave its sandbox behind. Since the sandbox is identified using the bundle > ID, a new version of the app will inherit the old version's sandbox. > > Where life is made difficult is with more general access to the file system, > which is a perfectly legitimate thing to do. A user stores various media all > over the file system and there is no reason why an app shouldn't have access > to it. There are several "shoebox" type apps (iPhoto, iTunes, etc) that also > manage media and it is perfectly reasonable for another app to want access to > that data. Doing this in a manner that is consistent across OS versions, > sandboxing, localizations and so on is extremely difficult if not impossible > right now. Apple are severely handcuffing us on the sandboxing front, but are > not giving anything back to sweeten the deal. If they provided a sanctioned > API for accessing media consistently that would go a long way, for me at > least, to accept sandboxing. Trying to work around this is proving impossible > with the current sandbox implementation - there are too many opaque hacks in > the system that mean you cannot trust the URLs you get from anywhere to > actually point to the right place, and you also have to hard-code paths in > your entitlements which are extremely fragile under both localisation and > system updates. (For example, if I add a temporary entitlement to > ~/Pictures/iPhoto Library, if that location changes, or is named differently, > my app stops working. Note the name of the iPhoto Library did subtly change > between 10.7 and 10.8 - the space is a different unicode character now). > > The only bright spot in all of this is the fact that on Mac at least you have > a channel other than the App Store to deliver apps, but since the App Store > is responsible for 90% of our sales, it would be commercial suicide to leave > it. So we're stuck. > > The other aspect of this is that the way the App Store staff treat the > developer in the face of sandboxing issues is seriously hurting developer > relations and Apple's image. But that's a separate issue I suppose. I do > remember a time when Apple's developer relations were second-to-none. Oddly, > the company was on death's door at the time. Success (which we've all had a > small part to play in) breeds contempt, it seems. > > --Graham > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
