30927725: UTType - Missing kUTTypeIconFileKey

[openradar-mirror]

Description

Summary:

The dictionary returned by UTTypeCopyDeclaration used to contain a value for the kUTTypeIconFileKey key, for types with an associated icon file.

On Sierra, this key is no longer present in the dictionary, meaning we cannot retrieve icons for a specific file type.

Some types actually contains a value for a key named _LSIconPath.

As an example, from /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist and looking at the declaration for public.data in UTExportedTypeDeclarations, we can see the associated icon with the key UTTypeIconFile and the value GenericDocumentIcon.icns.

So the declaration is correct.

---

Steps to Reproduce:

CFShow( UTTypeCopyDeclaration( kUTTypeData ) );

---

Expected Results:

The UTTypeIconFile key should be present in the dictionary.

---

Actual Results:

Dictionary looks like:

{ UTTypeConformsTo = ( "public.item" ); UTTypeDescription = data; UTTypeIdentifier = "public.data"; UTTypeTagSpecification = { "public.mime-type" = ( "application/octet-stream" ); }; "_LSIconPath" = "Contents/Resources/GenericDocumentIcon.icns"; }

Instead of UTTypeIconFile, there's now a _LSIconPath key.

---

Version:

macOS Sierra 10.12.4 Beta (16E183b)

---

Update from Developer Bug Reporting Team:

We have determined that this is an issue for you to resolve.

To get the icon for a UTI, use [[NSWorkspace sharedWorkspace] iconForFileType:@"Your UTI Here"]. You should not attempt to read the icon file directly as your process may not have read access at that location.

We are closing this bug report.

If you have questions about the resolution, or if this is still a critical issue for you, then please update your bug report with that information.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.

---

Update from myself:

Sorry, but respectfully disagree. This is clearly a bug. I'm perfectly aware of NSWorkspace, and that does not solve the problem at all...

• NSWorkspace is an Objective-C API, while UTIs can be used in C.
• One can need an icon for a specific UTI, without knowing the exact file extension (same type may have multiple extensions).

More important, the official documentation still mentions kUTTypeIconFileKey can be used to retrieve the UTI's associated icon. If you want to get rid of it, then officially deprecate this symbol, and give developers some time to react, rather than remove the feature on a minor macOS update... Otherwise, you just might break existing software that relies on features you advertise in your official documentation.

Regards,

---

Update from Apple Developer Relations:

Thanks for your update.

We are reopening this report, and we'll see if any further action is possible.

If you have questions, please update your report at:

http://bugreport.apple.com

---

Update from Apple Developer Relations:

Engineering has provided the following information regarding this issue:

• NSWorkspace is an Objective-C API, while UTIs can be used in C.

Many Apple APIs are written in Objective-C. An app that is primarily written in C can still use them.

• One can need an icon for a specific UTI, without knowing the exact file extension (same type may have multiple extensions).

The API we suggested takes a UTI as input.

If you want to get rid of it, then officially deprecate this symbol, and give developers some time to react, rather than remove the feature on a minor macOS update...

This behaviour was changed in macOS Sierra GM, not a minor update.

---

Update from myself:

Well, I was not aware this behaviour was changed as early as the Sierra GM. Then of course it is not a minor update.

I know I can pass a UTI string to NSWorkspace, or I can use objc_msgSend from C. It was just easier to have this information directly available from the UTI's declaration dictionary. Oh well...

Anyway, this is obviously not critical. But you should then really update the documentation accordingly if you don't want duplicate reports on this topic... : )

- Product Version: Created: 2017-03-08T20:49:49.732240 Originated: 2017-03-08T21:47:00 Open Radar Link: http://www.openradar.me/30927725

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-10T21:50:01.009140

[openradar-mirror]

Modified: 2017-03-13T19:57:33.424980

[openradar-mirror]

Modified: 2017-03-13T19:57:33.424980

[openradar-mirror]

Modified: 2017-03-13T19:57:33.424980

[openradar-mirror]

Modified: 2017-03-13T19:57:33.424980

[openradar-mirror]

Modified: 2017-03-15T20:04:07.896520

[openradar-mirror]

Modified: 2017-03-15T20:04:07.896520

[openradar-mirror]

Modified: 2017-03-15T20:04:07.896520

[openradar-mirror]

Modified: 2017-03-15T20:04:07.896520

[openradar-mirror]

Modified: 2017-03-15T20:04:07.896520

[openradar-mirror]

Modified: 2017-03-15T20:04:07.896520