Protect your IP with Runtime Apps

If you want to protect your IP when working with on-premises Business Central, you can distribute your apps as “Runtime Apps”. In this video, I explain what a runtime app actually is, check it out:

https://youtu.be/cliUs3xmXu4

In a previous video, Erik demonstrated how it was possible to bypass the resourceExposurePolicy flag on an on-premises Business Central instance and download the source code from an app that had source download disabled. That video generated significant feedback — many viewers challenged Microsoft to do better with encryption and IP protection. In this video, Erik reveals the real answer to protecting your intellectual property: runtime apps.

What Is a Runtime App?

A runtime app is a fundamentally different type of .app file. While it carries the same file extension, its internal structure is entirely different from a standard AL app package. Let’s compare the two.

Standard App Files Are Just ZIP Archives

A normal .app file is essentially a ZIP archive. If you open one with a tool like 7-Zip, you can browse its contents — including the full AL source code. If you examine the file header in a hex editor, you’ll see it starts with NAVX followed by ZIP file signatures (NAVX...PK...), confirming it’s a compressed archive.

Runtime Apps Are Encrypted

If you try the same with a runtime app file, 7-Zip will refuse to open it — it’s not a valid archive. Examining the file header reveals it starts with NAVX.NEA followed by what appears to be encrypted binary data. This is an encrypted app package, and you cannot simply unzip it to get at the contents.

How to Create a Runtime App

Runtime apps are generated by the Business Central server itself. You cannot produce them directly from the AL compiler — you need a running BC instance. The process works as follows:

  1. Install your normal (source) .app file into a Business Central instance
  2. Ask the server to give you the runtime version of that installed app
  3. The server returns an encrypted runtime package

The key PowerShell command from the BcContainerHelper module is:

Get-BcContainerAppRuntimePackage

Erik shared a PowerShell script that automates this process across all supported Business Central versions. The script loops through each version, spins up a Docker container, installs the app files, extracts the runtime packages, and then tears down the container before moving to the next version. After a few minutes, you end up with a folder full of runtime app files — one for each supported cumulative update.

Important Constraints of Runtime Apps

  • Version-dependent: A runtime app generated from one version of Business Central cannot be used on a different version. You must generate a separate runtime package for each BC version you support.
  • On-prem only: You cannot upload a runtime app to Business Central cloud (SaaS). The cloud will only accept source app files.

What’s Actually Inside a Runtime App?

Even though the file is encrypted in its packaged form, Erik demonstrated what the server actually puts inside a runtime app by extracting its contents. Here’s what you find:

  • Standard metadata: NavxManifest.xml (the XML equivalent of app.json), symbols, logos, translations, entitlements, layouts, and navigation entries
  • A bin folder instead of a source folder: This is the critical difference. A normal app has a source folder containing your AL code. A runtime app has only a bin folder containing .cs (C#) files.

The AL Compilation Pipeline

To understand why the runtime app contains C# code, you need to understand how AL actually works under the hood. The AL compiler is technically a transpiler:

  1. AL code is transpiled into C# code
  2. The C# code is compiled into IL (Intermediate Language)
  3. The .NET runtime’s JIT (Just-In-Time) compiler converts IL into machine code for execution

The runtime app contains the C# output from step 1. Erik showed an example — a page object (an option lookup list from his Toolbox app) that in C# looks like a public sealed class inheriting from a NAV form type. The generated C# contains constructors, an InitializeComponents method, variable declarations, and method implementations that vaguely correspond to the original triggers and procedures — but are thoroughly transformed and extremely difficult to reverse-engineer.

For example, an OnOpenPage trigger with a few lines of AL became a series of invocations like GetFilter, Evaluate, SetCurrentKey, and Invoke calls on record references — recognizable in concept, but bearing almost no resemblance to the original AL source code.

The Resource Exposure Policy and Source Protection

For context, here’s what a standard app’s app.json configuration looks like with the resource exposure policy settings:

{
  "id": "40286137-e535-45e5-ab8f-e5c1c616b97e",
  "name": "RuntimeDependencies",
  "publisher": "Default Publisher",
  "version": "1.0.0.0",
  "platform": "1.0.0.0",
  "application": "24.0.0.0",
  "idRanges": [
    {
      "from": 50100,
      "to": 50149
    }
  ],
  "resourceExposurePolicy": {
    "allowDebugging": true,
    "allowDownloadingSource": true,
    "includeSourceInSymbolFile": true
  },
  "runtime": "13.0",
  "features": [
    "NoImplicitWith"
  ]
}

Even with allowDownloadingSource set to false, as Erik showed in his previous video, the source can still be extracted from a standard app file on-premises. The resourceExposurePolicy is a policy flag, not a security mechanism. The actual AL source code is sitting right there in the ZIP archive.

With a runtime app, however, there is no AL source to extract. The original code has been transpiled into C#, and the package itself is encrypted. Even if someone could somehow decrypt the package, they’d find generated C# code that is practically impossible to reverse-engineer back into meaningful AL.

Practical Workflow for ISVs

Erik’s workflow for distributing his Toolbox app on-premises looks like this:

  1. Build the app through a normal CI/CD pipeline, producing a standard .app file
  2. Run the PowerShell script that iterates through all supported Business Central versions and cumulative updates
  3. For each version, spin up a Docker container, install the app, extract the runtime package, and tear down the container
  4. Collect all the generated runtime app files into an archive folder
  5. Distribute the version-appropriate runtime app to on-premises customers

The entire process takes just a few minutes and produces runtime packages for roughly 20 different Docker images covering all supported BC versions.

Conclusion

If you’re an ISV or developer distributing Business Central apps and you want to genuinely protect your intellectual property — especially for on-premises deployments — runtime apps are the way to do it. Unlike the resourceExposurePolicy flags which only serve as policy indicators, runtime apps provide real protection: the file is encrypted, contains no AL source code, and the transpiled C# inside is practically unreadable. The trade-off is that runtime apps are version-specific and cannot be used in cloud/SaaS environments, but for on-prem distribution, they are the definitive answer to IP protection in the AL ecosystem.

Picture of hougaard

hougaard