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.
There are two options for including the BlackBerry Dynamics runtime in an application:
The BlackBerry Dynamics runtime static library requires the following frameworks and libraries to be included in the Link Binary With Libraries build phase (this is not necessary for the BlackBerry Dynamics runtime dylib):
CFNetwork.framework
CoreData.framework
CoreTelephony.framework
GD.framework
libz.dylib
or libz.tbd
LocalAuthentication.framework
MessageUI.framework
MobileCoreServices.framework
Quartzcore.framework
QuickLook.framework
Security.framework
SystemConfiguration.framework
WebKit.framework
The BlackBerry Dynamics runtime dylib requires 'BlackBerryDynamics.framework' to be included in the Link Binary With Libraries build phase and to be embedded into the application bundle as part of a Copy Files build phase (this is not necessary for the BlackBerry Dynamics runtime static library). Create a new Copy Files build phase by selecting the Build Phases tab of the application target in Xcode, click the '+' button at the top of that section, select 'New Copy Files Phase' from the drop down menu, select 'Frameworks' as the destination and add 'BlackBerryDynamics.framework'. Optionally rename the build phase to 'Embed Frameworks' by clicking on the 'Copy Files' title.
Applications using the BlackBerry Dynamics runtime static library can use binary API compatibility to directly link to the third party libraries included in the runtime if required. Applications using the BlackBerry Dynamics runtime dylib can't directly link in this way but 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.
Some earlier versions of the BlackBerry Dynamics SDK for iOS required a fifth URL scheme declaration, with .sc
appended. This isn't required in the current version and must be removed if present.
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.
Use of a custom linker is mandatory for all BlackBerry Dynamics for iOS applications that use the BlackBerry Dynamics runtime static library, and is part of compliance with Federal Information Processing Standards (FIPS). The linker enables the BlackBerry Dynamics runtime to check its own binary integrity when the application runs. If the dylib is used, no special build-time configuration is needed to switch on run-time integrity checking in a BlackBerry Dynamics for iOS application.
Configure the linker using one of the following sets of instructions, depending on whether the application includes any Swift source files.
If the application has no Swift source then configure the linker as follows:
.xcconfig
) file, if the application has one, or can be placed in a separate file.-all_load
linker flag. This flag would be selected in the Other Linker Flags field in the Linking section, in the application target Build Settings. The -ObjC
linker flag can be used instead.If the application source includes one or more Swift files then configure the linker as follows:
.xcconfig
) file, if the application has one, or can be placed in a separate file.-B ${LDUTILDIR}
-all_load
linker flag, if it is present. This flag cannot be used with the custom linker. The -ObjC
linker flag can be used instead.The BlackBerry Dynamics runtime fails with an error message like the following if the custom linker is not configured:
"Crypto::initialise: FIPS_mode_set failed: fingerprint does not
match"
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.
All applications must switch off the Bitcode build option, i.e. set Enable Bitcode: No. The current state of the Bitcode build option in the application can be found in the Xcode Project Editor, on the Build Settings tab. The easiest way to locate the option may be to key "bitcode" in the search box.
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.
There is a known problem activating a BlackBerry Dynamics application in the following setup:
The symptoms of the problem are that activation fails at the stage: Secure Data Transfer via AppKinetics. An error alert is displayed, as follows.
The following appears in the development environment console.
The cause of the problem is that the application doesn't have access to the iOS keychain.
The problem can be fixed as follows.
Entitlements.plist
file with the following content. .xcconfig
) file, if the application has one, or can be placed in a separate file.Build and run the application with the above fix.