Re: Bundle Identifiers - and application support directory
Hi Quincey, The Library Directory Stores App-Specific Files Application Support All content in this directory should be placed in a custom subdirectory whose name is that of your app’s bundle identifier or your company. My vague recollection is that it used to say something like or your app name too. A similar description here: https://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/MacOSXDirectories/MacOSXDirectories.html I've wondered about why Mac apps put their app's name on their folders in the directories Application Support. It seems to me that this is just asking for problems and isn't localizable. I noticed that in Lion and Mountain Lion that the directory ~/Library is now invisible by default. Maybe Apple is starting to say that the folders within this folder such as Application Support aren't for human consumption anymore. -- Kaydell kaydell.leav...@icloud.com http://learnbymac.com ___ 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
Re: Bundle Identifiers - and application support directory
On Wed, 10 Jul 2013 10:43:04 -0600, Kaydell Leavitt said: I've wondered about why Mac apps put their app's name on their folders in the directories Application Support. It seems to me that this is just asking for problems and isn't localizable. I noticed that in Lion and Mountain Lion that the directory ~/Library is now invisible by default. Maybe Apple is starting to say that the folders within this folder such as Application Support aren't for human consumption anymore. If the folder's contents aren't for human consumption anymore, why do you worry about localisation? Also, I've never understood why ~/Library is invisible but /System and /Library are not... Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
Re: Bundle Identifiers - and application support directory
On Jul 23, 2013, at 11:52 AM, Sean McBride wrote: On Wed, 10 Jul 2013 10:43:04 -0600, Kaydell Leavitt said: I've wondered about why Mac apps put their app's name on their folders in the directories Application Support. It seems to me that this is just asking for problems and isn't localizable. I noticed that in Lion and Mountain Lion that the directory ~/Library is now invisible by default. Maybe Apple is starting to say that the folders within this folder such as Application Support aren't for human consumption anymore. If the folder's contents aren't for human consumption anymore, why do you worry about localisation? Also, I've never understood why ~/Library is invisible but /System and /Library are not... 100%. It unpleasantly reminds me of when Homer Simpson started bubble wrapping everything in his house lest Maggie hit a sharp edge. All this hiding and every app is an island seems just like what we did back when we created Shockwave in 1995. Every SW app in the browser could write their own file to a common prefs folder (think Documents, Music, Contacts). The first thing I did (after we shipped the plugin) was create an API in Shockwave's scripting language to a prefs file as a communication system between apps. It had a rudimentary locking mechanism (think pessimistic locking on a file write level with one all/none flag and one file). The file had sections with the applications' identifiers and within each identifier section, the public variables the authors wanted to expose, etc. We quickly bypassed the purpose of the plugin's application sequestration and had apps that made these little data stores and exchanged data and files at will. But an open subset of the file system with requests certainly would have been nicer. Back to iOS and it seems to be certainly creeping in to the Mac OS, it's a shame that we have this attempt to jam every document into the application that created it. Every App is an Island and some of our folders being hidden while more important (and more dangerous ones) aren't certainly isn't conducive to the fun we had that got many of us using Macs in the first place. Certainly seems like bubble wrapping parts of the OS lest we fall and hit our heads. ___ 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
Bundle Identifiers - and application support directory
I am trying to create an application support directory for my app ( on 10.8.3 )
I am using this piece of example code ( from the docs ) :-
NSString* bundleID = [[NSBundle mainBundle] bundleIdentifier];
NSFileManager*fm = [NSFileManager defaultManager];
NSURL*dirPath = nil;
// Find the application support directory in the home directory.
NSArray* appSupportDir = [fm URLsForDirectory:NSApplicationSupportDirectory
inDomains:NSUserDomainMask];
if ([appSupportDir count] 0)
{
// Append the bundle ID to the URL for the
// Application Support directory
dirPath = [[appSupportDir objectAtIndex:0]
URLByAppendingPathComponent:bundleID];
// If the directory does not exist, this method creates it.
// This method call works in OS X 10.7 and later only.
NSError*theError = nil;
if (![fm createDirectoryAtURL:dirPath withIntermediateDirectories:YES
attributes:nil error:theError])
{
// Handle the error.
}
}
When I run the code, bundleID is nil.
Is there something that I have to do to give my bundle an ID ?
I have checked the methods of NSBundle ( and NSBundle docs generally ) but
cannot see anything that looks promising.
Ultimately, I need to store some user modifiable files -
I am assuming that NSApplicationSupportDirectory is the correct place to do
this.
Peter
___
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
Re: Bundle Identifiers - and application support directory
On 10 Jul 2013, at 11:25, Peter Hudson peter.hud...@me.com wrote:
I am trying to create an application support directory for my app ( on 10.8.3
)
I am using this piece of example code ( from the docs ) :-
NSString* bundleID = [[NSBundle mainBundle] bundleIdentifier];
NSFileManager*fm = [NSFileManager defaultManager];
NSURL*dirPath = nil;
// Find the application support directory in the home directory.
NSArray* appSupportDir = [fm URLsForDirectory:NSApplicationSupportDirectory
inDomains:NSUserDomainMask];
if ([appSupportDir count] 0)
{
// Append the bundle ID to the URL for the
// Application Support directory
dirPath = [[appSupportDir objectAtIndex:0]
URLByAppendingPathComponent:bundleID];
// If the directory does not exist, this method creates it.
// This method call works in OS X 10.7 and later only.
NSError*theError = nil;
if (![fm createDirectoryAtURL:dirPath withIntermediateDirectories:YES
attributes:nil error:theError])
{
// Handle the error.
}
}
When I run the code, bundleID is nil.
Is there something that I have to do to give my bundle an ID ?
I have checked the methods of NSBundle ( and NSBundle docs generally ) but
cannot see anything that looks promising.
The bundle ID is set in your app's Info.plist. I'm surprised that Xcode will
even let you build an app without one though.
___
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
Re: Bundle Identifiers - and application support directory
Thanks Mike. I have now set an ID for my bundle and it is feeding through
happily.
Now I can set an ID, the docs suggest the format
com.companyDomainName.appName for the directory name in Application Support.
I notice that very few other applications use this format - they tend to use
just the name of the app.
Is there a good reason to follow the suggested naming convention ?
Peter
On 10 Jul 2013, at 14:33, Mike Abdullah mabdul...@karelia.com wrote:
On 10 Jul 2013, at 11:25, Peter Hudson peter.hud...@me.com wrote:
I am trying to create an application support directory for my app ( on
10.8.3 )
I am using this piece of example code ( from the docs ) :-
NSString* bundleID = [[NSBundle mainBundle] bundleIdentifier];
NSFileManager*fm = [NSFileManager defaultManager];
NSURL*dirPath = nil;
// Find the application support directory in the home directory.
NSArray* appSupportDir = [fm URLsForDirectory:NSApplicationSupportDirectory
inDomains:NSUserDomainMask];
if ([appSupportDir count] 0)
{
// Append the bundle ID to the URL for the
// Application Support directory
dirPath = [[appSupportDir objectAtIndex:0]
URLByAppendingPathComponent:bundleID];
// If the directory does not exist, this method creates it.
// This method call works in OS X 10.7 and later only.
NSError*theError = nil;
if (![fm createDirectoryAtURL:dirPath withIntermediateDirectories:YES
attributes:nil error:theError])
{
// Handle the error.
}
}
When I run the code, bundleID is nil.
Is there something that I have to do to give my bundle an ID ?
I have checked the methods of NSBundle ( and NSBundle docs generally ) but
cannot see anything that looks promising.
The bundle ID is set in your app's Info.plist. I'm surprised that Xcode will
even let you build an app without one though.
___
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
Re: Bundle Identifiers - and application support directory
On 10 Jul 2013, at 15:01, Peter Hudson peter.hud...@me.com wrote: Thanks Mike. I have now set an ID for my bundle and it is feeding through happily. Now I can set an ID, the docs suggest the format com.companyDomainName.appName for the directory name in Application Support. I notice that very few other applications use this format - they tend to use just the name of the app. Really? In my experience pretty much everything uses the correct format. Is there a good reason to follow the suggested naming convention ? 1) It removes the chance of two apps conflicting for the same name 2) I'm pretty certain Apple won't approve you for the app store without conforming to the rules ___ 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
Re: Bundle Identifiers - and application support directory
On Jul 10, 2013, at 8:27 AM, Mike Abdullah wrote: On 10 Jul 2013, at 15:01, Peter Hudson peter.hud...@me.com wrote: Now I can set an ID, the docs suggest the format com.companyDomainName.appName for the directory name in Application Support. I notice that very few other applications use this format - they tend to use just the name of the app. Really? In my experience pretty much everything uses the correct format. Nope, not even close. Here's mine for reference: 1Password DMG Canvas Logitech Remote Desktop TurboTax A Better Finder Rename 8DVD Player MacHg RipIt TurboTax 2012 Acorn DashMacSQL Roxio Ubiquity AddressBook DashcodeMactracker SEIntelligence Unison 2 Adobe Developer Microsoft SMART Utility VMware Fusion Aladdin DockMindVision DownloadsSMARTReporter Versions ApertureDragThing MobileSync SMARTReporter.log XRay Plugins AppStoreFile Buddy Mozilla SQLEditor Xcode Apple FileXaminer Multiplex SQLGrinder Yahoo! Sync Application Loader Firefox Net Monitor Sandvox com.apple.QuickLook AquaMinds FullCircle NetNewsWire Screen Sharing com.apple.TCC Audio Recorder 3.0 Scripts GarageBand NiXPS Seasonality com.elevated-dev.teamfile Automator Gitbox NoteBook Shark com.intuit.TurboTax.2012 Azureus Google NotificationCenter ShoveBox com.mactrackerapp.Mactracker BBEdit Google EarthOmni Group Skype com.nanotalons.iconfinder.plist BBEdit Backups Google SketchUp 6 OmniOutliner 3 Soulver com.sribe.pedcard Backup Google Video Player OmniWeb 5 SourceTree eSellerate BeLight SoftwareGraphicConverterOsiriX SpamSieve eSuite4X BitTorrent Growl PCalc Spell Catcher iCal CSSEdit IOXpertsPDFpen SubRosaSoft iLifeMediaBrowser ChronoSync ITunesSoftwareService PDFpenPro SuperDuper! iLifePageLayout Clarify Instruments PDFshrink 2 SyncServicesiPhone Simulator CocoaPacketAnalyzer Interarchy PGnJ TerminaliSQL-Viewer Console Interface Builder 3.0 PlistEdit Pro Tinderbox iWeb Core Image Fun HouseKodak EasyShare Preview TinkerTool iWork Cornerstone L8457789100 Project Builder TorusKnotSoftware ilexsoft CrashReporter LaunchCodes Quartz Composer Transmission DEVONthink Little Snitch RapidWeaver TrueCrypt -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
Re: Bundle Identifiers - and application support directory
On Jul 10, 2013, at 8:58 AM, Peter Hudson wrote: Bearing in mind that we do not sell on the app store ( and its unlikely we ever will ) does anyone know the rationale behind the documented way of specifying the directory name and the obvious disparity with real life ? No. Maybe a holdover from the days before bundles and bundle identifiers??? Is there a good reason for the documented way of doing this ? Well, I think so. App names can be localized, can be changed by the user, might even be changed by the publisher (pro 3.0), can be subject to conflict from dummies who put an app out without checking to see if the name is already used... But bundle identifiers in theory stay the same, and if specified properly are unique, and can always correspond to the app no matter what you or anyone else does to the app's name. Too bad *APPLE* chooses to set such a sloppy example... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
Re: Bundle Identifiers - and application support directory
Thanks Scott. That opens up some interesting possibilities for managing the development of the app going forward. As you say, shame Apple sets such a sloppy example. Peter On 10 Jul 2013, at 16:04, Scott Ribe scott_r...@elevated-dev.com wrote: On Jul 10, 2013, at 8:58 AM, Peter Hudson wrote: Bearing in mind that we do not sell on the app store ( and its unlikely we ever will ) does anyone know the rationale behind the documented way of specifying the directory name and the obvious disparity with real life ? No. Maybe a holdover from the days before bundles and bundle identifiers??? Is there a good reason for the documented way of doing this ? Well, I think so. App names can be localized, can be changed by the user, might even be changed by the publisher (pro 3.0), can be subject to conflict from dummies who put an app out without checking to see if the name is already used... But bundle identifiers in theory stay the same, and if specified properly are unique, and can always correspond to the app no matter what you or anyone else does to the app's name. Too bad *APPLE* chooses to set such a sloppy example... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
Re: Bundle Identifiers - and application support directory
Il giorno 10/lug/2013, alle ore 16:43, Scott Ribe scott_r...@elevated-dev.com ha scritto: Nope, not even close. Here's mine for reference: 1Password DMG Canvas Logitech Remote Desktop TurboTax […] Scott, my observations do not agree with yours… I get BundleIDs for apps from an app of mine via the NSRunningApplication bundleIdentifier property and, to be honest, I ever get correctly formed bundle identifiers. As example I get, from your list (for the app I have) I get: 1Password: ws.agile.1Password Acorn: com.flyingmeat.Acorn4 AddressBook: com.apple.AddressBook Aperture: com.apple.Aperture Fusion: com.vmware.fusion Microsoft Word: com.microsoft.Word Apple Pages: com.apple.iWork.Pages. I *think* this property comes from the bundle id (at least, it comes from bundle id for my applications) so I deduce the convention is usually followed… Ciao, gt --- Giacomo Tufano http://www.ilTofa.com/ Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. (S. Beckett) ___ 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
Re: Bundle Identifiers - and application support directory
On Jul 10, 2013, at 9:26 AM, Giacomo Tufano wrote: Scott, my observations do not agree with yours… I get BundleIDs for apps from an app of mine via the NSRunningApplication bundleIdentifier property and, to be honest, I ever get correctly formed bundle identifiers. As example I get, from your list (for the app I have) I get: 1Password: ws.agile.1Password Acorn: com.flyingmeat.Acorn4 AddressBook: com.apple.AddressBook Aperture: com.apple.Aperture Fusion: com.vmware.fusion Microsoft Word: com.microsoft.Word Apple Pages: com.apple.iWork.Pages. I *think* this property comes from the bundle id (at least, it comes from bundle id for my applications) so I deduce the convention is usually followed… The convention that we're talking about is that the apps' directories in Application Support should be named by bundle identifier, not by application name. The list that I provided was the result of ls Application\ Support, so as you can see the convention of using bundle identifiers is generally not followed. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
Re: Bundle Identifiers - and application support directory
Il giorno 10/lug/2013, alle ore 17:43, Scott Ribe scott_r...@elevated-dev.com ha scritto: On Jul 10, 2013, at 9:26 AM, Giacomo Tufano wrote: Scott, my observations do not agree with yours… I *think* this property comes from the bundle id (at least, it comes from bundle id for my applications) so I deduce the convention is usually followed… The convention that we're talking about is that the apps' directories in Application Support should be named by bundle identifier, not by application name. The list that I provided was the result of ls Application\ Support, so as you can see the convention of using bundle identifiers is generally not followed. Oh. I misunderstood... Sorry for the noise. :) ___ 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
Re: Bundle Identifiers - and application support directory
On Jul 10, 2013, at 10:26:22, Giacomo Tufano g...@iltofa.com wrote: Il giorno 10/lug/2013, alle ore 16:43, Scott Ribe scott_r...@elevated-dev.com ha scritto: Nope, not even close. Here's mine for reference: 1PasswordDMG Canvas Logitech Remote Desktop TurboTax […] Scott, my observations do not agree with yours… I get BundleIDs for apps from an app of mine via the NSRunningApplication bundleIdentifier property and, to be honest, I ever get correctly formed bundle identifiers. As example I get, from your list (for the app I have) I get: 1Password: ws.agile.1Password Acorn: com.flyingmeat.Acorn4 One of you is talking about bundle identifiers and one of you is talking about the folder name. Somebody didn't read the full question. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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
Re: Bundle Identifiers - and application support directory
On 10 Jul 2013, at 15:43, Scott Ribe scott_r...@elevated-dev.com wrote: On Jul 10, 2013, at 8:27 AM, Mike Abdullah wrote: On 10 Jul 2013, at 15:01, Peter Hudson peter.hud...@me.com wrote: Now I can set an ID, the docs suggest the format com.companyDomainName.appName for the directory name in Application Support. I notice that very few other applications use this format - they tend to use just the name of the app. Really? In my experience pretty much everything uses the correct format. Nope, not even close. Here's mine for reference: 1Password DMG Canvas Logitech Remote Desktop TurboTax A Better Finder Rename 8 DVD Player MacHg RipIt TurboTax 2012 Acorn DashMacSQL Roxio Ubiquity AddressBook DashcodeMactracker SEIntelligence Unison 2 Adobe Developer Microsoft SMART Utility VMware Fusion Aladdin Dock MindVision DownloadsSMARTReporter Versions Aperture DragThing MobileSync SMARTReporter.log XRay Plugins AppStore File Buddy Mozilla SQLEditor Xcode Apple FileXaminer Multiplex SQLGrinder Yahoo! Sync Application LoaderFirefox Net Monitor Sandvox com.apple.QuickLook AquaMinds FullCircle NetNewsWire Screen Sharing com.apple.TCC Audio Recorder 3.0 ScriptsGarageBand NiXPS Seasonality com.elevated-dev.teamfile Automator Gitbox NoteBook Shark com.intuit.TurboTax.2012 Azureus Google NotificationCenter ShoveBox com.mactrackerapp.Mactracker BBEditGoogle EarthOmni Group Skype com.nanotalons.iconfinder.plist BBEdit BackupsGoogle SketchUp 6 OmniOutliner 3 Soulver com.sribe.pedcard BackupGoogle Video Player OmniWeb 5 SourceTree eSellerate BeLight Software GraphicConverterOsiriX SpamSieve eSuite4X BitTorrentGrowl PCalc Spell Catcher iCal CSSEdit IOXpertsPDFpen SubRosaSoft iLifeMediaBrowser ChronoSyncITunesSoftwareService PDFpenPro SuperDuper! iLifePageLayout Clarify Instruments PDFshrink 2 SyncServicesiPhone Simulator CocoaPacketAnalyzer Interarchy PGnJ TerminaliSQL-Viewer Console Interface Builder 3.0 PlistEdit Pro Tinderbox iWeb Core Image Fun House Kodak EasyShare Preview TinkerTool iWork Cornerstone L8457789100 Project Builder TorusKnotSoftware ilexsoft CrashReporter LaunchCodes Quartz Composer Transmission DEVONthinkLittle Snitch RapidWeaver TrueCrypt Ah, sorry, you're talking about the folder name here, right? I misunderstood and thought we still talking about the raw bundle identifier. ___ 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:
Re: Bundle Identifiers - and application support directory
On Jul 10, 2013, at 08:43 , Scott Ribe scott_r...@elevated-dev.com wrote: The convention that we're talking about is that the apps' directories in Application Support should be named by bundle identifier, not by application name. The list that I provided was the result of ls Application\ Support, so as you can see the convention of using bundle identifiers is generally not followed. The convention has always been or, rather than instead of. The choice is still documented here: https://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html The Library Directory Stores App-Specific Files Application Support All content in this directory should be placed in a custom subdirectory whose name is that of your app’s bundle identifier or your company. My vague recollection is that it used to say something like or your app name too. A similar description here: https://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/MacOSXDirectories/MacOSXDirectories.html doesn't mention the alternatives at all: OS X Library Directory Details Application Support By convention, all of these items should be put in a subdirectory whose name matches the bundle identifier of the app. so it's possible that we're seeing a change in the convention in progress. My guess is that the app-name variant was previously preferred because Application Support was always envisioned as a folder that users might have a reason to visit in the Finder. But in sandboxed apps, Application Support doesn't seem to have as big a role to play as before. ___ 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
Re: Bundle Identifiers - and application support directory
On Jul 10, 2013, at 7:01 AM, Peter Hudson wrote: Now I can set an ID, the docs suggest the format com.companyDomainName.appName for the directory name in Application Support. I notice that very few other applications use this format - they tend to use just the name of the app. Is there a good reason to follow the suggested naming convention ? For what it's worth, my apps all used to use the application name, but are moving to using the bundle identifier. One good reason to use it is that it's unique and consistent with file names elsewhere, such as in the Preferences folder. It's not major, but it certainly makes sense to me. One *downside* to using it: if your application uses your app's name as a file extension for document packages, your app support folder becomes a file package as well. Oops. My guess is, like Quincey's, that Application Support should never be opened by a user (see the fact that ~/Library is completely hidden now) and Apple decided to change the convention. Either way, it's not important to anything AFAICT. -- Seth Willits ___ 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
