Undocumented MacOS X Deployment Options

[icouto]

Hi all! I'm trying to understand the deployment options that we have available for MacOS X, in the 'Standalone Application Settings' dialogue - but I'm getting stuck. There seem to be options that are not documented anywhere (I've looked through the User Guide, online docs, lessons and tutorials), but nothing.

So, I thought I'd try the experts here at the Forum:

• In the PLIST section of the dialogue, there is a field titled 'Signature' (under a 'Name' field), with a default value of "????" in it. What is it? Is this related to code signature? Do we have to manually produce a code signature?

• Still in the PLIST section, we have a 'Document Type' field, and a 'Document Extension' field. I'm guessing that 'document extension' should be a list of 3- or 4-letter extensions that my app is supposed to support, correct? - e.g., 'txt', 'gif', 'jpg', 'jpeg', etc. But what about 'document type'? Are there pre-defined values that should go there? What about if I want my app to support its own custom document type? - e.g., 'abcd' extension for "ABCD Document'?

• There is a field at the top of the dialogue for 'Application Icon' and under that one for 'Document Icon'. What happens if my app produces more than one type of document - which should have different icons? Do I have to then manually open the PLIST and edit values directly?

Any guidance is truly appreciated!

[jacque]

• In the PLIST section of the dialogue, there is a field titled 'Signature' (under a 'Name' field), with a default value of "????" in it. What is it? Is this related to code signature? Do we have to manually produce a code signature?

This is a remnant of OS 9 where app signatures needed to be registered with Apple. That was abandoned in OS X, so you can leave the default ???? in there. It is still possible to assign a signature if you already have one for the app, but OS X looks at the extension first and doesn't use the signature unless all else fails.

• Still in the PLIST section, we have a 'Document Type' field, and a 'Document Extension' field. I'm guessing that 'document extension' should be a list of 3- or 4-letter extensions that my app is supposed to support, correct? - e.g., 'txt', 'gif', 'jpg', 'jpeg', etc. But what about 'document type'? Are there pre-defined values that should go there? What about if I want my app to support its own custom document type? - e.g., 'abcd' extension for "ABCD Document'?

The document type is similar to the app signature, a four-character type code used by OS 9. It can be blank or ???? (all types.) The extension is how OS X identifies which document types your app can use. You would list those here. If you have a custom document type, put that extension here instead and be sure your app writes files with that extension. Extensions can be longer than 4 chars, LC uses ".livecode" for example.

• There is a field at the top of the dialogue for 'Application Icon' and under that one for 'Document Icon'. What happens if my app produces more than one type of document - which should have different icons? Do I have to then manually open the PLIST and edit values directly?

Yes, but you can't edit the plist after you've built the standalone because that will destroy the security signature. Instead, copy the plist and edit it in a text editor, then include it in Copy Files. The standalone builder will use your edited copy instead of its default one. I believe if you are using standard formats like PNG, TXT, etc, you don't need to include icons for those because the OS already has them. You only need the ones that are unique to your app.

[icouto]

Thank you for your wonderful guidance, @jaqcue! Just to confirm: if I'm not at all concerned with OS 9, I can safely leave the 'signature' and 'document type' fields alone, and all should work fine in OS X?

[jacque]

Right, you can ignore those fields.

[thatkeith]

Yes, but you can't edit the plist after you've built the standalone because that will destroy the security signature. Instead, copy the plist and edit it in a text editor, then include it in Copy Files. The standalone builder will use your edited copy instead of its default one.

Reviving an old thread as it seems to be utter gold, and I just want to check a detail...

So should I copy the ENTIRE plist data from a standalone, add <string>jpg</string> (for example, to open .jpg files) between <array> and </array> for the CFBundleTypeExtensions key, save that as a new text file with .plist as the filename suffix, and include that in Copy Files for my new standalone? This seems necessary if the standalone builder will use this rather than make its own.

The info at https://lessons.livecode.com/m/4071/l/1 ... le-onto-it is helpful but not fully clear. (It also doesn't warn users about the security signature issue.) Your comment implies that I need to provide the entire plist data, not just the customised <dict> ... </dict> structure that is shown in that above LC lesson. Also, looking at the plist data from an existing standalone, it appears that I just need to add my <string>SUFFIX</string> line between the existing <array> and </array> of the CFBundleTypeExtensions key.

If this is correct I have one further question: to add more file type extensions do I simply make additional <string>SUFFIX</string> entries?

k

[jacque]

Yes, you've got the right idea. Create a new revised file and put it into Copy Files. I generally edit the whole file. LC allows you to create a file that includes only the changes for an Android manifest but I'm not sure if that also applies to plist files so I play it safe and just use the whole thing.

Can't answer how to include more file types but your idea seems reasonable. Google probably knows.

[richmond62]

If you are concernced with Mac OS 9 you won't get very far with recent versions of LiveCode,
so the standalone build settings need a bit of tidying up.