Configure callbacks on iOS

When App Shielding checks for security problems, you can configure it to either exit when it detects a security issue, or to provide a notification to the application which specifies the results of the security check so the application can decide how to handle this case (e.g., notify the user about possible security problems). This is possible for all checks except the library injection feature which blocks injection. In this case, App Shielding only provides a callback, but it is not possible to configure it to terminate the app (which should not be necessary in any case, since the security posture is unchanged because the injection was blocked).

Delegate callbacks currently occur when the application registers an observer with PRMShieldEventManager, during application launch (see Callbacks on iOS), or when the application is moved to the foreground.For more information about configuring the App Shielding behavior after performing a security check, see Configuration of App Shielding for iOS apps.

Optionally, you can configure App Shielding to provide security check results.

To configure App Shielding to provide security check results

  1. Ensure the respective security feature is enabled in the configuration, and is not configured to terminate the application when a security problem is detected.
  2. Ensure that ShieldSDK.xcframework is included in the project.
  3. Import the ShieldSDK/Shield.h umbrella header into all source files that will interact with the callback API.

  4. Create a class that implements the PRMShieldEventDelegate protocol, as defined in ShieldEvent.h. This protocol defines delegate methods that, when implemented, are called when different security checks are finished. For more information about the callback functions, see Callbacks on iOS.

    The callback methods are triggered from the main thread so it is possible to perform UI operations directly from the delegate methods.

  5. Register an object of the class implementing the PRMShieldEventDelegate protocol by calling the - (void)addObserver: method of the PRMShieldEventManager class. This registration should take place as early as possible, since numerous security checks are performed right after application launch. Ideally, the registration is performed in the didFinishLaunchingWithOptions method of the application delegate.

    Observers added with the addObserver method will be retained indefinitely by App Shielding. They cannot be removed and their callbacks will remain active for as long as the application is running.

You can see an example of how to use the callbacks in the sample provided with the package.

Debugging: manual triggering of callbacks

To debug or test unshielded apps in the iOS simulator and on real devices, ShieldSDK callbacks can be manually triggered using instance methods of the PRMShieldCallbackTestManager class. ShieldSDK provides an API for debugging purposes. This debugging API allows you to trigger callbacks with the desired value and delay when the callback should be triggered. The API will not trigger any checks to be run but rather the desired callback which you want to validate.

---
- (void)triggerJailbreakStatus:(BOOL)value afterDelay:(NSTimeInterval)delay;
- (void)triggerEmulatorDetectedAfterDelay:(NSTimeInterval)delay;
...
---

This code is for debugging purpose only and should not exist in the binary when shielding it. When these calls are included in a shielded app, the app will terminate unexpectedly.

This feature will not be available after shielding, as the Shielding Tool will replace the stub library with the actual App Shielding library.