• BlackBerry Dynamics
  • Runtime library for iOS applications
  • 13.0.1.117
Build-Time Configuration

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.

Common Third Party Software

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.

See also
Third Party Software page in the appendix.

Application Set-Up Types

The build-time configurations that are required in a BlackBerry Dynamics application depend on how the application was or will be set up:

  • If the application is set up directly in the enterprise management console, then it is an in-house application. In-house applications are typically developed by programmers working at the same enterprise as the end users.
  • If the application is set up via the application developer portal then it isn't an in-house application, for the purposes of build-time configuration. Applications with this type of set-up are typically developed by third parties, Partner applications, or by BlackBerry itself.

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.

Inter-Application Communication

All applications must support inter-application communication. This is required for:

  • Enforcement of any authentication delegation policy set by the enterprise.
  • Delegation of activation, to support Easy Activation.
  • Application-Based Services, see the GDService class reference for details.

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.

<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleTypeRole</key>
<string>None</string>
<key>CFBundleURLName</key>
<string>com.iOS.App.ID</string>
<key>CFBundleURLSchemes</key>
<array>
<string>com.iOS.App.ID.sc2</string>
<string>com.iOS.App.ID.sc2.1.0.0.0</string>
<string>com.iOS.App.ID.sc3</string>
<string>com.good.gd.discovery</string>
<string>com.good.gd.discovery.enterprise</string>
</array>
</dict>
</array>

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.

Data Sharing

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:

  • All applications must be owned by the same developer team. They must be signed with provisioning profiles that have a common native App ID prefix.
  • Applications must switch on the Keychain Sharing capability. Applications must share a keychain group with the identifier: com.good.gd.data
    (The current state of Keychain Sharing in the application can be found in the application target, on the Capabilities tab.)

Variations

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

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.

<key>NSFaceIDUsageDescription</key>
<string>Enables authentication without a password.</string>

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.

Event Receiver Check

By default, the BlackBerry Dynamics runtime checks that there is a GDiOSDelegate 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 GDiOSDelegate and instead uses the GDState interface to monitor authorization.

The event receiver check can be turned off, as follows.

  1. Add a new row to the application's Info.plist file:
    • Key: BlackBerryDynamics
    • Type: Dictionary
    (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 row just added should appear there.)
  2. Within that row, add another new row:
    • Key: CheckEventReceiver
    • Type: Boolean
    • Value: No

Alternatively, add the following XML to the application's Info.plist file, using a text editor.

<key>BlackBerryDynamics</key>
<dict>
<key>CheckEventReceiver</key>
<false/>
</dict>
See also
GDState.

Support for App Thinnning

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.

Symbol Stripping

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.

  • Deployment Postprocessing: Yes.
  • Strip Linked Product: Yes.
  • Strip Style: All Symbols.
  • Strip Debug Symbols During Copy: Yes.

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.

Info.plist Configuration

The following configurations may be set within the Info.plist file of a BlackBerry Dynamics iOS application.

KeyTypeExampleRequiredDescription
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:
  • The application starts to provide a new shared service or shared service version.
  • The application stops providing a shared service or shared service version.
Otherwise, the entitlement version should not change.
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
authentication
package com good gd authentication
Definition: AuthenticationManager.h:7