Info Plist Mac

Mar 10, 2016 - 4 Comments. Plist files contain preference specifics and properties relevant to a particular application or portion of Mac OS X system software. Depending on where the plist file is located and what function they serve, they can either be in XML format, binary format, and sometimes even json. For users who need to modify a plist file or convert the file format to or from XML and binary, you can do so easily in the OS X Terminal with the help of the plutil command. Step1: sudo cp /Applications/Utilities/Boot Camp Assistant.app/Contents/Info.plist Desktop/Info.plist.bak. Step2: sudo nano /Applications/Utilities/Boot Camp Assistant.app/Contents/Info.plist. Step3: enter to my Boot ROM version in set of strings. Its inside About this Mac / system report /harware overview. Mac OS needs to 'reload' the Info.plist, otherwise the changes don't count. That's completely stupid and silly, and it tool me ages to figure it out. Share improve this answer follow answered Nov 19 '15 at 7:20. JPFrancoia JPFrancoia. 3,078 2 2 gold badges 25 25 silver badges 52 52 bronze badges. Question: Q: How do I edit the info.plist on OSX 10.11.2 More Less. This site contains user submitted content, comments and opinions and is for informational purposes only. Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not.

• Info.plist Mac
• Info.plist Mac Location
• Macos Plist
• Edit Plist Files Mac
• Info Plist Localization

An information property list file is a structured text file that contains essential configuration information for a bundled executable. The file itself is typically encoded using the Unicode UTF-8 encoding and the contents are structured using XML. The root XML node is a dictionary, whose contents are a set of keys and values describing different aspects of the bundle. The system uses these keys and values to obtain information about your app and how it is configured. As a result, all bundled executables (plug-ins, frameworks, and apps) are expected to have an information property list file.

By convention, the name of an information property list file is Info.plist. This name of this file is case sensitive and must have an initial capital letter I. In iOS apps, this file resides in the top-level of the bundle directory. In macOS bundles, this file resides in the bundle’s Contents directory. Xcode typically creates this file for you automatically when you create a project of an appropriate type.

Important: In the sections that follow, pay attention to the capitalization of files and directories that reside inside a bundle. The NSBundle class and Core Foundation bundle functions consider case when searching for resources inside a bundle directory. Case mismatches could prevent you from finding your resources at runtime.

Creating and Editing an Information Property List File

The simplest way to create an information property list file is to let Xcode create it for you. Each new bundle-based project that you create in Xcode comes with a file named <project>-Info.plist, where <project> is the name of the project. At build time, this file is used to generate the Info.plist file that is then included in the resulting bundle.

To edit the contents of your information property list file, select the <project>-Info.plist file in your Xcode project to display the property list editor. Figure 1 shows the editor for the information property list file of a new Cocoa app project. The file created by Xcode comes preconfigured with keys that every information property list should have.

To edit the value for a specify key, double-click the value in the Xcode property list editor to select it, then type a new value. Most values are specified as strings but Xcode also supports several other scalar types. You can also specify complex types such as an array or dictionary. The property list editor displays an appropriate interface for editing each type. To change the type of a given value, make sure the value is not selected and Control-click it to display its contextual menu. From the Value Type submenu, select the type you want to use for the value.

Because information property lists are usually just text files, you can also edit them using any text editor that supports the UTF-8 file encoding. Because they are XML files, however, editing property list files manually is generally discouraged.

Adding Keys to an Information Property List File

Although the Info.plist file provided by Xcode contains the most critical keys required by the system, most apps should typically specify several additional keys. Many subsystems and system apps use the Info.plist file to gather information about your app. For example, when the user chooses File > Get Info for your app, the Finder displays information from many of these keys in the resulting information window.

You add keys to your app’s Info.plist using the Xcode property list editor. For information about how to use this editor, see “Edit property lists.”

Important: The property list editor in Xcode displays human-readable strings (instead of the actual key name) for many keys by default. To display the actual key names as they appear in the Info.plist file, Control-click any of the keys in the editor window and enable the Show Raw Keys/Values item in the contextual menu.

For a list of the recommended keys you should include in a typical app, see Recommended Info.plist Keys.

Localizing Property List Values

The values for many keys in an information property list file are human-readable strings that are displayed to the user by the Finder or your own app. When you localize your app, you should be sure to localize the values for these strings in addition to the rest of your app’s content.

Localized values are not stored in the Info.plist file itself. Instead, you store the values for a particular localization in a strings file with the name InfoPlist.strings. You place this file in the same language-specific project directory that you use to store other resources for the same localization. The contents of the InfoPlist.strings file are the individual keys you want localized and the appropriately translated value. The routines that look up key values in the Info.plist file take the user’s language preferences into account and return the localized version of the key (from the appropriate InfoPlist.strings file) when one exists. If a localized version of a key does not exist, the routines return the value stored in the Info.plist file.

For example, the TextEdit app has several keys that are displayed in the Finder and thus should be localized. Suppose your information property list file defines the following keys:

The French localization for TextEdit then includes the following strings in the InfoPlist.strings file of its Contents/Resources/French.lproj directory:

For more information about the placement of InfoPlist.strings files in your bundle, see Bundle Programming Guide. For information about creating strings files, see Resource Programming Guide. For additional information about the localization process, see Internationalization and Localization Guide.

Creating Platform- and Device-Specific Keys

You can designate a key in an Info.plist file as applying to a specific platform, a specific device type, or both. To create a platform- or device-specific key variant, combine a root key name with one or two qualifiers, using the following pattern:

key_root-<platform>~<device>

In this pattern, the key_root portion represents the original name of the key, as you find it in this document. The <platform> and <device> portions are optional and restrict the key’s applicability to a specific platform or device type. Notice that if you employ a platform qualifier, connect it with a hyphen (-), and if you employ a device qualifier, connect it with a tilde (~).

Use of a device qualifier is much more common than is use of a platform qualifier.

For a device qualifier, you can use one of the following values:

• iphone The key applies to iPhone devices only

• ipod The key applies to iPod touch devices only

• ipad The key applies to iPad devices only

For a platform qualifier, you can specify a value of iphoneos or macos depending on which of these two platforms you are targeting.

When specifying a key variant, do so in addition to employing a corresponding key without any qualifiers, thereby ensuring you provide a reasonable default value. When the system searches for a key in your app’s Info.plist file, it chooses the key that is most specific to the current device and platform. If it does not find a qualified key, it looks for one without qualifiers. For example, to specify support for all device orientations on iPad, and three orientations for iPhone, the Xcode templates specify the corresponding keys in an app’s Info.plist file:

Custom Keys

iOS and macOS ignore custom keys you include in an Info.plist file. If you want to include app-specific configuration information in your Info.plist file, you can do so freely as long as your key names do not conflict with the ones Apple uses. When defining custom key names, prefix them with a unique prefix, such as your app’s bundle ID or your company’s domain name, to prevent conflicts.

Gita Vivrutti of Raghavendratirtha Item Preview remove-circle Share or Embed This Item. EMBED (for wordpress.com hosted blogs and archive.org item tags) Want more? Advanced embedding details, examples, and help! Geeta vivrutti pdf download. Sangraha.Another work- Geetartha Sangraha- which is better known as Geeta Vivrutti is a commentary on the Gita, while the Prameya Deepika Vyakhya is a commentary on Madhvacharya’s Geeta Bhashya Geeta Tatparya Teeka Vivarana is a commentary on Jayatheertha’s commentary of Madhwa’s Geeta Tatparya.

Recommended Info.plist Keys

Each of the Xcode application templates includes an Info.plist file, but you can also construct one from scratch. When creating an information property list file, there are several keys you should always include. These keys are almost always accessed by the system and providing them ensures that the system has the information it needs to work with your app effectively.

Recommended Keys for iOS Apps

It is recommended that an iOS app include the following keys in its information property list file. Most are set by Xcode automatically when you create your project.

In addition to these keys, there are several that are commonly included:

• UIRequiredDeviceCapabilities (required)

For descriptions of these keys, see the other chapters of this book.

Recommended Keys for Cocoa Apps

It is recommended that a Cocoa app include the following keys in its information property list file. Most are set by Xcode automatically when you create your project but some may need to be added.

These keys identify your app to the system and provide some basic information about the services it provides. Cocoa apps should also include the following keys to identify key resources in the bundle:

Note: If you are building a Cocoa app using an Xcode template, the NSMainNibFile and NSPrincipalClass keys are typically already set in the template project.

For descriptions of these keys, see the other chapters of this book.

Commonly Localized Keys

In addition to the recommended keys, there are several keys that should be localized and placed in your language-specific InfoPlist.strings files:

For more information about localizing information property list keys, see Localizing Property List Values.

Copyright © 2018 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2018-06-04

The Core Foundation framework provides the underlying infrastructure for bundles, including the code used at runtime to load bundles and parse their structure. As a result, many of the keys recognized by this framework are fundamental to the definition of bundles themselves and are instrumental in determining the contents of a bundle.

Core Foundation keys use the prefix CF to distinguish them from other keys. For more information about Core Foundation, see Core Foundation Framework Reference.

Key Summary

Table 1 contains an alphabetical listing of Core Foundation keys, the corresponding name for that key in the Xcode property list editor, a high-level description of each key, and the platforms on which you use it. Detailed information about each key is available in later sections.

CFAppleHelpAnchor

CFAppleHelpAnchor (String - macOS) identifies the name of the bundle’s initial HTML help file, minus the .html or .htm extension. This file must be located in the bundle’s localized resource directories or, if the help is not localized, directly under the Resources directory.

CFBundleAllowMixedLocalizations

CFBundleAllowMixedLocalizations (Boolean - iOS, macOS) specifies whether the bundle supports the retrieval of localized strings from frameworks. This key is used primarily by Foundation tools that link to other system frameworks and want to retrieve localized resources from those frameworks.

CFBundleDevelopmentRegion

CFBundleDevelopmentRegion (String - iOS, macOS) specifies the default language and region for the bundle, as a language ID. For example, English for Australia has the language ID en-AU. The system uses this value if it cannot locate a resource for the user’s preferred language.

For more information, see Language IDs in Internationalization and Localization Guide. For details on how a bundle finds localized resources, see The Bundle Search Pattern in Bundle Programming Guide.

CFBundleDisplayName

CFBundleDisplayName (String - iOS, macOS) specifies the display name of the bundle, visible to users and used by Siri. If you support localized names for your bundle, include this key in your app’s Info.plist file and in the InfoPlist.strings files of your app’s language subdirectories. If you localize this key, include a localized version of the CFBundleName key as well.

Because Siri uses the value of this key, always provide a value, whether or not you localize your app.

In macOS, before displaying a localized name for your bundle, the Finder compares the value of this key against the actual name of your bundle in the file system. If the two names match, the Finder proceeds to display the localized name from the appropriate InfoPlist.strings file of your bundle. If the names do not match, the Finder displays the file-system name.

For more information about display names in macOS, see File System Programming Guide.

CFBundleDocumentTypes

CFBundleDocumentTypes (Array - iOS, macOS) contains an array of dictionaries that associate one or more document types with your app. Each dictionary is called a type-definition dictionary and contains keys used to define the document type. Table 2 lists the keys that are supported in these dictionaries.

The way you specify icon files in macOS and iOS is different because of the supported file formats on each platform. In iOS, each icon resource file is typically a PNG file that contains only one image. Therefore, it is necessary to specify different image files for different icon sizes. However, when specifying icons in macOS, you use an icon file (with extension .icns), which is capable of storing the icon at several different resolutions.

This key is supported in iOS 3.2 and later and all versions of macOS. For detailed information about UTIs, see Uniform Type Identifiers Overview.

Document Roles

An app can take one of the following roles for any given document type:

• Editor. The app can read, manipulate, and save the type.

• Viewer. The app can read and present data of that type.

• Shell. The app provides runtime services for other processes—for example, a Java applet viewer. The name of the document is the name of the hosted process (instead of the name of the app), and a new process is created for each document opened.

• None. The app does not understand the data, but is just declaring information about the type (for example, the Finder declaring an icon for fonts).

The role you choose applies to all of the concrete formats associated with the document or Clipboard type. For example, the Safari app associates itself as a viewer for documents with the “.html”, “.htm”, “shtml, or “jhtml” filename extensions. Each of these extensions represents a concrete type of document that falls into the overall category of HTML documents. This same document can also support MIME types and legacy 4-byte OS types.

Document Icons

In iOS, the CFBundleTypeIconFiles key contains an array of strings with the names of the image files to use for the document icon. Table 3 lists the icon sizes you can include for each device type. You can name the image files however you want but the file names in your Info.plist file must match the image resource filenames exactly. (For iPhone and iPod touch, the usable area of your icon is actually much smaller.) For more information on how to create these icons, see iOS Human Interface Guidelines.

In macOS, the CFBundleTypeIconFile key contains the name of an icon resource file with the document icon. An icon resource file contains multiple images, each representing the same document icon at different resolutions. If you omit the filename extension, the system looks for your file with the extension .icns. You can create icon resource files using the Icon Composer app that comes with Xcode Tools.

Recommended Keys

The entry for each document type should contain the following keys:

• CFBundleTypeIconFile

• CFBundleTypeName

• CFBundleTypeRole

In addition to these keys, it must contain at least one of the following keys:

• LSItemContentTypes

• CFBundleTypeExtensions

• CFBundleTypeMIMETypes

• CFBundleTypeOSTypes

If you do not specify at least one of these keys, no document types are bound to the type-name specifier. You may use all three keys when binding your document type, if you so choose. In macOS 10.4 and later, if you specify the LSItemContentTypes key, the other keys are ignored. You can continue to include the other keys for compatibility with older versions of the system, however.

CFBundleExecutable

CFBundleExecutable (String - iOS, macOS) identifies the name of the bundle’s main executable file. For an app, this is the app executable. For a loadable bundle, it is the binary that will be loaded dynamically by the bundle. For a framework, it is the shared library for the framework. Xcode automatically adds this key to the information property list file of appropriate projects.

For frameworks, the value of this key is required to be the same as the framework name, minus the .framework extension. If the keys are not the same, the target system may incur some launch-performance penalties. The value should not include any extension on the name.

Important: You must include a valid CFBundleExecutable key in your bundle’s information property list file. macOS uses this key to locate the bundle’s executable or shared library in cases where the user renames the app or bundle directory.

CFBundleHelpBookFolder

CFBundleHelpBookFolder (String - macOS) identifies the folder containing the bundle’s help files. Help is usually localized to a specific language, so the folder specified by this key represents the folder name inside the .lproj directory for the selected language.

CFBundleHelpBookName

Info.plist Mac

CFBundleHelpBookName (String - macOS) identifies the main help page for your app. This key identifies the name of the Help page, which may not correspond to the name of the HTML file. The Help page name is specified in the CONTENT attribute of the help file’s META tag.

CFBundleIconFile

CFBundleIconFile (String - iOS, macOS) identifies the file containing the icon for the bundle. The filename you specify does not need to include the extension, although it may. The system looks for the icon file in the main resources directory of the bundle.

If your Mac app uses a custom icon and the asset name for the icon isn’t set in CFBundleIconName, you must specify the CFBundleIconFile property. If you do not specify this property, the system (and other apps) display your bundle with a default icon.

Note: If you are writing an iOS, tvOS, or watchOS app, use of the CFBundleIcons key instead of this one.

CFBundleIconFiles

CFBundleIconFiles (Array - iOS) contains an array of strings identifying the icon files for the bundle. (It is recommended that you always create icon files using the PNG format.) When specifying your icon filenames, it is best to omit any filename extensions. Omitting the filename extension lets the system automatically detect high-resolution (@2x) versions of your image files using the standard-resolution image filename. If you include filename extensions, you must specify all image files (including the high-resolution variants) explicitly. The system looks for the icon files in the main resources directory of the bundle.

The CFBundleIcons key takes precedence over this key in iOS 5.0 and later. This key takes precedence over the CFBundleIconFile key.

This key is supported in iOS 3.2 and later only and an app may have differently sized icons to support different types of devices and different screen resolutions. In other words, an app icon is typically 57 x 57 pixels on iPhone or iPod touch but is 72 x 72 pixels on iPad. Icons at other sizes may also be included. The order of the items in this array does not matter. The system automatically chooses the most appropriately sized icon based on the usage and the underlying device type.

For information about how to create icons for your apps, including the size information for each one, see iOS Human Interface Guidelines.

CFBundleIcons

CFBundleIcons (Dictionary - iOS, tvOS) contains information about all of the icons used by the app. This key allows you to group icons based on their intended usage and specify multiple icon files together with specific keys for modifying the appearance of those icons. This dictionary can contain the following keys:

• CFBundlePrimaryIcon—This key identifies the primary icon for the Home screen and Settings app among others. The value for this key is described in Contents of the CFBundlePrimaryIcon Dictionary Entry.

• CFBundleAlternateIcons—This key identifies alternate icons for the Home screen and Settings app among others. The value for this key is described in Contents of the CFBundleAlternateIcons Dictionary Entry.

• UINewsstandIcon—This key identifies default icons to use for apps presented from Newsstand. The value for this key is a dictionary whose contents are described in Contents of the UINewsstandIcon Dictionary.

The CFBundleIcons key is supported in iOS 5.0 and later and in tvOS 9.0 and later. In iOS, you can combine this key with the CFBundleIconFiles and CFBundleIconFile keys but in iOS 5.0 and later, this key takes precedence.

Contents of the CFBundlePrimaryIcon Dictionary Entry

The value of the CFBundlePrimaryIcon key is different in iOS and tvOS:

• In tvOS, the value of this key is a string. The value of the string is the name of an icon file in your app. For information about the icon file for your tvOS app, see “Icons and Images” in Apple TV Human Interface Guidelines

• In iOS, the value of the key is a dictionary. Table 4 lists the keys and values that you include in this dictionary.

When specifying icon filenames, it is best to omit any filename extensions. Omitting the filename extension lets the system automatically detect high-resolution (@2x) versions of your image files using the standard-resolution image filename. If you include filename extensions, you must specify all image files (including the high-resolution variants) explicitly. The system looks for the icon files in the main resources directory of the bundle.

Contents of the CFBundleAlternateIcons Dictionary Entry

The value of the CFBundleAlternateIcons key is different in iOS and tvOS:

• In tvOS, the value of the key is an array of strings. The value of each string is the name of an icon file in your app. For information about the icon file for your tvOS app, see “Icons and Images” in Apple TV Human Interface Guidelines

• In iOS, the value of the key is a dictionary. The key for each dictionary entry is the name of the alternate icon, which is also the string you pass to the setAlternateIconName:completionHandler: method of UIApplication when changing icons. The value for each key is a dictionary containing the keys in Table 5.

Info.plist Mac Location

When specifying icon filenames, it is best to omit any filename extensions. Omitting the filename extension lets the system automatically detect high-resolution (@2x) versions of your image files using the standard-resolution image filename. If you include filename extensions, you must specify all image files (including the high-resolution variants) explicitly. The system looks for the icon files in the main resources directory of the bundle.

Important: If your app contains iPad-specific versions of its icons, the system does not fall back to the alternate icons declared in the platform-agnostic version of CFBundleIcons key. Therefore, if you include any alternate icons in the CFBundleIcons key, you must include them again in your CFBundleIcons~ipad variant.

Contents of the UINewsstandIcon Dictionary

The value for the UINewsstandIcon key is a dictionary that identifies the default icons and style options to use for apps displayed in Newsstand. Table 6 lists the keys that you can include in this dictionary and their values.

When specifying icon filenames, it is best to omit any filename extensions. Omitting the filename extension lets the system automatically detect high-resolution (@2x) versions of your image files using the standard-resolution image filename. If you include filename extensions, you must specify all image files (including the high-resolution variants) explicitly. The system looks for the icon files in the main resources directory of the bundle.

CFBundleIdentifier

CFBundleIdentifier (String - iOS, macOS) uniquely identifies the bundle. Each distinct app or bundle on the system must have a unique bundle ID. The system uses this string to identify your app in many ways. For example, the preferences system uses this string to identify the app for which a given preference applies; Launch Services uses the bundle identifier to locate an app capable of opening a particular file, using the first app it finds with the given identifier; in iOS, the bundle identifier is used in validating the app’s signature.

The bundle ID string must be a uniform type identifier (UTI) that contains only alphanumeric (A-Z,a-z,0-9), hyphen (-), and period (.) characters. The string should also be in reverse-DNS format. For example, if your company’s domain is Ajax.com and you create an app named Hello, you could assign the string com.Ajax.Hello as your app’s bundle identifier.

Note: Although formatted similarly to a UTI, the character set for a bundle identifier is more restrictive.

CFBundleInfoDictionaryVersion

CFBundleInfoDictionaryVersion (String - iOS, macOS) identifies the current version of the property list structure. This key exists to support future versioning of the information property list file format. Xcode generates this key automatically when you build a bundle and you should not change it manually. The value for this key is currently 6.0.

Macos Plist

CFBundleLocalizations

CFBundleLocalizations (Array - iOS, macOS) identifies the localizations handled manually by your app. If your executable is unbundled or does not use the existing bundle localization mechanism, you can include this key to specify the localizations your app does handle.

Each entry in this property’s array is a string identifying the language name or ISO language designator of the supported localization. See “Language and Locale Designations” in Internationalization and Localization Guide in Internationalization Documentation for information on how to specify language designators.

CFBundleName

Edit Plist Files Mac

CFBundleName (String - iOS, macOS) specifies the short name of the bundle, which may be displayed to users in situations such as the absence of a value for CFBundleDisplayName. This name should be less than 16 characters long.

See also CFBundleDisplayName.

CFBundlePackageType

CFBundlePackageType (String - iOS, macOS) identifies the type of the bundle and is analogous to the Mac OS 9 file type code. The value for this key consists of a four-letter code. The type code for apps is APPL; for frameworks, it is FMWK; for loadable bundles, it is BNDL. For loadable bundles, you can also choose a type code that is more specific than BNDL if you want.

All bundles should provide this key. However, if this key is not specified, the bundle routines use the bundle extension to determine the type, falling back to the BNDL type if the bundle extension is not recognized.

CFBundleShortVersionString

CFBundleShortVersionString (String - iOS, macOS) specifies the release version number of the bundle, which identifies a released iteration of the app.

The release version number is a string composed of three period-separated integers. The first integer represents major revision to the app, such as a revision that implements new features or major changes. The second integer denotes a revision that implements less prominent features. The third integer represents a maintenance release revision.

The value for this key differs from the value for CFBundleVersion, which identifies an iteration (released or unreleased) of the app.

This key can be localized by including it in your InfoPlist.strings files.

See also NSHumanReadableCopyright.

CFBundleSpokenName

CFBundleSpokenName (String - iOS, macOS) contains a suitable replacement for the app name when performing text-to-speech operations. Include this key in your app bundle when the spelling of your app might be mispronounced by the speech system. For example, if the name of your app is “MyApp123”, you might set the value of this key to “My app one two three”.

This key is supported in iOS 8 and later and in macOS 10.10 and later.

CFBundleURLTypes

Info Plist Localization

CFBundleURLTypes (Array - iOS, macOS) contains an array of dictionaries, each of which describes the URL schemes (http, ftp, and so on) supported by the app. The purpose of this key is similar to that of CFBundleDocumentTypes, but it describes URL schemes instead of document types. Each dictionary entry corresponds to a single URL scheme. Table 7 lists the keys to use in each dictionary entry.

To learn about the converse operation in iOS of declaring the URL schemes an app can open, read the description of the LSApplicationQueriesSchemes key.

CFBundleVersion

CFBundleVersion (String - iOS, macOS) specifies the build version number of the bundle, which identifies an iteration (released or unreleased) of the bundle.

The build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero—for example, 3.1.2. The string should only contain numeric (0-9) and period (.) characters. Leading zeros are truncated from each integer and will be ignored (that is, 1.02.3 is equivalent to 1.2.3). The meaning of each element is as follows:

• The first number represents the most recent major release and is limited to a maximum length of four digits.

• The second number represents the most recent significant revision and is limited to a maximum length of two digits.

• The third number represents the most recent minor bug fix and is limited to a maximum length of two digits.

If the value of the third number is 0, you can omit it and the second period.

While developing a new version of your app, you can include a suffix after the number that is being updated; for example 3.1.3a1. The character in the suffix represents the stage of development for the new version. For example, you can represent development, alpha, beta, and final candidate, by d, a, b, and fc. The final number in the suffix is the build version, which cannot be 0 and cannot exceed 255. When you release the new version of your app, remove the suffix.

CFPlugInDynamicRegistration

CFPlugInDynamicRegistration (String - macOS) specifies whether how host loads this plug-in. If the value is YES, the host attempts to load this plug-in using its dynamic registration function. If the value is NO, the host uses the static registration information included in the CFPlugInFactories, and CFPlugInTypes keys.

For information about registering plugins, see “Plug-in Registration” in Plug-in Programming Topics.

CFPlugInDynamicRegisterFunction

CFPlugInDynamicRegisterFunction (String - macOS) identifies the function to use when dynamically registering a plug-in. Specify this key if you want to specify one of your own functions instead of implement the default CFPlugInDynamicRegister function.

For information about registering plugins, see “Plug-in Registration” in Plug-in Programming Topics.

CFPlugInFactories

CFPlugInFactories (Dictionary - macOS) is used for static plug-in registration. It contains a dictionary identifying the interfaces supported by the plug-in. Each key in the dictionary is a universally unique ID (UUID) representing the supported interface. The value for the key is a string with the name of the plug-in factory function to call.

For information about registering plugins, see “Plug-in Registration” in Plug-in Programming Topics.

CFPlugInTypes

CFPlugInTypes (Dictionary - macOS) is used for static plug-in registration. It contains a dictionary identifying one or more groups of interfaces supported by the plug-in. Each key in the dictionary is a universally unique ID (UUID) representing the group of interfaces. The value for the key is an array of strings, each of which contains the UUID for a specific interface in the group. The UUIDs in the array corresponds to entries in the CFPlugInFactories dictionary.

For information about registering plugins, see “Plug-in Registration” in Plug-in Programming Topics.

CFPlugInUnloadFunction

CFPlugInUnloadFunction (String - macOS) specifies the name of the function to call when it is time to unload the plug-in code from memory. This function gives the plug-in an opportunity to clean up any data structures it allocated.

For information about registering plugins, see “Plug-in Registration” in Plug-in Programming Topics.

Copyright © 2018 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2018-06-04