Embarcadero's 2011 cross-platform framework began by rejecting the architecture it replaced.
A Clean Break, by Design
When Embarcadero shipped FireMonkey with Delphi XE2 in September 2011, the company was explicit about why the VCL had not simply been extended to reach macOS and, later, iOS and Android. The VCL's component model is built on Win32 window handles: every TControl ultimately maps to an operating-system widget, and the layout, painting and event-routing logic delegates to Windows itself. That dependency is not incidental — it is structural. To make the VCL run on another platform would have required replacing its foundation entirely, which would have broken the accumulated ecosystem of third-party components and the runtime behaviour developers depended on.
Delphi-era developer conferences were where version changes got argued out in front of the people who had to migrate.
Photo: Matheus Bertelli / Pexels
FireMonkey's answer was to own the entire rendering stack. Rather than wrapping native OS controls, FireMonkey draws every UI element itself, using GPU-accelerated graphics APIs — Direct2D on Windows, Quartz on macOS, OpenGL ES on mobile. A button, a grid, a checkbox: each is a scene-graph node, painted by FireMonkey, not by the host platform. The approach is closer in spirit to a game engine than to a traditional RAD toolkit, and Embarcadero said so in its launch materials.
A parts store rather than a code library, but the same premise — take a standard piece off the shelf instead of making one.
Photo: Charlie Merrow / Pexels
The component model changed accordingly. The base visual class in FireMonkey is TControl, but it is not the Win32-flavoured TControl of the VCL. Components are positioned within a scene, can be nested and rotated, carry opacity and transformation properties, and respond to touch events as naturally as mouse events. Form files use the FMX extension rather than DFM, and the property vocabulary differs enough that VCL code cannot be dropped into a FireMonkey project without revision.
That incompatibility was a deliberate trade. Embarcadero's stated goal was a single Object Pascal codebase that could produce a native executable for Windows, macOS, iOS and Android — with platform-specific styling applied at runtime so that the same component tree could render differently according to the host OS ↗. The RTL and language were shared; only the framework layer changed. Third-party vendors including TMS Software and other vendors subsequently built parallel FireMonkey component lines to match their VCL catalogues, acknowledging that FireMonkey was not a compatibility layer but a separate platform requiring separate work.
The VCL was not retired. Embarcadero continued shipping it alongside FireMonkey, maintaining both ↗ in every subsequent RAD Studio release. The two frameworks coexist as a record of the argument Embarcadero made in 2011: that genuine cross-platform reach required starting over.
More in After Borland