Licenses & Certificate page

The Licences & Certificate page can be used to:

• designate the license number(s) that you want to integrate into your single-user stand-alone application
• sign the application by means of a certificate under OS X.

This page displays the list of available deployment licenses that you can integrate into your application. By default, the list is empty. You must explicitly add your 4D Developer Professional license as well as each 4D Desktop Volume license to be used in the application built. You can add another 4D Developer Professional number and its associated licenses other than the one currently being used.

To remove or add a license, use the [+] and [-] buttons at the bottom of the window. 

When you click on the [+] button, an open file dialog box appears displaying by default the contents of the [Licenses] folder of your machine. For more information about the location of this folder, refer to Licenses Folder in the description of the Get 4D folder command.

You must designate the files that contain your Developer license as well as those containing your deployment licenses. These files were generated or updated when the 4D Developer Professional license and the 4D Desktop Volume licenses were purchased. 

Once you have selected a file, the list will indicate the characteristics of the license that it contains:

• License #: product license number
• License: name of the product
• Expiration date: expiration date of the license (if any)
• Path: location on disk

If the license is not valid, a message will warn you of this. 

You can designate as many valid files as you want. When building an executable application, 4D will use the most appropriate license available.

Note: Dedicated "R" licenses are now required to build applications based upon "R-release" versions (license numbers for "R" products start with "R-4DDP").

After the application is built, a new deployment license file is automatically included in the Licenses folder next to the executable application (Windows) or in the package (Mac OS).

The application builder can sign merged 4D applications under OS X (single-user applications, 4D Server and client parts under OS X). Signing an application authorizes it to be executed using the Gatekeeper functionality of OS X when the "Mac App Store and identified Developers" option is selected (see "About Gatekeeper" below).

• Check the Sign application option to include certification in the application builder procedure for OS X. 4D will check the availability of elements required for certification when the build occurs:
  
  This option is displayed under both Windows and OS X, but it is only taken into account for OS X versions.

• Name of certificate: Enter the name of your developer certificate validated by Apple in this entry area. The certificate name is usually the name of the certificate in the Keychain Access utility:
  

To obtain a developer certificate from Apple, Inc., you can use the commands of the Keychain Access menu or go here: http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

Note: This certificate requires the presence of the Apple codesign utility, which is provided by default and usually located in the “/usr/bin/” folder. If an error occurs, make sure that this utility is present on your disk.

Gatekeeper is a security feature of OS X that controls the execution of applications downloaded from the Internet. The Mac App Store and identified Developers option is selected by default starting with OS X 10.8 Mountain Lion (Apple does not recommend selecting the lowest level "Anywhere" option). If a downloaded application does not come from the Apple Store or is not signed, it is rejected and cannot be launched. 

The Sign application option of the 4D application builder lets you generate applications that are compatible with this option by default.

Specifications concerning Gatekeeper evolve with each version of OS X. More specifically, codesign signatures are either type "v1" and/or "v2" depending on the OS where they are generated. On the Gatekeeper side, "v1" or "v2" signatures are accepted based on the OS where the final application is executed. The following table summarizes the principles of compatibility: