Configure callbacks on iOS

When App Shielding performs security checks, it can either be configured to exit the application when a security problem is detected (e.g., [Exit on hooking frameworks]), or it can be configured to notify the application via a callback. By handling the callback, you can, for instance, inform the user about the possible security threat.

Delegate callbacks currently occur when the application registers an observer with PRMShieldEventManager, during application launch, and when the application is moved to the foreground.

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

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

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 can also be removed with the removeObserver method of the PRMShieldEventManager API. However, App Shielding retains observers that were added with the legacy ShieldCallbackManager API indefinitely. They cannot be removed, and their callbacks remain active for as long as the application is running.

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 PRMShieldEventManager 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.