{"id":74,"date":"2008-07-03T19:06:18","date_gmt":"2008-07-04T00:06:18","guid":{"rendered":"http:\/\/vgable.com\/blog\/2008\/07\/03\/nsapplicationname-inconsistencies\/"},"modified":"2010-01-20T13:37:19","modified_gmt":"2010-01-20T18:37:19","slug":"nsapplicationname-inconsistencies","status":"publish","type":"post","link":"https:\/\/vgable.com\/blog\/2008\/07\/03\/nsapplicationname-inconsistencies\/","title":{"rendered":"NSApplicationName Inconsistencies"},"content":{"rendered":"<p>The value stored under the <code>NSApplicationName<\/code> key of the result of <a href=\"http:\/\/developer.apple.com\/documentation\/Cocoa\/Reference\/ApplicationKit\/Classes\/NSWorkspace_Class\/Reference\/Reference.html#\/\/apple_ref\/occ\/instm\/NSWorkspace\/activeApplication\"><code>[[NSWorkspace sharedWorkspace] activeApplication]<\/code><\/a> is not the always the name the user knows the application by.  Worse, it&#8217;s not always the same as the name for the application that other APIs expect or return.  Even <code>fullPathForApplication:<\/code> in NSWorkspace sometimes won&#8217;t recognize it!<\/p>\n<blockquote><p>\nThe problem stems from the fact that there are at least five application names floating around, at least in concept: (1) the file name the Finder sees, which in the case of an application package is the package (bundle) name; (2) the name of the executable inside the package, (3) the long name used in many places for display purposes only; (4) the short name used as the application menu title and in a few other places where a long name won&#8217;t fit for display purposes; and (5) the process name of a running application. They aren&#8217;t always the same, especially in Microsoft and Adobe products.\n<\/p><\/blockquote>\n<p>&#8211;From <a href=\"http:\/\/www.cocoabuilder.com\/archive\/message\/cocoa\/2003\/8\/24\/2349\">an informative message<\/a> by <a href=\"http:\/\/www.quecheesoftware.com\/\">Bill Cheeseman<\/a>.<\/p>\n<p>So instead of relying on <code>NSApplicationName<\/code> I now use <code> <a href=\"http:\/\/developer.apple.com\/documentation\/Cocoa\/Reference\/Foundation\/Classes\/NSFileManager_Class\/Reference\/Reference.html#\/\/apple_ref\/occ\/instm\/NSFileManager\/displayNameAtPath:\">-[[NSFileManager defaultManager] displayNameAtPath:]<\/a><\/code>  then strip off the filename extension.  This should give exactly the filename the user sees.  Every time.<\/p>\n<p><code><br \/>\nNSDictionary *appInfo = [[NSWorkspace sharedWorkspace] activeApplication];<br \/>\nNSString *appPath = [appInfo objectForKey:@\"NSApplicationPath\"];<br \/>\nNSString     *name = [[[NSFileManager defaultManager] displayNameAtPath:appPath] stringByDeletingPathExtension];<\/code><\/p>\n<p><strong><a href=\"http:\/\/developer.apple.com\/documentation\/CoreFoundation\/Conceptual\/CFBundles\/Tasks\/locating.html#\/\/apple_ref\/doc\/uid\/20001123-123081\">And of course, you really should be using bundle identifiers, instead of names, to identify an application.<\/a><\/strong>  Unfortunately, a <em>very few<\/em> applications are not bundles.  (For example, Microsoft stuff prior to Office 2008), so it <em>might<\/em> be necessary to fall back on using a name to locate them in a path-independent way.<\/p>\n<p>Creating a custom <code>CFBundleName<\/code> in an application&#8217;s <code>info.plist<\/code> file seems to confuse <code>NSApplicationName<\/code>.  For this reason I don&#8217;t think setting it is a good idea.<\/p>\n<p>UPDATE 2010-01-20: See also, <a href=\"https:\/\/developer.apple.com\/mac\/library\/qa\/qa2007\/qa1544.html\"><cite>Technical Q&#038;A QA1544: Obtaining the localized application name in Cocoa<\/cite><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>The value stored under the NSApplicationName key of the result of [[NSWorkspace sharedWorkspace] activeApplication] is not the always the name the user knows the application by. Worse, it&#8217;s not always the same as the name for the application that other APIs expect or return. Even fullPathForApplication: in NSWorkspace sometimes won&#8217;t recognize it! The problem stems [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18,6,3,5,4,13],"tags":[161,279,68,159],"class_list":["post-74","post","type-post","status-publish","format-standard","hentry","category-bug-bite","category-cocoa","category-macosx","category-objective-c","category-programming","category-sample-code","tag-file-systems","tag-mac-os-x","tag-nsapplicationname","tag-paths"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/74","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=74"}],"version-history":[{"count":2,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/74\/revisions"}],"predecessor-version":[{"id":560,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/74\/revisions\/560"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=74"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=74"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=74"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}