I am distributing my (heavily edited in the picture below) app via a read-only installer DMG. Both the app and the DMG are signed and pass the Gateway validation. My build machine is an El Capitan 10.11.6.
On Sierra (10.12) only, after mounting the DMG, this is what Finder shows me (except the popup on the left that, of course, I trigger afterwards):
As you can see:
- the
Applicationsicon is not what one would expect; right-click->Get Infoshows the expected icon for the alias (at the upper-side as well as underPreview).
Force-quitting Finder will rectify this situation.
I downloaded a Skype for Mac kit, knowing that it uses the same deployment mechanism. Interestingly, the Applications icon is properly shown from the get-go.
Another interesting aspect is that hitting Get Info on my DMG's Applications alias will display (at the bottom of the window) the Sharing & Permissions section, while the Skype one won't.
Details that may be relevant: my DMG is created using a "template" one, that I am modifying, then cloning and making the clone read-only. The alias placed on the template image is an alias that I created on my system and simply copied it there.
I would appreciate any idea on what I am doing wrong. Thank you. [Question updated below, left this one for consistency purposes.]
[UPDATE] Found this SOV thread, which seems to suggest that I am not doing anything wrong per-se. Is there any work-around, e.g. relaunching Finder programmatically after it opens the window (AppleScript)? Or something even less ugly? I wouldn't bet my $ on Apple fixing this anytime soon, as Finder "fetching" apps "in a hurry" and showing the strike-through circle over their icon as if they were broken, while they were not in fact, was a long-standing issue.
Best Answer
My original comment: It looks like you're using a Finder alias to the Applications, rather than a unix-style symbolic link. Aliases store a lot of info about the original item on the computer it was created on, which sometimes confuses things when they're moved to another computer. Try creating a symlink instead, with something like
ln -s /Applications /Volumes/QST-6.5-devel-setup/Applications-- that might be better-behaved.Here's a more detailed comparison of the two:
The Finder's Info window lists them both as "Kind: Alias", but only the true alias has a "Select New Original" button. Also, the symlink is much smaller, since true aliases include all sorts of information about the original item (the file's file ID number (inode) and name, the file ID and path of the folder it was in, info about what volume it was on, if the volume was a disk image or network volume, it'll have info about how to remount the volume, ...). My example alias, at 612 bytes, is much smaller than yours, probably because it was made under Sierra, and I think Sierra may've changed the format a little. The symlink, by comparison, is only 13 bytes -- it's really just the text "/Applications" (which is 13 characters).
The difference in the amount of info they have has important implications for how they work. True aliases are much more robust: you can rename a file, or move it to a different folder, and the alias can still find it by file ID; on the other hand, if you delete & replace it, it'll find the replacement by name & folder. A symlink, on the other hand, is more fragile: if you move or rename the original file, the symlink has no info at all that can help locate it.
But for portability, the lack of additional info in a symlink is actually a real advantage: on a different computer, the everything will have a different file ID, the volume info will obviously different, etc. Worse, some completely other file might have the same ID as the original had on your computer, and the alias might(*) resolve to it! All that extra information is really just creating opportunities for confusion. But the Applications folder will always be at "/Applications", so the symlink will always resolve to it, with no possibility for confusion.
(*) [Edit:] A long time ago, if an alias resolved to one file by file ID and a different file by folder&name, the ID match would take precedence. Apple switched the priority a while back -- either in an early OS X version or maybe even a late Mac OS 9 version, I don't remember -- so now the file ID should really only cause trouble if nothing exists at the "right" path. But if you create a true alias to, say, /Library/Application Support/YourApp, and that doesn't exist on some other computer, it might resolve to any other file or folder that happens to have the same file ID.
There's another difference I forgot to mention: all of the file access APIs in OS X know how to resolve symlinks, so they work great with both GUI apps and command-line and ported unix tools. True aliases, on the other hand, are only understood by the Cocoa and Carbon APIs (basically, the Apple-proprietary GUI programming environments), so command-line tools (which use plain POSIX APIs) just see them as files, and have no clue how to resolve them to the original item. This isn't relevant in your situation, but I thought I should add it for completeness.