Skip to main content









Applies only to Mobile Apps




Harden the protection of mobile apps with AppShield

  • Edit
    Collaborate with us
    Edit this page on GitHub
  • OutSystems AppShield lets you harden the protection of your native Android and iOS apps. OutSystems AppShield integrates with the Mobile Apps Build Service (MABS) version 6 builds and adds protection at runtime and at rest. For more information about the supported mobile operating systems and stacks, check out MABS and mobile operating systems lifecycles.

    To use OutSystems AppShield, you need to have a license. If you haven't got it already, contact the sales team.


    To protect your apps with AppShield, you need to meet the following requirements.

    • You installed the AppShield plugin in your environment. To download the plugin, check out OutSystems AppShield in Forge.
    • You have a license for AppShield.
    • You're using MABS 6.1 or later.


    • You need to rebuild and redistribute the mobile apps that you want to protect.
    • Account for the app file size increases after hardening the security, and additional time for MABS to create the build.

    Supported features

    These are the features you can use with the current release of the AppShield plugin.


    Protection available for the Android builds.

    • Root detection
    • Repackaging detection
    • Code obfuscation
    • Code injection protection
    • Debugger protection
    • Emulator detection
    • Keylogger protection
    • Screenshot protection
    • Task hijacking protection


    Protection available for the iOS builds.

    • Jailbreak detection
    • Repackaging detection
    • Code injection protection
    • Debugger protection
    • Screenshot protection

    How to use OutSystems AppShield

    To create a mobile app build with AppShield to hardened security, do the following:

    1. Install the AppShield component.
    2. Add AppShield dependencies to your app. Press Ctrl+Q to open the Manage Dependencies window. Enter OutSystemsAppShieldPlugin in the producer search field and then select all the elements in the right pane. Click Apply to add the references to your app and close the window.

      Manage dependencies

    3. Publish the app.

    4. Create native mobile builds of the app.


    AppShield and its features are enabled by default when you install it. You may want to disable it in one or more environments for testing purposes.

    • To disable AppShield functionalities in one or more environments, edit the Extensibility Configuration settings in LifeTime for the environment. Disabling the plugin in the development environment, for example, lets you run the app in emulators or debug the app.
    • To disable AppShield functionalities globally, edit the Extensibility Configuration settings in Service Studio. LifeTime copies configuration from Service Studio to environments during deployment.

    When working with AppShield JSON for Extensibility Configuration, keep in mind:

    • Specific settings in Extensibility Configuration override global Extensibility Configuration settings.
    • Extensibility Configuration settings in LifeTime override the Extensibility Configuration in Service Studio.

    Here is an example of the JSON for Extensibility Configurations. You can use different sections for iOS and Android.

        "preferences": {
            "global": [
                    "name": "DisableAppShielding",
                    "value": "false"
                    "name": "AllowJailbrokenRootedDevices",
                    "value": "false"
            "android": [
                    "name": "AllowJailbrokenRootedDevices",
                    "value": "true"
                    "name": "AllowScreenshot",
                    "value": "false"
            "ios": [
                    "name": "AllowJailbrokenRootedDevices",
                    "value": "true"
                    "name": "AllowScreenshot",
                    "value": "false"

    Configuration reference

    These are the values available in the AppShield configuration JSON.

    Value Type OS Description
    DisableAppShielding boolean iOS, Android Activates or deactivates App Shield.
    AllowScreenshot boolean iOS, Android If set to true, allows users to take screenshots of the app.
    AllowJailbrokenRootedDevices boolean iOS If set to true, allows users to run the app on the jailbroken devices.
    global JSON value iOS, Android Settings in this section apply to both Android and iOS builds.
    android JSON value Android The key denoting values that apply to the Android devices.
    ios JSON value iOS The key denoting values that apply to the iOS devices.


    In the current version, native code from the shell and supported plugins are obfuscated. A crash from the core OutSystems components generates an obfuscated stack trace.


    AppShield has the following limitations.


    Non-specific limitations.

    • On iOS the plugin doesn't block user-initiated screenshots, it only notifies the app that a screenshot was taken. OutSystems currently doesn't support this event. However, AppShield blocks taking screenshots of the iOS App Switcher.
    • After MABS creates a build, with the AppShield plugin active, and signs the build, you can't sign that build again manually because the app would recognize that as signs of tampering.


    The limitations that are specific to the obfuscation.

    We know how important obfuscation of JavaScript is to our customers. Our development team is working hard on delivering JavaScript obfuscation in one of the upcoming versions of AppShield.

    • The plugin obfuscates only the supported OutSystems mobile plugins.
    • The plugin obfuscates native Android logs in Service Center. You need to use an external tool to deobfuscate the logs.
    • JavaScript files obfuscation isn't supported. OutSystems provides guidance to obfuscate JavaScript.
    • Native iOS bitcode obfuscation isn't supported.
    • You need to contact Support to get the mapping files.

    How to retrace Android obfuscated logs

    The purpose of the obfuscation is to make the app harder to reverse-engineer. During the obfuscation process, the platform creates a mapping with the old and new names of methods and classes.

    In an obfuscated app, an error stack trace might look like this:

    Obfuscation example


    These are the prerequisites to deobfuscate the logs.

    • Android Studio on Mac, Linux, or Windows.
    • The mapping.txt file from the build. Please reach Support and request the mapping file.
    • A stack trace to deobfuscate and retrace.


    1. Have the mapping file ready.
    2. Locate the proguard tools, located under your Android SDK folder, usually in $ANDROID_HOME/tools/proguard/bin.
    3. Inside, you should have the retrace cli, or the proguardgui.

      With retrace cli. Use the retrace command, followed by the path to the mapping file and the file with the stack trace. Or, run the command without the stack trace file and then paste the log content.

      With proguardgui. Click the ReTrace button in the left pane and locate your mapping file. Paste the obfuscated stack trace and click ReTrace!.

      Proguard UI

    Known limitations

    The lines that for parsing can't have the timestamp, which is what logcat tools usually produce. Instead, the lines must start with the at keyword.

    More information

    For more information, see:

    • Was this article helpful?