Decompiling an App without AL Source Code in Business Central

What can you do without the source code to an app you own? In this video, with the help of Claude, I try to do that. A clean room design approach. Check out the video:

https://youtu.be/vYKqWw8bLeM

In this video, Erik demonstrates a fascinating “laboratory experiment” — decompiling and recreating a Business Central app when you no longer have access to the original source code. Using the publicly exposed symbol information from an installed app, combined with AI assistance, he reconstructs a working version of the app. He’s careful to note this is a “can you do it?” experiment, leaving the “should you do it?” debate for the comments.

The Scenario: Lost Source Code

The setup is a familiar nightmare for many Business Central developers: you have an app installed — in this case, Steve Endow’s “Super Duper Support Plan Management” app — but the original developer is no longer reachable and there’s no source code available. When you right-click the app in Business Central, there’s no “Download Source” option. The app works, but you can’t maintain or modify it.

No App Is Truly Without Source Code

Erik makes an important observation: no app is ever completely without source code. Every installed app exposes public information through its interface:

  • Page names and their field layouts
  • Table structures with field names and types
  • Enum definitions
  • Public procedure signatures
  • Tooltips, styles, and editable properties
  • Actions (though without their implementation triggers)

This public information is what Business Central developers know as symbols — the same metadata that Visual Studio Code downloads when you work with dependencies. Even a blank VS Code project already has access to symbol information for all installed apps.

The Approach: Symbols + AI = Reconstructed App

Erik built a function that automates the following process:

  1. Extract public symbols from the installed app
  2. Slice and dice the symbol information into structured data
  3. Send it to an AI (in this case, Claude Opus 4) and ask it to recreate each object
  4. Output a zip file containing the reconstructed AL source files

The process generates files for all the app’s objects — pages, tables, enums, and codeunits. The output includes an app.json file and individual AL files for each object.

First Compilation: Almost Perfect

After extracting the generated files into VS Code, the project nearly compiled on the first try. There was one error — the AI referenced a source table as “Support Plan” instead of “Support Plan Header.” After that quick fix, the app compiled successfully.

The reconstructed code included:

  • The Support Plan Setup table with primary key, number series, and field definitions
  • The Support Plan Card page with groups for General, Plan Details, Support Hours, Business Central Information, Notes, and Administration
  • A FactBox for related contacts
  • Usage categories and other page properties
  • Style expressions and conditional formatting (like “remaining less than five”)

Deploying Over the Existing App

To safely deploy the reconstructed app over the original, Erik took two key precautions:

// In app.json:
// 1. Bumped the version number to 2.0
// 2. Set schema update mode to prevent data loss
"schemaUpdateMode": "Synchronize"

// Also enabled source access for future maintenance:
"allowDebugging": true,
"allowDownloadingSource": true,
"allowSourceInSymbols": true

The schemaUpdateMode: Synchronize setting is critical — it ensures the new version won’t introduce any breaking changes to the existing database schema. When the app deployed successfully via F5, it confirmed there were no breaking changes between the reconstructed app and the original.

The Gap: Missing Business Logic

While the structure was faithfully recreated, there was an expected gap: action implementations were missing. Actions like “Refresh Status” and “Send Renewal Reminder” appeared on the page, but they had no trigger OnAction or RunObject defined — because that implementation detail is not part of the public symbol information.

Similarly, internal procedures (marked as local or internal) wouldn’t be in the symbols. However, any procedure without those access modifiers — meaning it’s publicly accessible — would be captured in the symbols, albeit without its implementation body.

Phase Two: AI Fills in the Gaps

To complete the missing business logic, Erik turned to Claude (Opus 4) with a straightforward prompt:

“This is an incomplete app. Please complete this app so that all functionality will work. This should be an app for handling support plans for Business Central.”

Claude then explored the codebase, read all the source files, and filled in the implementation gaps — comparing it to the Jurassic Park approach of “using frog DNA to fill in the gaps.”

The AI added:

  • Table triggers and procedures (like SetNotes, GetNotes, UpdateStatus)
  • Action implementations for refresh and send reminder functionality
  • Page triggers like OnAfterGetRecord and OnNewRecord
  • Style update logic
  • A Support Plan Management codeunit with RunObject references

After one round of build error fixes (since Claude was running detached and couldn’t compile directly), the app built, deployed, and ran successfully — showing status fields, “Days Until Expiration” calculations, and working action buttons.

About the Original App

The app used in this demonstration is from Steve Endo’s “VIP Coding” series on YouTube. The .navx extension file (shown in the source code section) is the compiled app package format, containing the manifest, compiled delta files for tables, pages, and codeunits, along with content type definitions — but notably, no human-readable source code.

Conclusion

This experiment proves that it’s technically possible to reconstruct a Business Central app from its installed symbols and AI assistance. The publicly exposed metadata provides the structural skeleton — tables, pages, fields, properties, and public procedure signatures — while AI can intelligently fill in the business logic gaps. The fact that the reconstructed app deployed over the original with Synchronize schema update mode and no breaking changes is a strong validation of the approach’s accuracy.

That said, Erik deliberately sidesteps the ethical and legal questions, leaving those for community discussion. There’s also a companion video on the channel about how to avoid getting into this situation in the first place — which is arguably the more important lesson. Prevention (ensuring source code access, escrow agreements, and proper IP arrangements) is always better than reconstruction.

Picture of hougaard

hougaard