Some clarification via the documentation and also this StackExchange answer from 2008:
https://stackoverflow.com/questions/121147 macOS `DocumentPackages` do not need an internal `Info.plist`; rather, filetypes are registered with the operating system via the `Info.plist` of an application that supports given filetypes. It seems like once a `DocumentPackage` extension is registered with the operating system, Spotlight will automatically set the Uniform Type Indicator “com.apple.bundle” and/or “com.apple.package” under `kMDItemContentTypeTree`. For example, if you append `.rtfd` to an arbitrary directory, then run `mdls` against it, among other output you should see: > kMDItemContentType = "com.apple.rtfd" > kMDItemContentTypeTree = ( > "com.apple.rtfd", > "com.apple.package", > "public.directory", > "public.item", > "public.composite-content", > "public.content" > ) It’s been a while since I’ve run into the issue, but if I remember correctly it’s possible to have a directory with a known package extension and have the operating system not recognize the directory as a package if you bring the directory over from another filesystem. I believe the above information is stored as an extended attribute under `com.apple.metadata:kMDItemContentType` and `com.apple.metadata:kMDItemContentType`, but I’m not 100% sure. Obviously an extension to the MIME standard shouldn’t use Apple’s internal extended attributes. At the same time, some degree of cross-compatibility on the Linux end would be nice, and an extension to the MIME standard would be more likely to be supported on the macOS and iOS end (i.e. at a bare minimum not mangling any packages following such a standard). Anyway, the way that macOS applications register package types seems very closely analogous to the way `.desktop` files register MIME types. That said, it could be nice if packages could “self-register” using internal `.desktop` files, albeit obviously without the the `Exec` key.
