AL language and runtime evolution

The AL language is what every Business Central extension is written in today. It replaced the older C/AL in NAV 2018 / BC 14, and has been evolving rapidly since — new runtime versions every release wave, new language features, deprecations of old patterns. For anyone touching BC code, understanding the language's trajectory matters.

C/AL background. Pre-2018, Business Central (then Dynamics NAV) used C/AL — a proprietary Pascal-like language tightly coupled to the NAV Development Environment. Code lived in objects modified directly inside the database. Customisations were per-tenant, hard to upgrade, hard to maintain.

AL launch. Introduced in 2017 with NAV 2018, AL is C/AL's successor:

• VS Code-based authoring.
• Modern syntax while preserving NAV semantics.
• Extension model — code packaged as deployable extensions, not direct object modification.
• Source control friendly — text-based; git workable.

The shift was painful but transformative. By BC 17 / 2020, AL was fully mature and C/AL was deprecated.

Runtime versions. Each BC release wave bumps the AL runtime version. Runtime version determines:

• Language features available.
• API surface available.
• Behavioural compatibility.

Extensions declare their minimum runtime version in app.json. Newer runtimes typically backward-compatible; the constraint is on lower bound.

Language features by wave.

• AL 1.0 (BC 14) — basics: tables, pages, codeunits, reports, events.
• AL 2.0 era — interfaces, enums, page extension improvements.
• AL 6.0+ era — text builders, refined error handling.
• AL 10+ era — out-of-the-box exception handling, modern collection types.
• AL 12+ era — Copilot-aware patterns, refactored event publishing.

Each wave adds incrementally; checking release notes per wave is essential for developers.

Interfaces. A meaningful add: defining interfaces for codeunit contracts, enabling polymorphism via enums implementing interfaces.

Events and integration. Events (OnBefore, OnAfter, Integration events) are the canonical extension hook. The event ecosystem expands per wave — more events, finer granularity.

The extension package (.app). Compiled AL produces an .app file:

• Self-contained.
• Versioned (Major.Minor.Build.Revision).
• Dependencies declared.
• Deployable via web client or programmatically.

The app.json and launch.json configure the project.

Per-tenant vs AppSource.

• Per-tenant extensions — deployed to one BC tenant.
• AppSource extensions — published by partners through Microsoft's marketplace; available to all BC tenants.

Same language; different distribution.

Performance considerations. AL performance has improved each wave but the patterns matter:

• Avoid heavy in-loop database calls.
• Batch operations preferred.
• Use SetLoadFields to reduce field load.
• Background tasks for long-running.

Modern testing. AL test framework matured around BC 16/17:

• Codeunits as test fixtures.
• Test runner integrated.
• Mocking patterns documented.

CI pipelines that compile and run tests on every commit are now standard.

Telemetry. Application Insights integration via AL allows extensions to emit telemetry; partners and customers can observe runtime behaviour.

Pragmas and obsolete attributes. Marking obsolete code:

• Obsolete attribute on procedures.
• Compiler warnings for callers.
• Eventual removal after grace period.

A discipline around obsoletion enables backward-compatible API evolution.

Common pitfalls.

• Sticking with C/AL patterns in AL. Old habits; AL has better idioms.
• Ignoring runtime targeting. Targeting too high excludes some tenants; too low loses features.
• Heavy direct database calls. Old pattern; new pattern uses set-based and batch APIs.
• No test coverage. Manual testing only; regressions ship.

Strategic positioning. AL is the future of Business Central extensibility. Investment in AL skills, modern patterns, source-controlled extensions, and CI/CD pipelines aligns with Microsoft's direction. Legacy C/AL maintenance is shrinking; new development should be AL from day one. The language continues to evolve; staying current on per-wave changes is part of being a productive BC developer.