VCL dual‑project versus FireMonkey single‑source for Windows/macOS RAD Studio applications

The premise needs one correction first

VCL is Windows-only. There is no supported way to compile a VCL project for macOS, so "two VCL projects, one per OS" is not an available strategy. The realistic dual-project option is VCL on Windows plus a FireMonkey (FMX) project on macOS, sharing non-UI code in common units. The single-source option is one FMX codebase compiled for both targets. With that correction, the trade-off becomes clear.

Which trade-off wins for your stated goals?

Your requirements pull in opposite directions: native Windows look-and-feel and direct Win32 access favor VCL; low maintenance favors single-source FMX. The deciding question is how hard your Windows fidelity and Win32 requirements really are.

• If native Windows fidelity and Win32 integration are hard requirements: VCL-for-Windows + FMX-for-macOS with shared business logic is the best trade-off. You get genuine native controls and fast startup on Windows, and FMX's styled controls are usually acceptable to macOS users, who are often more tolerant of non-Cocoa UI than Windows users are of non-native UI.
• If one team maintaining one UI matters most: single-source FMX wins despite the compromises. FMX renders its own GPU-backed controls rather than wrapping Win32, so Windows startup and rendering are typically heavier than VCL, though acceptable for most business applications.

Startup performance and macOS fidelity

On Windows, VCL generally starts faster and looks native because it wraps Win32 controls directly. FMX apps are native executables but render their own widget tree, so cold start and per-frame rendering carry more overhead. On macOS, FMX fidelity is "close but not native": styles imitate the platform appearance, but menu behavior, retina scaling edge cases, and platform-specific controls can diverge from a true Cocoa app. These gaps are version-sensitive — recent RAD Studio releases have improved FMX rendering and High-DPI support — so measure with your version rather than trusting older comparisons.

Maintenance overhead over a release cycle

A single FMX codebase roughly halves UI work, but concentrates effort in platform-conditional code ({$IFDEF MSWINDOWS}) and per-platform style tuning. Dual projects duplicate every UI change across two forms, but each platform stays fully native and changes are isolated. In both approaches, keeping business logic in shared, UI-free units is what actually controls duplication — the UI layer is where the strategies differ. A practical estimate: implement one representative feature both ways and track the change effort.

Win32 API access in FireMonkey

This is less limiting than it first appears. An FMX app on Windows is still a native Windows executable and can call Win32 APIs directly; the code just needs conditional compilation so the macOS build doesn't see it. The real cost is that every platform-dependent feature needs a per-platform implementation — Win32 calls on Windows, Cocoa/Objective-C bridging on macOS — which erodes the "write once" benefit in proportion to how many platform-specific features you have. List the specific Win32 APIs you need and confirm each works from an FMX Windows target before committing.

Verify before deciding

1. Build a representative form in VCL (Windows) and FMX (Windows + macOS) on your RAD Studio version; measure cold startup and memory.
2. Run the FMX macOS build beside a native Cocoa app and check menus, retina rendering, and standard controls.
3. Prototype your most demanding Win32-dependent feature in an FMX Windows target with {$IFDEF MSWINDOWS}.

Note that macOS deployment requires a Mac with Xcode and PAServer plus Apple signing/notarization regardless of framework — that pipeline overhead is constant across both options.