BlackBerry Dynamics utilizes a number of capabilities of the operating system that require build-time configuration. Some build-time configuration is therefore mandatory for all applications.
Applications using the BlackBerry Dynamics framework can't directly link to third party libraries included in the runtime, but should instead should include and maintain their own copies of any of these third party libraries if required.
The build-time configurations that are required in a BlackBerry Dynamics application depend on how the application was or will be set up:
Note: Here, application set-up means the creation of the BlackBerry Dynamics entitlement identifier and version. It doesn't mean server address configuration, policy settings, nor end user entitlement, for example.
The following build-time configuration is mandatory for in-house applications. It applies with small variations to other types of application. See under Variations, below, for details.
All applications must support inter-application communication. This is required for:
BlackBerry Dynamics utilization of inter-application communication requires the following build-time configuration.
All applications must register a specific URL type on the device. The URL type must be the same as the application's native bundle identifier.
Within the URL type declaration, five URL schemes must be declared. Two schemes must be declared that are the same as the URL type, with .sc2
and .sc3
appended. An additional scheme must be declared that is the same as the URL type with .sc2.
and then the BlackBerry Dynamics entitlement version appended. First and second discovery schemes com.good.gd.discovery
and com.good.gd.discovery.enterprise
must also be declared. The URL type and schemes would be declared in the application's Info.plist file, as usual.
For example, if the native bundle identifier of the application was com.example.gd.myapp
then the URL type declared would also be com.example.gd.myapp
and the URL schemes would be:
com.example.gd.myapp.sc2
com.example.gd.myapp.sc3
com.example.gd.myapp.sc2.1.0.0.0
(if the BlackBerry Dynamics entitlement version was 1.0.0.0)com.good.gd.discovery
(first discovery scheme)com.good.gd.discovery.enterprise
(second discovery scheme)The Info.plist file of any of the official sample applications that come with the BlackBerry Dynamics SDK can be used as a guide. The second discovery scheme com.good.gd.discovery.enterprise
is not included in the samples and must be added manually. Alternatively, add the following XML to the application's Info.plist file, using a text editor. Change all instances of com.iOS.App.ID
to the native bundle identifier of the application and change 1.0.0.0
to the BlackBerry Dynamics entitlement version.
Note that the first three CFBundleURLSchemes
array items have suffixes of .sc2, .sc2.1.0.0.0 and .sc3 applied to the native bundle identifier. The CFBundleTypeRole
element is not used by BlackBerry Dynamics and could take another value, as required by the application.
In case there are multiple Info.plist files, check that the correct one has been edited by opening the Info tab of the application target being built. The declarations just made should appear there.
The BlackBerry Dynamics runtime checks the configuration during authorization processing. The end user will not be authorized if the configuration is incorrect.
Any BlackBerry Dynamics application that is part of a suite developed by the same enterprise must support data sharing. This is required for Easy Activation delegation between the applications in the suite. If an enterprise has only a single BlackBerry Dynamics application, then supporting data sharing is still advised because it has no disadvantages.
BlackBerry Dynamics utilization of data sharing requires the following build-time configuration:
com.good.gd.data
The above build-time configurations are for in-house BlackBerry Dynamics applications. Other types of application must use a variation with a different declaration of URL schemes. In-house URL scheme declarations are under Inter-Application Communication, above.
BlackBerry Dynamics applications that aren't in-house, partner applications, mustn't declare the second discovery scheme: com.good.gd.discovery.enterprise
BlackBerry Dynamics applications developed by BlackBerry must instead declare the second discovery scheme: com.good.gd.discovery.good
There is no second discovery scheme for partner BlackBerry Dynamics applications developed by third parties.
Face ID is a facial recognition feature that is available on some iOS devices. The BlackBerry Dynamics management console has a policy setting by which the enterprise administrator can allow end users to authenticate using Face ID. Authentication processing for Face ID is handled by the BlackBerry Dynamics runtime, without reference to the application code. The purpose for which Face ID is used must be declared by the application, and this cannot be handled by the runtime.
A purpose for using Face ID must be declared by all BlackBerry Dynamics iOS applications. This is a mandatory build-time configuration. The declaration goes in the Info.plist file, in the NSFaceIDUsageDescription
property. For example, the following key and value could be added.
The value will be presented in a confirmation dialog for the end user, before the first attempt to authenticate using Face ID is made. Note that if enterprise policy doesn't allow the current end user to authenticate by this mechanism, then the dialog won't be shown.
Because this value is a message to the end user, it should be made available in different languages and in localized variations. This can be done by using InfoPlist.strings files. The mechanism is described in the Information Property List Key Reference on the apple.com developer website. See under Localizing Property List Values.
The Info.plist and InfoPlist.strings files of the sample applications that come with the BlackBerry Dynamics SDK contain values that can be used in any BlackBerry Dynamics application.
By default, the BlackBerry Dynamics runtime checks that there is a GDiOSD
elegate
event receiver when an authorize function is called. If there isn't, the runtime will raise an assertion and the program will terminate. This check must be switched off in the case that the application doesn't implement GDiOSD
elegate
and instead uses the GDState interface to monitor authorization.
The event receiver check can be turned off, as follows.
le:BlackBerryDynamics
Dictionary
CheckEventReceiver
Boolean
No
Alternatively, add the following XML to the application's Info.plist file, using a text editor.
BlackBerry Dynamics supports App Thinning by slicing. In principle, App Thinning by use of on-demand resources is also supported but this isn't useful to typical BlackBerry Dynamics applications. Bitcode isn't supported.
Stripping symbols from the executable increases the security of an application. It makes reverse engineering and binary modification more difficult.
Select the following options in the configuration for the production build.
The user interface for these options can be found in the Xcode Project Editor, on the Build Settings tab. The easiest way to locate the options may be to key the name of each setting in the search box.
The above settings will remove symbols and debugging information from the executable. It is OK not to select them in a debug build.
Check the Apple application developer website for more explanation of what these options do.
The following configurations may be set within the Info.plist file of a BlackBerry Dynamics iOS application.
Key | Type | Example | Required | Description |
---|---|---|---|---|
GDApplicationID | String | com.example.browser | Yes | BlackBerry Dynamics apps are uniquely identified by a BlackBerry Dynamics entitlement ID (GDApplicationID). The entitlement ID is used to manage end-user entitlement in the management console. |
GDApplicationVersion | String | 1.0.0.0 | Yes | A BlackBerry Dynamics entitlement version is a string made up of a sequence of numbers separated by full stops (periods). The entitlement version string should only change in subsequent releases in which one of the following software changes is made:
|
GDDisableScreenshotPrevention | Boolean | false | No | Disables iOS screenshot prevention. When set to true , screenshot prevention is disabled even if the policy is enabled in the enterprise management console. Setting to false has no effect.Note: Developers should only disable this feature if encountering issues with UIWindow handling. |
GDDisableAutomaticLauncherManagement | Boolean | false | No | Disables BlackBerry Dynamics Launcher. BlackBerry Dynamics will attempt to display and manage the Launcher by default, thus providing app navigation and switching functionality to all Dynamics apps. If this is not desired, disable this behavior by setting this to true |