Firemonkey: Promise and Limitation

Firemonkey is amazing, when considered as a platform with a future. As a product, as it ships, it's a strange mix of odd capabilities, and unusual gaps.

For example, it's cool that everything in Firemonkey HD (formerly 2D) can be rotated and scaled. The scaling is practically useful, more than the rotation, but who knows... Maybe rotation of 90 degrees can be useful for charts or other diagrams, or in combination with animations, but I have yet to see animation used in business applications for much.

Scaling may not matter to you today, but if you have ever cared about supporting high-DPI displays in Windows, or on Mac, you need Firemonkey, not the VCL. The VCL will never be as High-DPI friendly as Firemonkey. It was a brilliant move to name Firemonkey "HD" instead of calling it "2d". The other mode in firemonkey is 3d, and so obviously the "HD" mode is 2 dimensional, but by explaining that the purpose was to be "high def" it very clearly reminds you that classic Win32+GDI is "non-high definition".
If by some chance an update to Firemonkey was to provide GDI+ back-ends on Windows, in addition to the current DirectX (win) and OpenGL (mac) back-ends, so much the better. The VCL can include GDI+ elements, such as the fine GDI+ based controls from TMS Software, but no complex VCL application I've ever written or ever will be able to write, will ever seamlessly blend GDI and GDI+, and support HIgh-DPI awareness, to my satisfaction. I've met people who claim to write Win32 applications that perfectly work at high-DPI values other than 96 DPI. I don't buy it though. Either their applications are ridiculously simple, or they have done a ridiculous amount of grunt-work to make it all work. Either way, it's hardly the low-friction "it just works" experience that Delphi users crave.

Firemonkey doesn't quite look native on Windows, or Mac, but it does provide a reasonably modern UI. It's a bold, impressive move, and it's clearly ahead of its time. The value proposition of "one app that runs natively on mac and pc, with differences between platforms either abstracted out by the framework, or IFDEFd when necessary" is convincing. And Pascal is a better language than C++, C# or java, for such an endeavor. Native code with a compile time code optimization is always faster than JIT. It's a no brainer. Delphi and C++ apps spend zero cycles doing JIT-code generation. Delphi and C++ Apps are compile time analyzed and compile time optimized, and compile time linked to strip out unused code. Delphi and C++ will always be faster and provide a smaller size application with less runtime to setup, or none (in Delphi's case). And Delphi will always be a simpler, easier to learn and more orthogonal language. It will also be less feature-complete than C++. It will fit in your brain better than C++, although C++ 2011 is an amazing language, it's still full of complexity and warts that make me none to eager to work all day using C++.

There are huge challenges ahead for Firemonkey on Mac. If you think about it, Firemonkey offers a way onto Mac for Delphi fans, and as a combo Mac and Delphi fan, I'm very happy about that. However, there is a principle of "least common denominators" that is the bane of the cross-platform developer's existence. Mac OS X is built on Cocoa+Objective-C frameworks, and anybody who doesn't write their app on Mac, using native Cocoa, will not be able to use the new frameworks. So, for example, just try to make an app with Firemonkey, and have it use OS X Lion's new document model. If you try to write an app and have it accepted as good enough to count as a Mac app instead of a "lame port of a windows app", you need to observe the platform conventions and rules as set out by Apple, as implemented in their Document Model. The easiest way to be sure you're following all those rules is to write your app in Objective-C with the Cocoa frameworks that implement it all for you. Frankly, if all you want is just a Mac app and you don't need it to run on Windows, then it's a no brainer; Learn objective-C and cocoa. But if you (like me) would like to write an app and spend a bit more effort to get it working on both Windows and Mac, then Apple doesn't care to help you.

The only real alternatives I see to Delphi + Firemonkey, for native application development, are QT and C++, or other similar frameworks, like wxWidgets and C++. There is also an open-source Pascal flavor, "FreePascal", and an IDE project "Lazarus", but if you thought Firemonkey looked "beta", well, then, I can only describe Lazarus and its LCL frameworks as "alpha level". They provide something less than VCL 1.0 level experience, and although I hope that they grow and improve in the future, they are of little interest to me, aside from one thing; Lazarus IDE actually runs natively on Mac OS, Windows, and Linux. For that alone, I should give a little nod to the geeks who built this thing and made it open source; Way to go, good work. But I'm not all that interested in LCL, and I don't think it's nearly as promising as "Firemonkey" and Delphi.

I have been developing some test applications, and trying to learn Firemonkey on Windows. I am disappointed that you can't skin the non-client areas of a window, or the Main Menu area. I'm disappointed that there is no ActionList or ActionManager yet, and that as yet there is no printing support in Firemonkey, however I am confident that they will add all those things, and much more, and that by the time Firemonkey reaches a "2.0" designation, it will hopefully be at least at the point where most of us will be seriously considering starting our next big application in Firemonkey.

I plan to write a serious text editor for Mac + Windows in firemonkey, and add printing support to it once Firemonkey supports it. I plan to investigate Document Framework classes that will run atop both Mac and Windows versions of Firemonkey, and offer a native document experience on both platforms, including operating system search and indexing, spotlight and quick preview on mac, and start-menu and task-bar integration on Windows. Just because you're cross platform doesn't mean your users will let you get away with inferior platform integration. Delphi should let you go deep, and now, wide, at the same time.


The future is Delphi on Mac OS, iOS, Windows, and hopefully some day, Android and Linux. I'm not even going to mention Windows Phone, or Blackberry, because they are dead already they just don't know it yet. Oh wait, I did mention them. Forget I mentioned them, they're dead.