AI Integration
CENTRALIZE AI PROVIDERS AND MODELS WITH REUSABLE ALIASES
AI providers and models are now defined in a dedicated AI tab in Settings and reused across the application.
Each provider stores its base URL, API key, and optional identifiers. Connections can be tested directly, so access is verified before any call is made. Once configured, providers become part of the project settings and follow the same deployment logic across structure, user, or data level configurations.
Model usage is simplified through two approaches. You can reference models using a provider based format such as ProviderName:ModelName, or define model aliases that map a custom name to a provider and a model ID. When the model attribute matches an alias, 4D automatically resolves the associated provider and model configuration.
This removes the need to repeat provider details or model identifiers across your code. Switching providers, updating credentials, or replacing models does not require changes in multiple methods.
Provider and model configurations remain accessible at runtime through the OpenAIProviders class. You can inspect available providers, retrieve model aliases, or adapt behavior dynamically when needed.
AI integration becomes easier to manage as it scales. Configuration stays centralized, model usage stays consistent, and your code stays focused on application logic instead of external setup.
User Interface
LIQUID GLASS LOOK FOR 4D FORMS ON macOS
In 4D 21 R3, forms on macOS adopt the Liquid Glass system style automatically.
Standard objects such as buttons, lists, and menus follow updated spacing, transparency, and visual feedback defined by macOS. Rendering changes visually, while form logic and event handling remain unchanged.
Because the style introduces transparency and rounded shapes, layouts with tight spacing or layered elements may require minor adjustments.
Applications align with current macOS conventions without changing how forms are built.
BUILD MODERN INTERFACES WITH FLUENT UI AND LIQUID GLASS
In 4D 21 R3, the Object Library supports Fluent UI on Windows and Liquid Glass on macOS.
Existing components render using the selected design system without changing their definition. The same forms adapt across platforms, keeping a consistent and modern interface without redesign.
Updated components follow current development practices, with cleaner object methods when added or regenerated.
The interface evolves across platforms while the structure and logic remain unchanged.
PRINT MODERN FORMS WITH PAPER-OPTIMIZED RENDERING
In 4D 21 R3, forms using modern UI styles are automatically adapted for print.
Widgets are converted into flat, monochrome representations, and visual effects such as transparency and shadows are removed. Layout, alignment, and dimensions are preserved, and printed values match the current state, including unsaved data.
The transformation runs automatically and produces consistent output across macOS and Windows, without changes to print logic.
NETWORK
LEGACY NETWORK REMOVED
In 4D 21 R3, the Legacy network layer is removed.
New projects use QUIC by default, while binary databases use ServerNet. The network layer is defined at creation time based on the application type.
Existing applications that still reference Legacy remain compatible. At runtime, 4D uses ServerNet, so applications continue to run on a supported layer without requiring immediate changes.
Supported protocols become the baseline, while Legacy is no longer part of the configuration.
RECEIVE REAL-TIME EMAIL EVENTS WITH IMAP IDLE
In 4D 21 R3, IMAPTransporter supports the IDLE protocol, allowing applications to react to mailbox changes as they happen.
The IMAP New transporter command now accepts a listener object where callback functions can be defined for events such as onMailCreated, onMailDeleted, and onFlagsModified. Each callback receives the transporter and an event object with details like message count, sequence number, or updated flags.
Notifications are controlled through the notifier property. Calling notifier.start() subscribes to server events, while notifier.stop() pauses them. When active, the transporter maintains a live connection and delivers events instead of relying on periodic polling.
This shifts email handling from scheduled checks to an event driven flow. Applications stay aligned with the mailbox state, reduce unnecessary requests, and can update UI or trigger logic as soon as changes occur.
4D Write Pro
STRUCTURE DOCUMENTS WITH HIERARCHICAL NUMBERED LISTS
In 4D 21 R3, numbered lists in 4D Write Pro move from simple formatting to structured document organization. You can now define hierarchical numbering across multiple levels, allowing sections, subsections, and nested content to stay consistent automatically.
Numbering is defined through linked paragraph styles, where each level follows a structured hierarchy. Formats such as 1, 1.1, and 1.1.1 are generated automatically.
When content is added, removed, or reorganized, numbering updates across all levels without manual adjustment.
This approach removes the need to restart numbering or maintain it through code. Instead, numbering follows the structure you define, ensuring consistency across long or complex documents.
4D language
Access user sessions directly from the 4D CLIENT
In 4D 21 R3, the Session command is extended to the 4D client and now returns the remote session object instead of Null.
Session data such as the session ID, user name, and context becomes directly accessible from the 4D client. Functions like createOTP(), getPrivileges(), hasPrivilege(), and isGuest() can be called locally while still reflecting the server session.
This removes the need to reorganize code just to access session information. Logic can stay where it is used, which keeps flows easier to follow and reduces the number of intermediate methods required in client server applications.
Hybrid scenarios also become more direct. A client can generate an OTP and open a Qodly page within the same authenticated context without additional coordination.
Server side restrictions remain unchanged. Privilege modification functions still execute only on the server, and client storage remains separate.
Session handling becomes easier to integrate into existing code without restructuring it around execution context.
EXECUTE SHARED AND SESSION SINGLETON FUNCTIONS ON THE SERVER
In 4D 21 R3, functions of shared and session singletons support the server keyword, allowing them to execute on the server even when called from a 4D Client.
The function runs on the server side instance of the singleton. If no instance exists, it is created automatically, which means a singleton can exist on both client and server with distinct property values.
This applies to shared and session singleton classes. The local keyword can still be used for clarity, while ORDA data model functions also accept server for explicitness.
Parameters and returned values must be streamable, following the same execution model as server side ORDA functions.
Session related logic, shared memory operations, and server dependent processing can now stay inside the singleton that defines them, without being moved to project methods or ORDA functions to control execution location.
Turn dynamic text into real executable methods
In 4D 21 R3, the new 4D.Method class allows code stored as text to be executed as a native method.
A method is created using 4D.Method.new() and behaves like a native method. It can be executed, stored in objects, or invoked using call() and apply(). Parameters are passed in a structured way, and This returns the hosting object during execution.
Before execution, checkSyntax() validates the source code and returns detailed information about errors and warnings, including line numbers.
This allows dynamic logic to be introduced without sacrificing control. Code stored in databases or external sources can be validated and executed using the same language model, which makes runtime customization more reliable and easier to maintain.
Execution remains consistent across environments, as methods run in interpreted mode even in compiled applications.
Dynamic behavior integrates into the application instead of remaining an isolated mechanism.
VALIDATE JSON WITH MODERN SCHEMA STANDARDS
In 4D 21 R3, JSON Validate command now supports the latest JSON Schema standard (Draft 2020-12).
Schemas can now include conditional logic, advanced constraints, and extended format validation. This allows more validation rules to be expressed directly in the schema instead of being implemented in code.
As a result, validation logic can be shared across systems without duplication. Backend, frontend, and external services can rely on the same schema, which keeps behavior aligned as data flows between them.
Error reporting is more precise, making validation issues easier to identify and fix. Existing Draft-04 schemas remain supported, and the validation engine is selected automatically based on the $schema attribute.
VALIDATE DATES CONSISTENTLY IN JSON SCHEMAS
In 4D 21 R3, JSON Validate handles dates consistently whether they are stored as strings or as native 4D Date values.
Validation follows the schema definition regardless of how the date is represented internally. This removes inconsistencies when data flows between JSON, APIs, and internal processing.
Schemas remain the reference for validation rules, without requiring additional conversion logic before validation.
CATCH COMMAND PARAMETER ERRORS EARLIER IN THE EDITOR
In 4D 21 R3, syntax checking is extended to validate command parameters directly in the editor, using the types and syntax patterns defined in the documentation.
When a command expects a specific type such as Text, Integer, Object, Pointer, or an assignable variable, invalid arguments are now detected while writing code instead of surfacing later at runtime or during syntax checking. This also applies to documented multi type parameters, variadic parameters, and variadic parameter groups.
Checks are now more precise for common cases such as wrong argument types, non assignable values passed where a variable is required, or command signatures that depend on a specific documented syntax. Existing command syntax checking is not replaced here. It is extended to cover a broader and more exact set of parameter rules in both the 4D code editor and VS Code.
This brings command usage closer to what the documentation actually defines, so invalid calls are identified earlier and corrected before they spread further into the development cycle.
4D Component
MANAGE GITLAB COMPONENT DEPENDENCIES FROM THE PROJECT INTERFACE
In 4D 21 R3, the Project Dependencies interface now supports GitLab repositories, extending existing dependency management beyond GitHub.
Components can be added directly from a GitLab repository using either a full URL or a repository path. Private repositories are supported through personal access tokens, which can be defined per server and reused across dependencies.
Version selection follows the same logic as other components. Dependencies can target the highest available release, a specific tag, or a semantic version, allowing precise control over what is integrated into the project.
Once added, GitLab components behave like any other dependency. They are listed in the Project Dependencies interface, installed on project restart, and can be updated, checked, or removed without leaving the environment.
Dependency management becomes consistent across repository sources, so components hosted on GitLab follow the same lifecycle and versioning rules as the rest of the project.
Visual Studio code extension
EDIT ROLES, PRIVILEGES, AND HTTP HANDLERS VISUALLY IN VS CODE
Structured project files can now be edited through dedicated UI editors directly in VS Code.
Roles and privileges, as well as HTTP handlers, open in a visual interface instead of raw JSON. Fields are organized, options are explicit, and configurations can be updated without navigating nested structures or managing syntax manually.
Validation is built in. Invalid configurations are harder to introduce, and common errors caused by formatting or structure are avoided before they reach runtime.
The same files remain accessible as text at any time. You can switch between raw editing and the UI depending on the task, without changing your workflow or tooling.
This makes configuration easier to read, safer to modify, and more accessible across the team, while staying fully integrated in your VS Code environment.
DEPENDENCIES NOW FULLY RECOGNIZED IN VS CODE
In 4D 21 R3, the 4D-Analyzer extension loads project dependencies the same way as 4D. With dependencies resolved automatically, syntax checking and code completion rely on the same context as the 4D IDE, so feedback remains consistent across environments.
The extension reads dependencies from both dependencies.json and environment4d.json. Components shared across multiple projects are detected without additional configuration, and updates to these files trigger an automatic project reload so changes are immediately reflected in the editor.
GitHub integration follows the same logic as 4D. Components are downloaded using the same local storage, avoiding duplication and keeping versions aligned. When a GitHub session is already active in VS Code, it is reused automatically. If not, a session can be opened directly from the extension to access both public and private repositories without interrupting the workflow.
VS Code stops guessing. It works with the same dependencies, the same structure, and the same rules as your 4D application
Security
USE MACOS KEYCHAIN CERTIFICATES DIRECTLY IN HTTPS REQUESTS
In 4D 21 R3, HTTPS requests and HTTP agents can use certificates stored directly in the macOS Keychain.
Certificates are referenced by name using the storeCertificateName property when creating an HTTPRequest or an HTTPAgent. 4D resolves the certificate through the operating system, and if the certificate is not found, an error is returned immediately.
This follows the same approach already available for the Windows Certificate Store, allowing the same code to work across platforms.
Certificates no longer need to be distributed or stored as files within the application environment. They remain managed by the system, which simplifies deployment and keeps credential handling consistent across machines.